Il giorno 03/dic/2011, alle ore 01:02, Jim Graham ha scritto:
> Phil described my take on it pretty well, but I do see your point about 
> hiding where they come from.
> 
> If I had to do it over again I might put them into an interface that SG2D, 
> the SD's and other pipeline objects could all inherit with an "implements" 
> since the constants are so intimately shared.  Josh Bloch has spoken against 
> that usage, though, since the constants then become part of the API of all of 
> those classes, but in our case this is internal API so we don't have to worry 
> about binary compatibility outside of a given release.
> 
> If we did it that way, that would likely be beyond the scope of this current 
> exercise since the goal is to not change any APIs (even internal ones) to 
> isolate the warnings changes (as simple as this change is).  On the other 
> hand, other fixes involve declaring more specific types for internal 
> generified objects which also changes API, so this is a fuzzy line in the 
> sand.
> 
> Interestingly, both a static import of * and moving the constants to a shared 
> interface would both result in the constants simply being referenced without 
> a qualifier.
> 
> Finally, I have had, in the back of my head, the thought that we should 
> eventually try to move all of the constants into a single field as much as 
> possible since they bloat the SG2D object by so much which just wastes memory 
> and cycles to create and clone them.  Doing that would likely require a lot 
> of bitmasking which would likely lead to a helper class which would be a 
> completely different rewrite of all of this code.
> 
> I'm happy to approve whichever version Mario wants to promote (except the 
> rewrite to bitfields which is clearly outside the scope here) since he is 
> doing the work though...
> 
>                       ...jim

Hi Jim,

Thanks a lot for the reply.

I've been thinking about that also, and to be honest I am still undecided which 
version I prefer (static import vs fully qualification) exactly because of what 
you say.

I like the idea to refactor those fields too.

Since the scope of this exercise is not a complete rewrite of the code, I'll 
push the current version as is from my latest webrev, but I'll start working on 
a more complete refactoring for the next weeks, at least to explore what would 
be the benefit of it over the current approach.

Thanks again.

Cheers,
Mario
---
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

http://www.ladybug-studio.com

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/




Reply via email to