Ticket #2114 (new RFC)

Opened 3 years ago

Last modified 3 years ago

getprop op is strange

Reported by: whiteknight Owned by:
Priority: trivial Milestone:
Component: core Version: master
Severity: low Keywords:
Cc: Language:
Patch status: Platform: all

Description

The getprop op is strange because it has a signature getprop_p_s_p. By analogy, the getattr opcode has signature getattr_p_p_s. setprop_p_s_p and setattr_p_s_p are similar and are not a problem.

getprop_p_s_p should be changed to getprop_p_p_s for symmetry with other ops.

Also, we should take some time to reconsider the whole properties mechanism, since I don't think it is used often. It *is* used, but not often and I'm not sure that it's the best mechanism for doing what we want to do with it.

Change History

Changed 3 years ago by pmichaud

On Wed, May 18, 2011 at 03:35:10PM -0000, Parrot wrote:
>  The getprop op is strange because it has a signature getprop_p_s_p. By
>  analogy, the getattr opcode has signature getattr_p_p_s. setprop_p_s_p and
>  setattr_p_s_p are similar and are not a problem.
> 
>  getprop_p_s_p should be changed to getprop_p_p_s for symmetry with other
>  ops.

Note that Rakudo uses this opcode heavily.  

>  Also, we should take some time to reconsider the whole properties
>  mechanism, since I don't think it is used often. It *is* used, but not
>  often and I'm not sure that it's the best mechanism for doing what we want
>  to do with it.

Note that Rakudo uses this opcode heavily.  All of Rakudo's ability
to maintain container types, r/w, flattening behavior, subroutine
signatures, etc. is based on the properties mechanism.

Rakudo even has its own dynop to enable a set of PMCs to share the 
same prophash (e.g., in arrays, where all of the elements have a 
common type constraint).

So far it works well for us (if perhaps a little expensive), so
consider this a tag that says "there's at least one heavy user of
this feature" before we mess with it too much.  :-)

Pm


Changed 3 years ago by whiteknight

I knew Rakudo was using it, I wasn't sure to what extent. I'm glad to hear it is more commonly used (and without any major problems).

I would still like to change getprop_p_s_p to getprop_p_p_s. That's a small, low-priority aesthetic nit, but I wanted to keep track of the issue anyway. I marked this ticket "trivial" when I created it, so nobody needs to get worried about this quite yet.

As a follow-up, does this property system work as well as you would like it to? Are there any changes you could suggest? If we're talking about a major overhaul of the object model to begin sooner than later, object properties is something we could get right if it isn't already right.

Changed 3 years ago by pmichaud

On Thu, May 19, 2011 at 01:40:39PM -0000, Parrot wrote:
> Comment(by whiteknight):
> 
>  I knew Rakudo was using it, I wasn't sure to what extent. I'm glad to hear
>  it is more commonly used (and without any major problems).
> 
>  I would still like to change getprop_p_s_p to getprop_p_p_s. 

This should be no problem -- add getprop_p_p_s now, give clients
(like Rakudo) a supported release or two to make the switch, then
eliminate getprop_p_s_p.

FWIW, getprop's inconsistent with other ops has always struck me as
odd as well, so I'm fine with the proposed change.

>  As a follow-up, does this property system work as well as you would like
>  it to? Are there any changes you could suggest? If we're talking about a
>  major overhaul of the object model to begin sooner than later, object
>  properties is something we could get right if it isn't already right.

We probably won't know entirely until we have Rakudo completely switched
over to the new system, although Jonathan might have some insights to
share here.

Pm

Note: See TracTickets for help on using tickets.