Re: Seperate class for Perl scalars?

[Per Bothner <per at bothner dot com>]

"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.

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

The disadvantage is that each PerlScalar means more object, more
memory space, worse caching, more time spent in gc.  So there are
definitely casts.  In addition, it may make Perl-Java cordination a
bit more complex - or maybe not.


> I worry about excessive number to string conversions if I don't do the same
> thing here.

When are you primarily doing number to string conversion?  When
concatenating? When printing?  In neither case do I see a need for
a String representation of the number.  Instead, you are appending
digits to a char buffer, not a String (since you cannot append to a
String).
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/