Gary, Please excuse the delayed response.
> -----Original Message----- > From: Gary Gregory [mailto:[EMAIL PROTECTED] > > > -----Original Message----- > > From: Alex Karasulu [mailto:[EMAIL PROTECTED] > > > > Greg, > > > > > (1) The public Binary.BITS field is not used from anywhere. How is > it > > > generally useful, it has no Javadoc? Should we get rid of it? > > > > I was planning on using it later when I cleaned up this class a bit. > > If you're going for a release feel free to blow it away. I have not > > decided yet whether to leave loops unraveled and ugly or add another > > loop to cycle through this array. I thought it might be better to > > unravel it for speed. > > My POV is to *not* write code "for speed" over proper abstractions until > a proven bottleneck has been identified. In general, I do not optimize > before measuring bottlenecks. In the case of unrolling a loop, I doubt > that any measurable performance gain would up in an application. But > feel free to measure ;-) Point taken and assimilated - then in this case let's blow away the BITS field I can recreate it as a private constant later when I add the extra loop to shrink the amount of code. BTW I would not sacrifice an abstraction either, just had 8 very similar looking lines instead of a for loop over the elements of the BITS array. > > > (2) The public Binary.BIT_n fields are only used from Binary. Should > > > they really be public fields? > > > > Hmmm I think this might be best kept private but I do use them else > where > > in applications that depend on Binary however perhaps incorrectly. > Let me > > explain below. > > I see them used from the unit tests so perhaps they can be moved to the > unit test code base. Ok with me. Let's just make them private in Binary and redefine them as needed for use in the unit test cases. <snip/> > I you do things in the XP spirit, then you'd create the constants as you > need them. In this case, the tests needs them, so we have them. Maybe > the constants are in the wrong place, I am not sure. Yes I agree. There is no reason to expose the constants in Binary. Any class needing them define the consts as needed instead of using ones on Binary. Overall a good point since Binary is a codec and not a place for centralizing binary constants. <snip/> > That is a tricky issue as I stated above. My company's server ships with > a whole bunch of Jakarta jars, so I would rather see code in its proper > place, but hey, that's just me. > > Then again is it ok for other commons > > projects to have a dependency on something like commons-lang which > > has no other dependency. To me commons-lang can be a universal > > dependency and get away with it. > > Agreed, but plenty of folks do not want codec to depend on anything. Np. I don't think it's worth it to have the dependency just for the sake of accessing a couple constants in one place. Instead we define constants in the usual manner for the file needing it if it is not already defined (therefore accessible w/o a dep) by an existing codec class or the JDK. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
