Using reflection to determine color datatype versus int

Processing Beginners
1

Hello again!

Is there a way, using reflection, to determine if a given class field is declared as a color field as distinct from an int field?

I figure there must be a way, but the following returns both fields as int:

import java.lang.reflect.*;

void setup(){
  A a = new A();
  Test(a);
}

class A {
  int i = 1;
  color c = #ffff00;
}

<T> void Test(T obj){
  Class someClass = obj.getClass();
  Field[] allFields = someClass.getDeclaredFields();
  
  for (Field field : allFields){
    Class type = field.getType();
    
    println("\nfield:",field,
            "\n\tfield.getName:",field.getName(),
            "\n\ttype:",type,
            "\n\tgetName:",type.getName(),
            "\n\tgetCanonicalName:",type.getCanonicalName(),
            "\n\tgetSimpleName:",type.getSimpleName(),
            "\n\tgetTypeName:",type.getTypeName(),
            "\n\ttoGenericString",type.toGenericString(),
            "\n\ttoString:",type.toString());
  }
}

Thank you!

2

Hello Aleksi,

I don’t know if you want to do is doable. The reason is that the color datatype is actually a simple int type.

When you have a look at the source code for the color() function, you can see it actually return an int not a color datatype:

1 Like
3

Hi jb4x, thanks for the reply.

Yes, I knew that already. Hence my post: I was hoping someone knew some magical way to differentiate between the two.

4

I guess it really depends on what you’re trying to do. Again, int and color are the same thing and there’s no way to distinguish or I would say there’s no sense of distinction. But for example if you are using only opaque colors, you can test if the top 8 bits are 1 or not because it’s unlikely that they are all 1 when you use integer (it’s a negative number) - but of course, it may not happen when you count apples in real life, but if you count generative apples it might happen. There’s also a funny trick that background(-1); makes white background :slight_smile:
https://processing.org/reference/color_datatype.html

1 Like
5

Hi micaut, thanks for the reply.

What I’m attempting to do is genericize json parsing, and I’m mostly there. In my classes I use int fields for integers, and color fields for colors. I like being able to distinguish them in such a way.

It would have been nice and convenient if I could ascertain both fields from their types, or even by somehow otherwise parsing the strings used to specify the type, but I guess it’s not to be.

Fortunately there are a variety of workarounds I can implement. I was just hoping I wouldn’t have to jump through such hoops; but it appears I must.

Oh well…

6

The color dataype is syntactic sugar, existing only in the Processing editor (.pde files). As has been mentioned already, it’s simply an alias for int.

When a sketch is run from the Processing editor, .pde files are converted to .java/.class files – during this conversion any uses of color are replaced with int by the Processing preprocessor.

So during runtime int is indeed the type of these variables, just as you’ve found via reflection.

The only way to differentiate between the two (if you really want to, not that you need to, since both can be treated as int) is to look at the .pde source file.

2 Likes
7

Thank you for that micycle. Most helpful.

8

I checked how (pg.)background determines the value from int and color, and it does check the higher bits as I suggested

9

I’d be careful of your assumption there! The check for higher bits is to determine whether the calculations need to take account of alpha values. A fully opaque colour can (probably will) have the higher bits as zero. In fact, that’s the exact issue mentioned about transparent black - the color “type” really is a horrible and buggy hack!

1 Like