#483: :invocant flag
-------------------+--------------------------------------------------------
 Reporter:  coke   |        Owner:  whiteknight
     Type:  todo   |       Status:  closed     
 Priority:  minor  |    Milestone:             
Component:  core   |      Version:  master     
 Severity:  low    |   Resolution:  wontfix    
 Keywords:  pcc    |         Lang:             
    Patch:         |     Platform:  all        
-------------------+--------------------------------------------------------
Changes (by whiteknight):

  * status:  assigned => closed
  * resolution:  => wontfix


Comment:

 I've been looking at this ticket and am coming to a few conclusions:
 1) It doesn't make any sense to jam this logic into fill_params. That
 function is already too large without adding a bunch of additional special
 cases.
 2) IMCC or another PIR compiler already prepends the invocant to the list
 of passed arguments, so this part of the logic already exists. The only
 thing :invocant will allow us to change is the *human readable* name of
 the variable that the invocant is stored in. This is strictly in the
 purview of the compiler, not libparrot or PCC.
 3) A lot of logic in IMCC relies on the fact that the invocant is named
 "self". Changing this to be a variable is going to introduce a lot of pain
 that we don't really want to deal with.

 I don't think we want to implement :invocant in the current system now.

 That said, there are still use-cases where we would like to obtain a
 reference to the current invocant object without relying on the "self"
 keyword in PIR or any particular behavior in IMCC. For that, I think we
 can do this little sequence:

 {{{
 .param pmc signature :call_sig
 .local pmc me
 me = getattribute signature, "current_object"
 }}}

 I don't see any value for doing this on the caller-side, since we could
 easily replace this:

 {{{
 $P0($P1 :invocant)
 }}}

 with this:

 {{{
 $P1.$P0()
 }}}

 I am going to remove references to :invocant from the docs and examples,
 and then close this ticket. If we decide that we really want to implement
 this feature, we can re-open this ticket or (preferrably) open a new
 ticket with specific details about how it should be done.

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/483#comment:9>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets

Reply via email to