Re: Tying sub arguments is rare?

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. -              <[email protected]>
           "I am the Lemon Zester of Destruction!"  //MST3K