Skip Menu |
Report information
Id: 127236
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: lloyd.fourn [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Attribute.package is wrong for attributes declared inside roles
To: "rakudobug [...] perl.org" <rakudobug [...] perl.org>
From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
Date: Mon, 11 Jan 2016 13:45:47 +0000

role Foo { has $.foo; }; Foo.^attributes[0].package.^name.say #->$?CLASS

From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
To: perl6-compiler [...] perl.org, bugs-bitbucket [...] rt.perl.org
Date: Mon, 11 Jan 2016 15:00:37 +0000
Subject: Re: [perl #127236] Attribute.package is wrong for attributes declared inside roles
Download (untitled) / with headers
text/plain 1.6k
Since timtimo++ saw this ticket and tried to ping me on IRC I'm going to explain why I wanted this to work. See: 

And in particular this commit.
https://github.com/LLFourn/p6-AttrX-InitArg/commit/ffd5e962020d85595b2c2edd08f3900999944899

I was using Attribute.package to figure out the class that I should apply the "InitArgContainer" role to. I found that this didn't work with roles because $attr.package was a GenericHOW. So instead I used a compiler hack ($*PACKAGE), which worked perfectly.

If MOP introspection doesn't work, compiler introspection will. I think it would be better if the former had the power so I could avoid the latter.

 I think Perl 6 is conflating the notion of a 'package' and a 'class':

role Foo { has $.a }; class Bar does Foo { }; Bar.^attributes[0].package.say

#-> Bar

To me that should be Foo. It was declared in Foo. This is important for introspection related to auto-documentation. If I want to produce documentation for a class, I want to know where it's attributes and methods came from, ie which file, which module, in which package.

I'm totally fine if this is NOTABUG for now, I didn't know there was this theme of roles are not real packages. I knew of course they weren't real classes ( which is why It was supprising when I found I could .new them!)

LL


On Tue, Jan 12, 2016 at 12:46 AM Lloyd Fournier <perl6-bugs-followup@perl.org> wrote:
Show quoted text
# New Ticket Created by  Lloyd Fournier
# Please include the string:  [perl #127236]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=127236 >


role Foo { has $.foo; }; Foo.^attributes[0].package.^name.say #->$?CLASS
Date: Mon, 11 Jan 2016 15:49:07 +0000
Subject: Re: [perl #127236] Attribute.package is wrong for attributes declared inside roles
To: perl6-compiler [...] perl.org, bugs-bitbucket [...] rt.perl.org
From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
To add to the confusion:

role Foo { method meth { } }; class Bar does Foo { }; Bar.^find_method("meth").package.say
(Foo)

so methods behave as I expect but attributes don't. 



On Tue, Jan 12, 2016 at 2:00 AM Lloyd Fournier <lloyd.fourn@gmail.com> wrote:
Show quoted text
Since timtimo++ saw this ticket and tried to ping me on IRC I'm going to explain why I wanted this to work. See: 

And in particular this commit.
https://github.com/LLFourn/p6-AttrX-InitArg/commit/ffd5e962020d85595b2c2edd08f3900999944899

I was using Attribute.package to figure out the class that I should apply the "InitArgContainer" role to. I found that this didn't work with roles because $attr.package was a GenericHOW. So instead I used a compiler hack ($*PACKAGE), which worked perfectly.

If MOP introspection doesn't work, compiler introspection will. I think it would be better if the former had the power so I could avoid the latter.

 I think Perl 6 is conflating the notion of a 'package' and a 'class':

role Foo { has $.a }; class Bar does Foo { }; Bar.^attributes[0].package.say

#-> Bar

To me that should be Foo. It was declared in Foo. This is important for introspection related to auto-documentation. If I want to produce documentation for a class, I want to know where it's attributes and methods came from, ie which file, which module, in which package.

I'm totally fine if this is NOTABUG for now, I didn't know there was this theme of roles are not real packages. I knew of course they weren't real classes ( which is why It was supprising when I found I could .new them!)

LL


On Tue, Jan 12, 2016 at 12:46 AM Lloyd Fournier <perl6-bugs-followup@perl.org> wrote:
# New Ticket Created by  Lloyd Fournier
# Please include the string:  [perl #127236]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=127236 >


role Foo { has $.foo; }; Foo.^attributes[0].package.^name.say #->$?CLASS
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 695b
On Mon Jan 11 05:46:19 2016, lloyd.fourn@gmail.com wrote: Show quoted text
> role Foo { has $.foo; }; Foo.^attributes[0].package.^name.say #->$?CLASS
Just to note that this behavior is intentional rather than accidental (or at least, *I* intended it :-)). Roles undergo generic instantiation at the point of being composed into a class, during which the package is substituted for the type of the class itself. This is important for things like accessor generation to work, since after composition the attributes need to be resolved as if they really are in the class. We might want a declaring-package that is non-generic, if there's a strong enough use case. And the method inconsistency may want resolving.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org