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
but role { ... }
interacts strangely with outer lexicals, and doesn't warn about it
#6139
Comments
From @smls sub a ($a) { my $x = a 42; my $y = a "Hello"; I have a suspicion that this is not a bug but rather a consequence of But the current behavior is rather LTA in cases like this. |
From @lizmatYes, this is because classes / roles are not proper closures. And yes, I’ve been bitten by this as well. To me, making them proper closures, feels like the correct solution to me. But I’ll settle for a warning / exceptione :-)
|
The RT System itself - Status changed from 'new' to 'open' |
From @jnthnOn Thu, 09 Mar 2017 07:39:39 -0800, elizabeth wrote:
It boils down to roles and classes being compile-time constructs, while closures are decidedly runtime ones. You can force a role to be re-evaluated each time by making it parametric, and passing the state as a role parameter. Note, however, that roles are interned based on the object identity of their positional parameters. This means the pattern, used on values, has a high chance of causing a memory "leak". Note that the `but RoleName($value)` syntax that mixes in the role and, if it has a single attribute, assigns $value to it, is there to make cases like this a bit more convenient.
* To clone the methods, attribute initialization closures, etc. Declaring lexical classes and roles isn't an entirely unusual practice; without some careful analysis of when we need to do the cloning, we'd end up giving programs using this pattern a huge performance regression. All to give other programs a feature that will be hard to optimize, and so will then get a (deserved) reputation for being slow and thus probably not used all that much anyway.
I think these options are worth consideration. I can't think of a false positive off hand. /jnthn |
From @timoOn 09/03/17 20:38, jnthn@jnthn.net via RT wrote:
class Test { method tester { say "testest" } } # warning: you're not allowed to close over variable &say! is there a sane heuristic for this? "does it have a & sigil" isn't sane, |
From j.david.lowe@apple.comThis short program behaves dies on my system, apparently because the mixed-in attribute is somehow "leaking" between the two threads (???): ``` await((^2).map: { produces output like: ``` Original exception: $ ./bug Original exception: It's possible that what I'm doing in this code isn't *intended* to be thread-safe, but if that's the case, I don't understand why (e.g. looking at the code, the two threads appear to be completely isolated.) More information: ``` |
From @smls@David I think this is not a thread safety issue, but rather a result of `role`s (intentionally) not being closures. I.e. a duplicate of this RT: This is a duplicate of https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130965 |
The RT System itself - Status changed from 'new' to 'open' |
From j.david.lowe@apple.comAgreed. In that case, the threads are just racing to observe a mutating value while it's in the "expected" state. I will add my voice to the chorus calling for either making roles into closures, or producing a compile-time warning or error. It's tempting to use roles to "monkey patch", and would be good to be warned if it isn't a safe thing to do. I'm fine with closing this as a duplicate.
|
Migrated from rt.perl.org#130965 (status was 'open')
Searchable as RT130965$
The text was updated successfully, but these errors were encountered: