Yes, I want to check in the latest optimized Entities class. I think I can do that today.
I agree with Hen's analysis below about allowing yuckiness for the sake of optimization. I'll make it clear that IntHashMap is not a lang API class either, but a private implementation class. - A > > > Should we consider: > > > > > > (1) IntHashMap as a non-public member of [lang] > > > > > > In for 2.0, or defer to discuss (2)? > > > > This was for Entities.java optimisation? Sounds good to go in. > > > > > (2) "all his other utility code" > > > > > > Does not affect [lang] per se but it is becoming clear that keeping [lang] > > > and [collections] not inter-dependent will introduce duplication of > > > functionality or odd placement of functionality (IntHashMap in lang, not > > > collection). Duplicating code is something I am really not fond of. > > > > I think this is a clear case of a good reason for allowing duplication. > > Optimisation involves lots of yucky things [and rarely anything nice]. > > Duplication is a yucky thing, but the optimisation is more important. > > > > Hen > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Alex Chaffee mailto:[EMAIL PROTECTED] Purple Technology - Code and Consulting http://www.purpletech.com/ jGuru - Java News and FAQs http://www.jguru.com/alex/ Gamelan - the Original Java site http://www.gamelan.com/ Stinky - Art and Angst http://www.stinky.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
