I'm adding the new vtable entries required for PDD15. A few questions.
1) become_parent we agreed should go. It appears to be completely unused
anywhere in the repository (languages included). Should we take that as
evidence enough to just kill it, or go for a standard deprecation cycle?
2) I think we agreed that the subclass vtable method should go too, but
the current ParrotClass and ParrotObject use it, so we can't deprecate
that until we deprecate those. Note that it is only impelmented in
default.pmc.
3) I just discovered we also have:
PMC* new_singleton()
PMC* get_anonymous_subclass()
I marked them unspecified. Neither of them are implemented by any PMCs
in the repository - not even default. Should they go?
4) We have:
PMC* get_attr(INTVAL idx)
void set_attr(INTVAL idx, PMC* value) :write
I guess, like subclass, these are things we plan to deprecate along with
ParrotClass and ParrotObject once folks are all using the PDD 15
implementation, since attribute lookup is by name now? Or do we leave
them for other languages that might want integer indexed attribute
lookup, but just not implement them in our own class system?
Thanks,
Jonathan
> 1) become_parent we agreed should go. It appears to be completely unused
> anywhere in the repository (languages included). Should we take that as
> evidence enough to just kill it, or go for a standard deprecation cycle?
Well, it seems to be unused anywhere that Google's tentacles reach to:
http://www.google.com/codesearch?q=become_parent
Nicholas Clark
> Hi,
>
> I'm adding the new vtable entries required for PDD15. A few questions.
>
> 1) become_parent we agreed should go. It appears to be completely
> unused anywhere in the repository (languages included). Should we
> take that as evidence enough to just kill it, or go for a standard
> deprecation cycle?
Standard cycle, which means it'll be gone in 11 days or so.
> 2) I think we agreed that the subclass vtable method should go too,
> but the current ParrotClass and ParrotObject use it, so we can't
> deprecate that until we deprecate those. Note that it is only
> impelmented in default.pmc.
>
> 3) I just discovered we also have:
>
> PMC* new_singleton()
> PMC* get_anonymous_subclass()
>
> I marked them unspecified. Neither of them are implemented by any
> PMCs in the repository - not even default. Should they go?
>
> 4) We have:
> PMC* get_attr(INTVAL idx)
> void set_attr(INTVAL idx, PMC* value) :write
> I guess, like subclass, these are things we plan to deprecate along
> with ParrotClass and ParrotObject once folks are all using the PDD
> 15 implementation, since attribute lookup is by name now? Or do we
> leave them for other languages that might want integer indexed
> attribute lookup, but just not implement them in our own class system?
>
> Thanks,
>
> Jonathan
>
--
Will "Coke" Coleda
wi...@coleda.com
Yes, standard cycle. Get the deprecation note into DEPRECATED.pod before
the next release.
>> 2) I think we agreed that the subclass vtable method should go too,
>> but the current ParrotClass and ParrotObject use it, so we can't
>> deprecate that until we deprecate those. Note that it is only
>> impelmented in default.pmc.
Yes, it's adequately handled by add_parent, no need for both.
>> 3) I just discovered we also have:
>>
>> PMC* new_singleton()
>> PMC* get_anonymous_subclass()
>>
>> I marked them unspecified. Neither of them are implemented by any PMCs
>> in the repository - not even default. Should they go?
Yes. I'd say they're a case of being overly prepared for possible future
needs. Both can be adequately handled by passing in options to 'new', or
(for singletons) altering the instantiation code in the class (if all
instantiations are singletons).
>> 4) We have:
>> PMC* get_attr(INTVAL idx)
>> void set_attr(INTVAL idx, PMC* value) :write
>> I guess, like subclass, these are things we plan to deprecate along
>> with ParrotClass and ParrotObject once folks are all using the PDD 15
>> implementation, since attribute lookup is by name now? Or do we leave
>> them for other languages that might want integer indexed attribute
>> lookup, but just not implement them in our own class system?
Let's go ahead and deprecate them (when we do the full change to PDD
15). We can bring them back at some point if absolutely necessary.
Allison