According to Ken Fox:
Chip Salzenberg writes:
According to Ken Fox:
my $x = 1;
$x = foo();
sub foo { my $y : KenFoxScalar = 2; $y }
Oh, that's easy. Scalars are allowed to be tricky, but as long as
they're actually scalars they have to know how to do value assignment.
Custom representations aren't very useful if they get "sliced" whenever
they get copied.
Sure they are. Think of $$. After C<$a = $$>, you don't expect $a to
be a magical pid variable, just a copy of the current pid.

On the other hand, in C<$a = $b>, $b's copy_to() is allowed to do a
dynamic_cast<>() on $a, and do something special if it's a known type.
That allows assignments to be fatter than usual when appropriate.
Perl-wrapped constructors become impossible too.
There's were reasons Larry made all objects references. I'll bet this
is one of them.
Doesn't all of this trouble go away if extension writers only create
new Guts?
Yes, but then we're back to Perl 5's requirement of an extra level of
indirection on EVERY SINGLE DATUM. I'm sick of that.
Huh? The core can still do ThinScalars -- just make extension writers
do FatScalar-like scalars.
In that case, FatScalar et al become mere forwarders. That would
impose an extra vtable dispatch on *every* operation that currently
requires only one.
I have no objection to my customizations taking an indirection
penalty in exchange for simple transmogrification.
But not only your customizations would pay that penalty. FatScalar,
FatArray, FatHash, etc. would also pay it. That would add up.

I never worry about giving away a Factor of Two in a program.
The problem is, neither do nine of my friends.
-- Stu Feldman (progenitor of Make)

Chip Salzenberg - a.k.a. - <chip@valinux.com>
"I am the Lemon Zester of Destruction!" //MST3K

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 21 of 24 | next ›
Discussion Overview
groupperl6-porters @
postedOct 12, '99 at 8:32p
activeOct 18, '99 at 2:31a



site design / logo © 2019 Grokbase