PDD15 says that both classes and objects have a list of attributes and
it is possible to add or remove attributes to a class but not an object.
Am I right in thinking that the attribute list for an object is just a
copy of the attribute list for the class, which is used to store the
objects values?
It seems that for Ruby instance variables can be modelled using
attributes, but I couldn't see any way of handling class variables. So,
what is the recommended way of handling them?
--
Mark Sparshatt
First, one takes the bat labeled "Metaclasses" and smacks the
designer in the head with it. Then, once enlightenment has hit, we
implement metaclasses and you add class variables as new attributes
on a class' metaclass. I think.
Alternately you can stick 'em in as plain variables in the class
namespace, which is probably the right answer for the moment, though
not for the long run.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
> At 6:53 PM +0100 4/8/04, Mark Sparshatt wrote:
>
>> It seems that for Ruby instance variables can be modelled using
>> attributes, but I couldn't see any way of handling class variables.
>> So, what is the recommended way of handling them?
>
>
> First, one takes the bat labeled "Metaclasses" and smacks the designer
> in the head with it. Then, once enlightenment has hit, we implement
> metaclasses and you add class variables as new attributes on a class'
> metaclass. I think.
>
The problem, as far as Ruby is concerned, is that it has two subtly
different types of class variable.
there are metaclass instance variables, which would be created using
this piece of evil looking code
class Example
class << self
attr_accessor :x
end
end
the class << self part accesses the metaclass Example' and then adds
accessor methods to access it's instance variable x.
However when talking about class variables in Ruby you usually mean
variables that are accessed using the notation @@x
The difference between these two methods is that if created a sub class
SubExample, using the metaclass instance variable method changing
SubExamples value of x wouldn't affect Example's copy. Whereas if you
used the class variable method, then changing @@x in SubExample does
affect the value of @@x within Example.
This is starting to sound like one of the less pleasant parts of Ruby :P.
> Alternately you can stick 'em in as plain variables in the class
> namespace, which is probably the right answer for the moment, though
> not for the long run.
Thanks, that does seem to be the best way to deal with the @@variables.
--
Mark Sparshatt
> At 6:53 PM +0100 4/8/04, Mark Sparshatt wrote:
>>I've got a couple of questions about Atrributes in Parrot.
>>
>> PDD15 says that both classes and objects have a list of attributes and
>> it is possible to add or remove attributes to a class but not an
>> object.
>>
>> Am I right in thinking that the attribute list for an object is just a
>> copy of the attribute list for the class, which is used to store the
>> objects values?
>>
>> It seems that for Ruby instance variables can be modelled using
>> attributes, but I couldn't see any way of handling class
>> variables. So, what is the recommended way of handling them?
>
> First, one takes the bat labeled "Metaclasses" and smacks the designer
> in the head with it. Then, once enlightenment has hit, we implement
> metaclasses and you add class variables as new attributes on a class'
> metaclass. I think.
Enlightenment *has* hit then?
> Alternately you can stick 'em in as plain variables in the class
> namespace, which is probably the right answer for the moment, though not
> for the long run.
I already (sort of) think of classes and objects as being 'a bit like
namespaces', so that makes a certain kind of sense.
I think so. Or I could be coming down with the flu--it's often
difficult for me to tell the difference. :)
> > Alternately you can stick 'em in as plain variables in the class
>> namespace, which is probably the right answer for the moment, though not
>> for the long run.
>
>I already (sort of) think of classes and objects as being 'a bit like
>namespaces', so that makes a certain kind of sense.
I think this is actually the right answer for class variables, but
I'm not sure as yet.