> 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?)
done. but where do i send the zip? Or did you mean just
attach it to the bug?
> 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.
> Yeah, sure, thats understood, and no issues. But your 'empty cell'
> comment made
> me think, the function implementations should probably follow Excel
> 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.
Exactly. Thats what made me think about having a BlankEval.
Currently though, its not a /big/ problem because for most
numerical formulas where blanks are ignored, even strings
are ignored. So that is taken care of (but will change when
I introduce BlankEval)
> 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?
The idea was that since Oo errors are better documented,
and this is a functionality that will be used in code, it
should be helpful to give more information (Oo way) than
less (excel way).
Then again, apart from error handling, there are cases
where excel and Oo behave differently - generally I have
given preference to excel impl over Oo. Also, currently
I am documenting these in code as I detect them, but any
suggestions to better handle/document such cases are