Andy, > I'll now -1 and uncommit any patches to the littlendian > package until this is fixed or someone shows me how having divergent > implementations of common functinality is a good thing. (good luck)
Well, I think if you looked at my patch on DWord.java, you won't be unhappy. I don't add any functionality. I add a Javadoc comment to hint to the developer that the class is a 32 bit unsigned int. I only have to do this because of the messed up intValue() method. > So if fixing these divergents is a big enough > *priority* for you and Rainer, well FIX them. > "Don't leave broken windows." I agree whole-heartedly. The first fix is to deprecate intValue() from DWord.java. It is just wrong. A 32 bit unsigned int should not return a 32 bit signed int. Can we fix this broken window, or do we leave it? I think the Javadoc patch is important. I have a second one coming up for it. The following appears in the Javadoc for intValue() in DWord.java. FIXME: Introduce a superclass for the numeric types and make this a method of the superclass! So, I e-mail the list saying this is a bad idea. Why don't we get rid of this comment? Will you -1 a patch that takes out erroneous information from the Javadocs? Seems silly to -1 an attempt to correct the documentation. As a POI user, I expected more functionality to be added to /hpsf/littleendian based on this comment. Why can't I remove it? I see this as a broken window also. I am not adding any functionality. However, documentation needs to be correct. I think we are trying to do the same thing here, unify a correct implementation of little endian functionality. My apprpoach differs in that: 1) I want to see a dangerous method deprecated 2) I want to modify the Javaodocs of the duplicate functionality to make the docs correct. Leaving erroneous information in our docs compounds the problem, it doesn't help. - Drew Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > > > > > > > >I don't understand what you want here. > > > > Not to end up with a spaghetti mess where every part of POI has its own > utility library with duplications of classes that are used throughout > POI. > > If it doesn't become a priority I'll start obstructing bugfixes and > enhancements to classes that should be rolled into this. It may look > like I'm being a pain on this, but I've been patient. I said "lets do > it when you get to it" and well its been a few months. Marc mentioned > something about it. I filed a bug recently...it was accepted. > > So bottom line, if I have to do it I will, but I'll obstruct this > package from growing in the mean time. Not because I'm trying to be > difficult but because I think its important that we don't end up with a > big mess. What makes POI different according to most people is that > we're well documented and have nice easy to read sources (most folks > agree). The way we got that way was that members of this community made > > it a priority. So if fixing these divergents is a big enough *priority* > > for you and Rainer, well FIX them. "Don't leave broken windows." -- > Otherwise leave them alone. I'll be there soon. Quality is a priority > > to me. > > Don't think I don't appreciate your work, its just this little tumor is > starting to grow. Its time to do surgery. Its not your fault, its > mine. I should have raised the issues before the code was committed, > then we'd have had this fixed a long time ago. Well I'm correcting my > mistake. I'll now -1 and uncommit any patches to the littlendian > package until this is fixed or someone shows me how having divergent > implementations of common functinality is a good thing. (good luck) > > -Andy > > Andy unit status: > > > 1. centipede documentation - priority high - wait state for Ken to fill > in blanks > 2. essay on portable code generation with XML - priority medium - active > 3. code cleanup in POI - priority high - you're starting to witness > this effort > 4. cocoon best practices example - high > 5. formulas - priority high- status - wait state > 6. other processes - swaping in and out. > > > > > >- Drew > > > >Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > > > >>Okay dudes, I'm going to start being a real pain and -1ing commits if > >>you "Have time" to fix bugs in the divergent LittleEndian than you > have > >>time to combine the functionality into the org.apache.poi.util package > > >>instead of causing a "lets everyone build their own little endian util > > >>classes" in POI. I don't want to see POI turn into a microcosim of > the > >>Apache whole where everyone builds their own conneciton pool or > >>whatever. > >> > >>-Andy > >> > > > > > >___________________ > >Drew Varner > >[EMAIL PROTECTED] > > > > > > ___________________ Drew Varner [EMAIL PROTECTED]
