I wanted to extend ColorRGBA to ColorHSLA but can’t because it is final, what the the chances of getting the final declaration removed ?
why use inheritance ? it sux. just use a static method to convert ColorRGBA to ColorHSLA.
tralala said:
why use inheritance ? it sux. just use a static method to convert ColorRGBA to ColorHSLA.
lol I'm not going to touch the inheritance comment :) I currently am using static methods in the interim, until I have my ColorHSLA class (which ideally needs to extend ColorRGBA). I need to be working in an HSL space, not just converting values.
Inheritance really sucks bad, he’s right. It always gets one caught in a pattern of inheritance one doesn’t really want. Thats why we have Controls and support entity systems rather than extending Node. Also, having a hierarchy like “NPC extends Movable extends Entity” and “Box extends Openable extends StaticObject extends Entity” locks you in. What if you want an openable NPC? Its also the reason many classes in jme3 are final.
The issue with inheritance is that if you export any models which have your ColorHLSA set on them, they will be “non-standard” and not import in any version of jME3 without them.
I’m aware of the risk’s and inherent issues, I was asking if it could be made not final, or if Im going to need to work from a custom branch.
Can you explain why you need to extend it? I don’t understand that part. Why do you need a ColorRGBA that is not a ColorRGBA?
@pspeed I don’t need a ColorRGBA thats not a ColorRGBA, I need a ColorHSLA that is a ColorRGBA, so I can internally work in an HSL colour environment (for a bunch of reasons) and perform HSL operations without needing to undergo multiple conversions each time, meanwhile JME can happily continue away using ColorRGBA.
Regardless of why I wan’t to do this, or what a bad idea it is, that is not the point of this thread… I wan’t to find out if there are reasons why we can’t make ColorRGBA non final ? I can’t think of any significant performance reasons why it needs to be finalised. (Momoko mentioned exporting “non-standard” models but that’s not a reason in support of final, it’s more of a warning).
Non-final classes also require an extra 2 bytes to send using SpiderMonkey’s Serializer.
Your ColorHSLA is keeping a separate set of HSL components or just providing operations on top of RGB or using the RGB values not as RGB?
I’m just wondering. It’s half bugged me that color isn’t a vec4 (or has-a vec4) sometimes but not for any strong reasons other than how many times we tend to treat them like vectors in math ops.
“Non-final classes also require an extra 2 bytes to send using SpiderMonkey’s Serializer.” Note: that isn’t to suggest that this was a real problem just to point it out.
@pspeed ColorHSLA has separate h, s, and l components (and transforms them back to RGBA when needed), it is not using the r, g and b values for something else.
After doing enough shader work I found I looked at everything as vec4, like when Wile E. Coyote looks at the Roadrunner and all he sees is roast meat on legs 
perform HSL operations without needing to undergo multiple conversions each time
I’m not going to touch this comment. Start with beginner java tutorials to understand Delegation > Inheritance
I don’t think we are going to change this component in the engine just to satisfy a particular and rare requirement. If you want you can do this change locally in your jME3 copy.
@Momoko_Fan thanks man, this is the sort of definitive answer I was looking for. I had already changed my own copy, I have no issues with doing so, just prefer not to.