DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11028>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11028

[PATCH] HSSFColor to use instanciations rather than seperate classes





------- Additional Comments From [EMAIL PROTECTED]  2002-07-24 12:03 -------
Personally I don't think so.  But I think you can accomplish what you're trying
to accomplish and what I'm trying to accomplish another way.

Secondly, I'm resistant to anything that increases memory for this form of
convienience.  Memory consumption is the biggest thing I want to fix after 3.0.

Third, any modificaiton to this class needs to keep the issue of "custom
palletes" in mind.  Meaning I don't want to drastically change this twice.  (Not
to mention it will be a big pain in the serializer)

Fourth, is that patch worth the memory -- AND breaking (though we don't
gurarantee interface backward compatibility in the development tree, we should
"be nice") every piece of code ever written to POI?

Here is what *would* be worth it in my view.

1. Look at custom pallettes 
2. Make this compatibile with a later approach involving custom palettes
3. probably make the constants static final ints for the indicies into the
default pallette

Here is what you'll come close to (I think, just a guess):

HSSFPallete  ----------------->  HSSFDefaultPallete     
    p HSSFColor getColorMatchingDefault(int colorindex)
    p HSSFColor getColorMatchingDefault(String triplet)
    p HSSFColor createColor(int index, String triplet, double
whateveryouneedforcustompallettes)
    p HSSFColor createColor(int index, String triplet, boolean matchesDefault,
int defaultindex, double whateveryouneedforcustompallettes)
    p HSSFColor getColor(int index)
    p HSSFColor getColor(String triplet)
    

HSSFDefaultPallete would have, in addition to the usual methods, constants
matching the *default* pallette 
 pfs int BLACK

HSSFWorkbook
  getDefaultPallette
  createCustomPallete
     (returns a pallete populated with the defaults)

While you don't have to implement the custom pallette functionality (I've
resigned myself to having to do this eventually), anything done to HSSFColor
that inconviences all existing users in hopes of convienienceing future users
needs to go in this direction IMHO, otherwise we'll just do it again later, and
thats just mean.

So I'll give you a vote on this.  If the majority of you, Glen, Avik, and Shawn
all agree on applying your patch I'll remove my objection.  (active HSSF developers)

What do you think?

BTW do you have the Excel 97 Developers kit?  

-Andy

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to