> > > >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 > What is the point of scalpalling the top of a tumor if the underlying tumor grows? You still have a tumor.
> >functionality. However, documentation needs to be correct. > No it needs to be deleted entirely. > >I think we are trying to do the same thing here, unify a correct >implementation of little endian functionality. > So lets do it. > >My apprpoach differs in that: > >1) I want to see a dangerous method deprecated > I want to see it deleted. > >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. > Nope having the class there is the issue. When I get back from camping this weekend I'm ripping the sucker out and doing my best to bandage the bleading scars in HPSF, but I don't know the code well enough to do a good job and it doesn't have much in the way of unit tests if I recall. Sorry to be drastic, but the soft suggestion approach got "I don't have time" for long enough that I feel its necessary. So if you care enough about the correct approach, take up the issue. If not...don't worry, I'll <rubbing hands together> take care of it. Its my itch I'm going to scratch it. At least I warned WELL in advance several times that "if you don't fix it I will" well...talk is cheap. -Andy > > >- 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] >
