Front page | perl.perl5.porters |
Postings from July 2011
On Jul 10, 2011, at 1:41 PM, Reverend Chip wrote:
> On 7/10/2011 12:14 PM, Father Chrysostomos wrote:
>> 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.)
>
> Intuition counts, but needs balance.
>
> The point of this feature is specifically so that method foo ($a)
> {...} can have $a not be a copy (this is for speed), but also prevent
> accidentally modifying the original (this is for safety). It's
> "read-only aliasing", the default mode of parameter passing in Perl 6.
> Shirley having to choose between slow names and fast and unsafe @_ is a
> situation that needs fixing.
>
> Does that help?
It just made me think more and come up with other observations:
I thought the whole point of function signatures was to avoid having to write:
sub foo {
for my $x (shift) {
for my $y (shift) {
for my $z (shift) {
...
}
}
}
}
If you make them read-only it defeats the purpose of having an alias.
If you want something more efficient than copying, we have copy-on-write for strings. Can we make perl use that more often? And isn’t copying an RV or a number just as fast as making a view?
I can’t speak for Perl 6, but making something read-only in Perl 5 just feels un-Perl-5-ish. After all, we allow $^X assignment.
And if someone *really* wants them read-only, a copy can be made so.
>
>> 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...
>
> The no-common-vars optimization works strictly by name? Feh. Perhaps
> you're right about the pragma, or perhaps we can just have users use do
I meant not a pragma in the sense of ‘use whatever’, but for the hint to be turned on automatically. But that won’t help if a reference to a bound scalar is returned to a scope without that hint. However, now we have a use for ‘use less "buginess"’.
> BLOCK as a workaround since it makes temp copies that can have their
> contents stolen, reducing the waste:
>
> ($original,$something_else) = do { 3,$v };
Thread Previous
|
Thread Next