Re: Tying sub arguments is rare?

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. I think of representation as being
equivalent to Perl 5's IV, NV, PV, etc. Those things don't disappear in
an assignment -- why should a custom representation disappear?

BTW, this brings up another facet of representation -- overloading.
Perl 5's IV, NV, PV, etc. reps are overloaded. Custom reps should allow
overloading by default too.

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

Which is fine if custom scalars can transmogrify the target.

> > Perl-wrapped constructors become impossible too.
> 
> There's were reasons Larry made all objects references.  I'll bet this
> is one of them.

Now I'm confused about whether you believe objects and representations
should be the same thing. IMHO, a custom rep should return ref() false.

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

- Ken

-- 
Ken Fox, [email protected], (313)59-44794
------------------------------------------------------------------------
Ford Motor Company, Powertrain           | "Is this some sort of trick
Analytical Powertrain Methods Department |  question or what?" -- Calvin
C3P Implementation Section               |