"David Manura" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> khemir nadim wrote:
>
> > I agree that a way of describing a range without naming one of the
limits
> > should exist, I just don't know how to make it visually clear. What
about
> > 'B1:B*' 'B*:B10' 'B*:B*' ?
>
> '*' might be ambiguous. Does it mean infinity? Does it mean the last
> defined value in the column? The latter seems more useful, so if you
> state B1:B* and the only defined cells in the B column are B1:B10, then
> you could infer B1:B* to mean B1:B10. What then if the only defined
> values in the B column are B1:B10 and B20:B30? Would B5:B* mean B5:B10
> and B25:B* mean B25:B30? I don't know if Excel supports such
> functionality (I've looked before.)
Excel doe support this but it has meaning in the context of a formula only
while we also have the assignement context.
I completely agree with you. I have implemented this but I don't "release"
it since I don't know the semantics myself ( '*' is A or 1 as of today :-)
Your guess is as good as mine. I can even give another example, what do
$ss{'*'} or $ss{B*} mean? In the TODO there is the question about
cell/row/spreadsheet default value. We may need diffrent syntaxes for 'last'
and 'infinity'. And need to know if we need infinity and what we mean with
it.
> One thing I noticed is that the OO interface can be long-winded:
> $ss{A3} = Spreadsheet::Perl::Formula('$ss->AddOne("A5") + $ss{A5}') ;
This is patialy fixed.
$ss{A3} = Formula('$ss->AddOne("A5") + $ss{A5}') ;
I don't know if I have done that yet the following might be a good thing
$ss->Formula
(
A1 => '........',
A2 => '........',
A3 => '........',
A4 => '........',
) ;
> With some reimplementation work and some string parsing, this might be
> simplified to
> $ss{A3} = '=AddOne(A5) + A5';
No, No and Yes. No because I want SS::P to be perl and the formula should
be valid perl. No because I want to be able to store the string '=AddOne(A5)
+ A5' as a value and keep general. Yes, because many people may want to do
this. If someone is whiling to write a lexer/sub_builder (or a converter)
for those formulas, I can think about this syntax:
$ss{A3} = XXX('=AddOne(A5) + A5') ; #name may vary
> Just a few ideas. (I also just noticed the method names are the of the
> style GetFormulaText rather than of the more Perlish get_formula_text.)
Thats the man's coding style. I don't want to be dissolved into the age old,
ugly and unreadable KR style. You can always define an alias module.
> For a module with similar functionality but which does not flatten the
> problem onto a 2D grid, the psuedo-code for its usage might look like
I'll look at that separately
There is a new release in the pipeline (0.04); somewhere around sunday night
but you can get a beta if you'd like to.
I have partially fixed the mapping to spreadsheet, and back, problem:
$ss{A1} = Ref(\$my_variable) ;
or
$ss->Ref(A1 => \$x, B5 => \($struct->{xxx}), 'A2:A3' => ......) ;
$ss{A1} = 25 ; # set the scalar
We can now:
- Read the spreadsheet formulas
- Map our structures
- Recalculate()
- Go on with the perl structures
Changing the scalar directly doesn't change anything in the spreadsheet.
That would be a cool trick to have this work but I can't say that it's an
easy programming model but it seriously cool and difficult to debug.
The usual fixes and the documentation are going forward too.
I am looking at defining a standard (that's one function name) for database
connectivity (using DBI as interface).
I also have some discussion with another guy (I'll ask him to join here or
I'll CC) who wants to use SS::P for a web
based application.
I also think that the question of the format of the files generated by SS:P
as well as a "real" read and write are going to get important soon. IMO the
canonical format is perl, like in the setup example (in the tests
directory).
Thanks a lot for your input, Nadim.
