This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Seperate class for Perl scalars?


"Bradley M. Kuhn" <bkuhn@ebb.org> writes:

> Ok.  What library do you suggest?  Should i use java.lang.StringBuffer?

That is probably easiest.  Of course there is no guarantee that the
library implementation doesn't implement StringBuffer.append(int)
by first converting to String and then appending the String - but
we always have the option of replacing that.

> Other cases where (number-to-string conversion) happens is string
> comparisons, and regular expression matches.

But is that really frequent enough (using a number for string comparison
or regular expression matching) that it is worth the extra overhead?

On the other hand, maybe it's not a big overhead.  Certainly, adding
an extra pointer to field in addition to a int field is no big deal.

In any case, if you have a usable PerlScalar class, you might as
well keep it for now, and we can revisit it later.

> String to number conversion happens whenever numeric operations are
> attempted on a variable.  Examples are canonical numeric operators, and
> numeric comparison.

But in how many case is the variable's value a string in those cases?

> The final reason that I chose to have my own Scalar class was that it was
> easier to implement the semantics of scalars that way.  It's not hard to
> implement them as part of the compiler itself; it was just easier to push
> them into an abstraction.
> 
> If you suggest a particular string implementation that might serve the needs
> well, I could probably switch to it, and do conversions to numbers on
> demand.  We can always see later if it is slowing things down and switch to
> another method.

Use the Scalar class - for now, at least.

> One thing I'd like to avoid is to having always to test what format a
> particular scalar is in.  For example, if I have an operation that needs the
> scalar a string, I don't want to have to have a case statement that decides
> how to convert it.  (This might be solved if every possible representation a
> scalar could be in has toString() and toNumeric() methods, and I always knew
> I could call it and get the right version, even if it simple return { this}.)

Or you can just have a static method that does any needed conversions.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]