New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EXPORT ignored when unit module/package is used #5063
Comments
From @gfldex# https://gist.github.com/b0d44595e0d3b314a09d # Module.pm6 sub EXPORT ($var) { # use-module.p6 use v6; # OUTPUT: # Package.pm6 unit package Package; sub EXPORT ($var) { # use-package.p6 use v6; # OUTPUT: # expected: either complain about unit and EXPORT in the same file or |
From @jnthnOn Sun Jan 17 22:29:57 2016, gfldex wrote:
&EXPORT must be in the outermost lexical scope of the compilation unit. Which...uh...it appears it should be here! I suspect the compiler is sneaking a secret extra scope in as a result of the unit declaration. Can we fix that? Yes for module/class/grammar. But for roles, not really as they're generic and the parameter has to go somewhere. But that makes a weird discontinuity. Hmmm. :-) |
The RT System itself - Status changed from 'new' to 'open' |
From @LLFournI am going to sneak in a docs discussion into this ticket with regards to http://docs.perl6.org/language/modules#EXPORT I mentioned when I wrote it: Of course, happy for that to change. With my more nuanced understanding of "for EXPORT to be called it must be defined at UNIT::&EXPORT. Therefore it Maybe if a package is declared as UNIT, all its lexical symbols could be gfldex, I see you've edited the second EXPORT example, but to me it's made Thanks! On Tue, Jan 19, 2016 at 5:03 AM jnthn@jnthn.net via RT <
|
From @gfldexOn Mon, 18 Jan 2016, Lloyd Fournier via RT wrote:
I'm not happy with that example myself and intend to change it.
I do not agree with the notion "Let's not tell them!". The whole point of |
From @LLFourngfldex++ for blogging. My basic feeling about documentation is that it should: 1. Explain the construct, it's purpose and behaviour. The original example was there to explain that you would not get DEFAULT Though, I agree with you that type captures in EXPORT are worth showing, Feel free to make changes as always. And thanks for your contributions! I suppose we should leave this ticket for the bug now ;) On Thu, Jan 21, 2016 at 12:59 AM Wenzel P. P. Peppmeyer <
|
From @tbrowderIn a conversation about this issue on IRC channel #perl6 on 25 Oct 2016 starting at approx 06:24, module authors and users express concern about modules polluting the user's namespace. Several main desires IMHO: User: 1. Selective import by object name(s) or tag(s). 2. Selective import by excluding object name(s) or tag(s) [perlpilot]. Author: 1. Tagging or otherwise marking subs to enable the user desires above. 2. Enable multiple export tags to better organize export categories. |
1 similar comment
From @tbrowderIn a conversation about this issue on IRC channel #perl6 on 25 Oct 2016 starting at approx 06:24, module authors and users express concern about modules polluting the user's namespace. Several main desires IMHO: User: 1. Selective import by object name(s) or tag(s). 2. Selective import by excluding object name(s) or tag(s) [perlpilot]. Author: 1. Tagging or otherwise marking subs to enable the user desires above. 2. Enable multiple export tags to better organize export categories. |
From @tbrowderOn Tue Oct 25 06:07:15 2016, tbrowder wrote:
The URL to the thread start is: |
From @tbrowderOn Tue Oct 25 06:07:15 2016, tbrowder wrote:
Note that selective import by tag is possible now if the author tags each subroutine export trait with the sub name or an alias or both.
This is possible now for import selection, but not import by exclusion.
Disregard, this is possible now. |
From @skidsOn Tue, 25 Oct 2016 08:22:19 -0700, tbrowder wrote:
Well, mostly. Note you still cannot export different values for the same symbol $ perl6 -e 'unit module foo; my class A { my class A is export(:foo1) { }; }; my class B { my class A is export(:foo2) { } }' |
Migrated from rt.perl.org#127305 (status was 'open')
Searchable as RT127305$
The text was updated successfully, but these errors were encountered: