vtable cleanup and questions

0 views
Skip to first unread message

Jonathan Worthington

unread,
Apr 6, 2007, 12:31:54 PM4/6/07
to parrot-...@perl.org
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?

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

Nicholas Clark

unread,
Apr 6, 2007, 2:14:25 PM4/6/07
to Jonathan Worthington, parrot-...@perl.org
On Fri, Apr 06, 2007 at 05:31:54PM +0100, Jonathan Worthington wrote:

> 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

Will Coleda

unread,
Apr 6, 2007, 2:37:39 PM4/6/07
to Jonathan Worthington, parrot-...@perl.org

On Apr 6, 2007, at 12:31 PM, Jonathan Worthington wrote:

> 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


Allison Randal

unread,
Apr 10, 2007, 2:32:58 AM4/10/07
to Will Coleda, Jonathan Worthington, parrot-...@perl.org
Will Coleda wrote:
> On Apr 6, 2007, at 12:31 PM, Jonathan Worthington wrote:
>
>> 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.

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

Reply all
Reply to author
Forward
0 new messages