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?


Per Bothner <per@bothner.com> wrote:
> "Bradley M. Kuhn" <bkuhn@ebb.org> writes:
> 
> > The problem that I have come across is that it will cause many String to
> > Number conversions if I do that.
> 
> That is a reasonable issue.
> 
> > For example, in Perl:
> > 
> >          $x = 5; $x .= "foo"; print $x ;
> >          yields:
> 
> This should not be a number-to-string conversion, depending on the
> library implementation.  You are doing number-string concatenation.
> Concatenation you want to do using a StringBuffer or something
> equivalent.  If things are implemented correctly, you should not need
> to convert the number 5 to a String - you just append the digits into
> the StringBuffer.

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

> > So, the lowest common denominator is likely strings; however, typical Perl
> > programs will have many implicit conversions.  A scalar inside the current
> > perl implementation has the ability to hold multiple representations of
> > different types at once, and results are cached.

> When are you primarily doing number to string conversion?  When
> concatenating? When printing?

Number to string conversion happens anytime a Perl built-in function or
other operation (e.g., printing and concatenation) expect a string rather
than a number.

Other cases where this happens is string comparisons, and regular
expression matches.


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


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.

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}.)


-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

PGP signature


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