Iâm not saying itâs ideal, but itâs not a requirement to be able to use color with an offscreen graphics (unless youâre getting into threading)
@neilcsmith you have taken my words out of context so giving them a different meaning and then contradict them. Wow
I said the pre-processor hid the OO syntax for newbies, I call that simplification! The decision to use color as an alias for int was again aimed at early sketchers / graphic designers, personally I think it was a huge error of judgement. Fancy having a data type with the same name as a method, its just wrong.
Whatever the rights and wrongs of the pre-processor the problem is, it takes valid Processing code (according to API) and converting it to invalid Java code, and I would like it fixed.
It is a requirement that an instance of PGraphics can call the method color it is in the documented API and in the source code. It is just the pre-processor makes a mess of it.
I was already aware of the code fix you posted and I agree it will do the job but is ineligant and shouldnât be necessary. I HATE writing code like that.
Sorry! But then you took mine out of context too then! But that comes to some ambiguity as to what syntax and structure are in programming languages. Hiding the OOP stuff isnât what I was criticising in the first place.
Up to you! Itâs not much different to any other âglobalâ mathematical function in Processing in my mind - itâs not a property of the underlying PGraphics.