On Tue, Feb 26, 2008 at 7:08 PM, Allison Randal <[EMAIL PROTECTED]> wrote:

> Andrew Parker via RT wrote:
> > On Thu Jun 28 16:34:17 2007, [EMAIL PROTECTED] wrote:
> >> While comparing pdd15_objects compared to the tests located in
> >> t/pdd15oo we cannot find evidence the following tests exist:
> >> callmethodsupercc
> >> callmethodnextcc
> >> newclass
> >> get_class
> >> removeparent
> >> removeattribute
> >> addrole
> >
> > I just ran into these docs being wrong.  It appears that it is not
> simply that there are missing
> > tests, but missing implementations as well.  I have found no other
> references, except in
> > PDD15, to the following ops:
> >
> >    * callmethodsupercc
> >    * callmethodnextcc
>
> The ops were added in PDD 15, but haven't been implemented yet. The docs
> are correct, the implementation needs to be updated.
>
> > After stumbling across the Super PMC I suspect that those two ops are
> not going to be
> > supported. Super seems to support callmethodsupercc, though, but I don't
> see support for
> > callmethodnextcc anywhere.  I've attached a patch to remove these 2 ops
> from PDD15.
>
> Super PMC will be deprecated (or at least greatly changed). It's an old
> attempt at parent proxying and can never work properly as currently
> implemented.
>
> > These ops look to still not be in any tests:
> >
> >    * removeparent
> >    * removeattribute
> >
> > After looking a bit closer into these (and trying to write a test for
> removeparent) I came
> > across RT#50646.  It appears that removeparent may not be getting
> implemented.  The
> > implementation of removeattribute is currently:
> >
> >   real_exception(interp, NULL, UNIMPLEMENTED, "removeattribute is not
> implemented");
>
> Not yet implemented.
>
> In theory, these are logical features to have. In practice, they're not
>  used by our target languages (or any language that I'm aware of). I
> suspect that the future of dynamically recomposing classes is more
> likely to take the form of combining sets of roles in various different
> ways, rather than manually deleting a parent, role, or attribute from an
> existing class.
>
> Show of hands for language implementors that need the ability to remove
> a parent or attribute from a class?
>

A quick google found me this:

<SCRIPT LANGUAGE="JavaScript">
<!--
var objBody = document.getElementsByTagName('BODY').item(0);
var remAttr = objBody.removeAttribute('bgcolor');
-->
</SCRIPT>

JavaScript/ecmascript is a language on Parrot. Although there may be
different solutions to achieve the same effect (as ecmascript's object
system is prototype-based, iirc), I do think it'd be good to implement these
functions.

I can think of situations in which removal of attributes and parents for
certain (and I barely dare to use the word these days :-) domain-specific
languages that target parrot.

Of course, if the same behavior of removing a parent/attr. can be achieved
through a different mechanism (than this single op), that would be fine too,
as long as parrot offers the functionality.

kjs


>
> Allison
>

Reply via email to