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
Z Metaoperator bug #6586
Comments
From ipatrol6010@yahoo.comAs per a discussion on the IRC channel, I am requesting that a regression bug be filed regarding the incorrect handling of variables referenced to packages by the Z and X meta-operators. The behavior over time is detailed here: Of those, the result given from 2015.09 to 2015.11 is the correct and desired behavior, considering the design documents. Doing a bisection: The regression revision appears to be: --ipatrol |
From @jnthnOn Sun, 08 Oct 2017 19:13:34 -0700, ipatrol6010@yahoo.com wrote:
I think Z and X are doing the right thing: treating something in a Scalar container as a single item. This is done consistently across the language, so you'll observe this behavior in many more constructs. The surprise here is that we get a Scalar container in the first place: $ perl6-m -e 'my @A::B = (1..8); say @A::B.VAR.WHAT; my @B = (1..8); say @B.VAR.WHAT' I suspect that's happening because a package's symbol table is a Stash, which is just a subclass of Hash, and this code is relying on autovivification, which always involves a Scalar container. It probably should instead, somehow, be arranging than an Array is bound directly into the Stash. Then Z, X, and plenty more things would work less surprisingly. A `my %A::B` is likely exhibiting the same kind of problem at the moment too. |
The RT System itself - Status changed from 'new' to 'open' |
From @lizmat
FWIW, I think this is not a matter of a Array being wrapped into a Scalar. my @A::B and my %A::B *are* scalars, regardless of their sigil. Feels like a case of sigil inspection on the last element of split ‘::’ on the full name, instead of on the first. |
Migrated from rt.perl.org#132248 (status was 'open')
Searchable as RT132248$
The text was updated successfully, but these errors were encountered: