Re: Tying sub arguments is rare?

According to Ken Fox:
> Chip Salzenberg writes:
> > According to Ken Fox:
> > > 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.
> 
> That's because $$ IMHO isn't a representation -- it's merely magical.
> If I write a ScalarWithUnit representation, I don't want the unit sliced
> off whenever an assignment happens.

You're talking about the copying semantics of overloading, while I'm
talking about the copying semantics of tying.

I intend to support overloading with an entirely separate mechanism
from what we've been discussing so far, because overloaded assignment
is just the tip of the iceberg---everything else has to be overloaded,
too.

(I sometimes confuse the two sometimes because $$ is going to be a
specialized representation, just one that doesn't mind being sliced.)

> I think of representation as being equivalent to Perl 5's IV, NV,
> PV, etc. Those things don't disappear in an assignment ...

But they do!  For example: An SVt_PVMG that happens to hold an undef,
when assigned to a target SV, will not force the target to upgrade to
PVMG.  It will simply turn off the OK flags of the target.

> I said FatScalar-*like* not FatScalar derivatives. Build a virtual
> class CustomScalar as peers of Thin and Fat scalars. Require all
> extension writers to subclass from Thin, Fat or Custom *only*. Thin
> and Fat can be extensively optimized. Custom is only there to make
> hard things possible.

Ah, now I see!  I must ponder this idea.  It has great potential.

... It's even possible that this could be the core construct of
support for overloading.
-- 
Chip Salzenberg             - a.k.a. -              <[email protected]>
           "I am the Lemon Zester of Destruction!"  //MST3K