Piers Cawley wrote:
Let's say I have a class, call it Foo which has a bunch of attributes, and I've
created a few of them. Then, at runtime I do:
eval 'class Foo { has $.a_new_attribute is :default<10> }';
Assuming I've got the syntax right for defaulting an attribute,
I think you need a 'class Foo is extended' to re-open the class.
Otherwise you produce a redefinition error if the scope you call
eval in already contains---or is that extains because of the name
search beeing *outwards*---one you start from scratch.
and lets assume
I have, the Perl runtime needs to chase down every instance of Foo or its
subclasses and add an attribute slot (adding a method to a class is nowhere
near as interesting, because every instance of the class shares a single class
object).
One way to do this is for a class to keep track of all its instances, which is
all very well until you start subclassing because subclasses have to both keep
track of their instances and inform their superclasses about any new instances,
Sorry, I thought the instances of a class fall into the two categories:
instances and subclasses. A generic implementation of Perl-OO just blesses
a reference into its immediate parent. When accessing attributes the type
system knows two things: (1) the actual data of the object, (2) the class
who did the blessing. A read access of an attribute that is not found in
the object is delegated to the class. A write access to a slot which is
not present in the object triggers a request to the class asking if such a
request is part of the attribute set. If yes, the slot is vivified on
the object and available there for future accesses. A deletion of the slot
reverts to the inherited-value lookup.
You might object that this sounds like an object as a (pseudo)hash,
and I will say it is exactly this, but in a more convenient form then
under Perl5 where the language spec didn't prescribe the default
implementation and nothing observed it at runtime.
Hmm, and when does P6Opaque enter the scene? Well, I guess there will
be a ringing of the bell(s) and then the above fully dynamic lookup
can be compiled into a fixed index per attribute packed array per object
implementation or some such. And I guess this freezing can be thawed when
needed e.g. for eval and friends. But I wouldn't expect it to be a
cheap operation!
The freeze/thaw can in an additional installment compiled into an
unthawable form that can run without a full-blown VM. But eval and
friends will be simple exception throwers in that environment.
The attentive reader might interject that the delegation to (super)class
breaks down under multiple inheritance. And this is of course correct!
It simply means the programmer has to say something about it in the
definition of the class.
Here is a list of incidents in ascending order of severity:
0: type identity of the slot, identical default value.
effect => dynamic lookup ends here and yields this default value
1: type identity of the slot, different default value.
effect => class has to specify default value
2: type compatibility of the slot.
effect => class has to disambiguate
3: type incompatibility of the slot.
effect => class has to implement the slot
And yes, I believe a slot accessor looks as follows:
class Example
{
my %private_data;
my sub source {...};
has %.data;
has &.blahh = { %.data<blahh> };
# and how about syntactic sugar for this:
has &.blubber from %.data;
# private slot
has &.hidden from %private_data is rw;
has $.hidden := &.hidden;
# initialized from class
has $.cache is rw from source;
# virtual per instance
has $.value from {...};
}
But as usual, all the above is the opinion of a casual participant
on this list without authority.
But it's not my private opinion anymore ;)
By posting it, it has become part of our @opinions since
this $email does ::Perl6::Language :)
BTW, this also gives us: my @twodim has shape(2);
--
TSa (Thomas Sandlaß)
