Re: Tying sub arguments is rare?

According to Ken Fox:
> Chip Salzenberg writes:
> > I think we have to continue allowing simple value modification.  Even
> > transmogrification is no issue, because it's simply an implementation
> > technique limited to a  of the type tree (PoolScalars), and thus
> > irrelevant to classes that fall outside that subtree.
> 
> So the following works:
> 
>   my $x = 1;
>   foo($x);
>   sub foo { $_[0] = "blah"; }

Yes, by all means.

> $x starts out life as a ThinIntegerScalar and then transmogrifies
> into a ThinStringScalar -- which is no problem because that's supported
> for all objects derived from PoolScalar.

Right.

> Cool. One thing that occurs to me though is that this is a
> "yank-the-rug-from-under-the-compiler" sort of thing so some
> compiler optimizations (like caching vtbl pointers) might break
> things.

Point taken.  However, given the possibility of delete/new during any
subroutine call, I doubt that such an optimization would comply with
the ANSI standard.

> The problem case is when a PoolScalar must transmogrify to a
> non-Pool Scalar.

The hard case is when a Scalar of undetermined type -- say, a
KenFoxScalar -- is tied.  Since I have no knowledge of the size or
lifetime or other characteristics of KenFoxScalars, I can't assume
that transmogrification will work.  Thus my intention to restrict
the semantics of tie.

However, if by Rule #1 we have to support tying via reference, there
is still a way out.  It's ugly, but here goes:

We would have to impose two additional requirements on all tyable
Values.  First, they would have to know how to displace themselves to
new storage and replace themselves back into the original storage.
Second, they would have to be at least as large as a TiedScalar (or
TiedArray or ...), so as to leave room for one to be contructed.

Those two requirements together would permit transmogrification of
any Value into a Tied{Scalar,Array,whatever}.  Problem solved, but
only at great cost to my self-respect.  (Get me the soap, quick.)

> One possible solution is to have transmogrify() generate a
> forwarding object if the new object is larger than the old
> one. (Don't lisp systems with copying garbage collectors call these
> broken hearts?)

Eew.  Forwarding.  Well, I'll file that away in case we need it.

> BTW, why are ThinScalars so big? ThinIntegerScalar is 32 bytes on
> my machine (Sun Ultra-60 w/ gcc 2.95).

It's because ThinIntegerScalar is using a 'long long' currently.
That'll change in the next snapshot.
-- 
Chip Salzenberg             - a.k.a. -              <[email protected]>
           "I am the Lemon Zester of Destruction!"  //MST3K