Chip Salzenberg wrote: > What views offer are the ability to add semantics - filters - to the > aliasing. The only current use case, perhaps the only ever, is adding > read-only-ness. So after something like > > view const $v, $original; > > or whatever the syntax might be, then: > > \$v == \$original # true > $original=1; print $v # "1" > $v=1 # throws exception > I don’t really see the point of this feature, but don’t let that deter you. (On the other hand, I thought the same thing about smart match and consequently ignored it, so maybe that’s a red flag; then again, maybe not.) In any case, do views work with the no-common-vars optimisation? I.e., what will be assigned to $something_else in this case? Not 3, I hope. $original = 7; ($original,$something_else) = (3,$v); This is already a problem for aliased package vars, so it wouldn’t be a new bug. But shouldn’t we try to avoid spreading it? Maybe we need a hint flag to disable this optimisation within a lexical scope.Thread Previous | Thread Next