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;

sub foo {
$_[0] = "blah";

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

The problem case is when a PoolScalar must transmogrify to a non-Pool
Scalar. (But Topaz doesn't have any non-PoolScalars yet... ;) 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?)

A forwarding system might be useful for moving things like FatScalar
out of the PoolScalar hierarchy too. A forwarding object should only
be a few bytes larger than the xguts pointer in FatScalar (and the
forwarding object will eventually be GC'd).

BTW, why are ThinScalars so big? ThinIntegerScalar is 32 bytes on
my machine (Sun Ultra-60 w/ gcc 2.95). Is this common? FatScalar by
comparison is only 24 bytes.

- Ken

Ken Fox, kfox@ford.com, (313)59-44794
Ford Motor Company, Powertrain | "Is this some sort of trick
Analytical Powertrain Methods Department | question or what?" -- Calvin
C3P Implementation Section |

Search Discussions

Discussion Posts


Follow ups

Related Discussions

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



site design / logo © 2019 Grokbase