commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: [codec] Binary BIT_n and BITS question.
Date Thu, 18 Mar 2004 19:02:41 GMT
Gary,

Please excuse the delayed response. 

> -----Original Message-----
> From: Gary Gregory [mailto:ggregory@seagullsw.com]
> 
> > -----Original Message-----
> > From: Alex Karasulu [mailto:aok123@bellsouth.net]
> >
> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message