Re: cvs commit: parrot vtable.tbl
Sam Ruby
> Sam Ruby wrote:
>
>> Leopold Toetsch wrote:
>>
>>> cvsuser 04/12/15 02:36:29
>>>
>>> Modified: . vtable.tbl
>>> Log:
>>> stub in object vtables
>>
>> [snip]
>>
>>> +void add_parent(PMC* parent)
>>> +void become_parent(PMC* class)
>>> +INTVAL class_type()
>>> +void add_method(STRING* method)
>>> +void remove_method(STRING* method)
>>> +STRING* namespace_name()
>>> +PMC* new_singleton()
>>> +PMC* get_anonymous_subclass()
>>
>> Cool. Are there plans for opcodes? I could make use of add_parent
>> and add_method...
>
> add_parent has already an opcode C<addparent>. add_method should
> probably get one, yes. But add_method is a bit more complicated. It's
> called automatically during bytecode loading, *if* the class is already
> existing. E.g.
>
> .namespace ["Integer"]
> .sub hex method
>
> but the problem is code like this:
>
> newclass cl, "Foo"
> ...
> .namespace ["Foo"]
> .sub foo method
>
> now the class isn't constructed, when the bytecode is loaded and the old
> Parrot_store_global is used. But if you load the method code with
> load_bytecode again add_method is called.
My need is to be able to call add_method for methods defined as @ANON.
From the perspective of Parrot, namespaces should be viewed a perfectly
reasonable mechanism for implementing classes, and there perhaps should
even be special support for enabling classes to be defined that way...
but: there should be no built in assumptions that all classes are
defined in this way.
- Sam Ruby
Leopold Toetsch
> My need is to be able to call add_method for methods defined as @ANON.
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
> From the perspective of Parrot, namespaces should be viewed a perfectly
> reasonable mechanism for implementing classes, and there perhaps should
> even be special support for enabling classes to be defined that way...
> but: there should be no built in assumptions that all classes are
> defined in this way.
Yes. But OTOH a different scheme should only be used if it's unavoidable.
> - Sam Ruby
leo
Sam Ruby
> Sam Ruby wrote:
>
>> My need is to be able to call add_method for methods defined as @ANON.
>
> This doesn't make sense to me. The @ANON pragma avoids the add_method
> (or store_global) call in the first place.
I don't want the method added to a namespace, or stored as a global. I
want it stored as a property of a class object.
>> From the perspective of Parrot, namespaces should be viewed a
>> perfectly reasonable mechanism for implementing classes, and there
>> perhaps should even be special support for enabling classes to be
>> defined that way... but: there should be no built in assumptions that
>> all classes are defined in this way.
>
> Yes. But OTOH a different scheme should only be used if it's unavoidable.
Python classes are not namespaces. Nor are they global. They are
dictionaries.
Take a look at the last test in
parrot/languages/python/t/basic/oo_class.t to get an idea of what I am
talking about.
- Sam Ruby
Leopold Toetsch
>>
>> This doesn't make sense to me. The @ANON pragma avoids the add_method
>> (or store_global) call in the first place.
> I don't want the method added to a namespace, or stored as a global. I
> want it stored as a property of a class object.
I presumed that ;) Well, due to the described problem (class exists
already or not) that's for now a good alternative
> Python classes are not namespaces. Nor are they global. They are
> dictionaries.
Or, the view is a dictionary-like. The dict is CPython's implementation.
I can imagine that Parrot's class namespaces work as well.
> Take a look at the last test in
> parrot/languages/python/t/basic/oo_class.t to get an idea of what I am
> talking about.
Well, that just depends on how you implement attribute access, as far as
I can see.
> - Sam Ruby
leo
Sam Ruby
>> Python classes are not namespaces. Nor are they global. They are
>> dictionaries.
>
> Or, the view is a dictionary-like. The dict is CPython's implementation.
> I can imagine that Parrot's class namespaces work as well.
Are namespaces subject to garbage collection? Classes may be created on
the fly in Python, and disapear just as quickly.
>> Take a look at the last test in
>> parrot/languages/python/t/basic/oo_class.t to get an idea of what I am
>> talking about.
>
> Well, that just depends on how you implement attribute access, as far as
> I can see.
In the example, two objects with the same class have different
implementations of a given method.
Furthermore, every assignment to any property of any instance has the
potential of invalidating whatever caches you may have.
- Sam Ruby
Leopold Toetsch
> Are namespaces subject to garbage collection? Classes may be created on
> the fly in Python, and disapear just as quickly.
In Python as well as in Perl. We have to deal with that anyway. Perl6
has the notion of lexically scoped multimethods. Operator overloading
only for one specific scope.
> In the example, two objects with the same class have different
> implementations of a given method.
Fine. The find_method call has to consult the properties of the object too.
> Furthermore, every assignment to any property of any instance has the
> potential of invalidating whatever caches you may have.
The assignment of a Sub PMC, yes. But if your implementation of
find_method is able to locate a method now, you know already where and
in which order you are searching. And if the implementation can overload
e.g. a "add" method, you know where you have to call add_method to
achieve that effect.
I don't see a problem here. Worst case is an uncached find_method call
as you are doing now anyway in e.g. PyClass.
> - Sam Ruby
leo