On Tue, 2005-05-10 at 20:38 -0700, [EMAIL PROTECTED] wrote:
> -1 on committing any patches without unit tests anymore. It
> destabilizes code too much. Even to scratchpad because then the code
> never moves out of scratchpad. We learned this lesson already. It
> doesn't matter how good or bad or how much we want it...no unit tests +
> doco...it stays as patches in bugzilla.
>
While I agree with your general sentiments, I think that not getting
things into CVS detracts from getting more contributors, particularly
for this formula stuff, where unit tests are going to be easy to write,
but we need lots and lots of it, and one person is certainly not going
to finish all cases. That's why I think we have scratchpad, so that
people can start looking at incomplete stuff.
If required, we should have criteria for removing stuff from scratchpad,
if they remain unmaintained for too long. Also we should NEVER release
jars of stuff from scratchpad, only CVS. If scratchpad and main have the
same criteria, then why have scp? would you rather that HWPF not have
been added to CVS, as opposed to being where it is now? (sorry, too many
rhetorical q's :)
Amol, irrespective of this disucussion, you should start writing some
tests for your code :)
Regards
-
Avik
> [EMAIL PROTECTED] wrote:
> > [Moving to the list, since bugzilla is bad for conversation]
> >
> > Comments inline.
> >
> >> **** As a result, you may have to apply the ****
> >> **** patch to /src/scratchpad/src instead of ****
> >> **** the root folder ****
> >
> >
> > That's ok. For the initial bit, can you just zip/tgz the directory. Provide
> > patches after the initial additions have been comitted. I am waiting to
> > commit
> > till the dummy method javadocs are removed (maybe an awk script might be
> > quick?)
> >
> >>
> >> 1. Ptg and Eval: Delegating or extending?
> >> <snip> But I guess extending from Ptg could also work...
> >
> >
> > Just to clarify, by extend, i meant have a separate class that interits
> > from the
> > Ptgs.. ie, `class AddEval extends AddPtg` .. but as I said, just a
> > suggestion,
> > you'll know best.
> >
> >> 2. Functions in one class or one class per function?
> >
> > <snip>
> >
> > Yeah, sure.
> >
> >> 3. Testing...
> >> Unit testing would be a big effort. Almost as big as writing individual
> >> functions, a distributed effort would be great!
> >
> >
> > Certainly, probably bigger. So once again, this is a call for everybody
> > interested in this functionality to write unit tests for it. Its easy!
> >
> >>
> >> 4. My eclipse...
> >
> > <snip>
> >
> > Please try and remove the extraneous comments, i dont want to put that
> > in CVS.
> > I'll commit it as soon as that's done, I'm happy with everything else.
> >
> >> 5. Under contruction:
> >> The work on core eval classes is not yet "complete". I think there is
> >> need for a
> >> BlankEval class to handle empty cells - which are currently being
> >> handled as
> >> StringEval("").
> >
> >
> > Yeah, sure, thats understood, and no issues. But your 'empty cell'
> > comment made
> > me think, the function implementations should probably follow Excel
> > semantics..
> > for eg, in the average function, empty cells do not add to the number of
> > elements (ie, the denominator). Also, these semantics might be different
> > for
> > different versions of excel. How do we handle that.
> >
> > A final thoguht on error handling. Your error handling is modelled after
> > OO.o.
> > In excel however, errors are a more limited set.. #REF, #VALUE, etc. Do
> > we need
> > to think about how to handle/map those. Maybe it doesnt matter?
> >
> > Once again, to everybody out there, this is a big and important piece of
> > work
> > that can certainly do with more evaluation/comments/unit tests. Thanks!
> >
> > Regards
> > -
> > Avik
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > Mailing List: http://jakarta.apache.org/site/mail2.html#poi
> > The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
> > .
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> Mailing List: http://jakarta.apache.org/site/mail2.html#poi
> The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
