On Tue, Mar 08, 2005 at 05:49:54PM -0800, chromatic wrote:
: On Tue, 2005-03-08 at 17:39 -0800, Larry Wall wrote:
:
: > On Tue, Mar 08, 2005 at 03:23:14PM -0800, chromatic wrote:
:
: > : I could make the argument that it should be possible to decorate an
: > : object with a role. If that means generating a new anonymous class just
: > : to have a vtable to munge, so be it.
: >
: > Er, how is that different from what we already said?
:
: I didn't think it was, but this explanation used simple words that
: didn't rely on me pretending to care about weird mathematics.
Well, okay, we're in violent agreement on that, but I was also trying
to answer the question about whether and when low-level types like
"int" behave as objects or not. And the basic answer is that they
do as long as you don't try to change their storage representation.
You probably aren't allowed to say
my bit @array is shape(10_000_000);
@array[42] = 1;
@array[42] does AddExtraAttributes;
since a low-level declaration is making certain representations to the
optimizer that would be likely be invalid if we suddenly promoted the
entire array to holding Bit instead of bit. People start getting a
little edgy when they make one function call and their process size
unexpectedly goes from 2 megs to 200 megs...
On the other hand, while I can see us decorating
my bit $maybe = 1;
$maybe does AddOnlyMethods;
it's also a little problematic (I almost said "a bit problematic") to
say:
my bit @array is shape(10_000_000);
@array[42] = 1;
@array[42] does AddOnlyMethods;
insofar as we'd have to decide whether to decorate the return type of the
entire array or not. So maybe we allow decoration of low-level types
only for entire containers. The above would be illegal, but this would not:
my bit @array is shape(10_000_000);
@array[42] = 1;
@array does AddOnlyMethods;
I'm just trying to strike a balance between practicality and purity here.
Larry
