Re: What the [sub]in 'L value do they have?

I mainly agree with the objections to lvalue subs as an OO mechanism. They impose a syntax which exposes the implementation, and they allow direct accesss to data to be exported. As you say, constraint checking is not possible.

The lvalue attribute means that the represented value is modifiable, not just assignable. Consider the following:

{
    my $foo = 'boo' . $/;
    sub foo () : lvalue { $foo }
}
chomp foo;
foo =~ s/o/r/;
print foo;
[download]

What will your visible future foo be in these cases? Your proposals all seem to require that the lvalue sub know a lot about the operators that bind it. It appears that that will produce a very heavy and baroque kind of attribute.

I think that the lvalue attribute should be retained as the overloading mechanism that it is, and its use for exporting data recognized for its own properties. The fact that it is unsuitable for strict OO does not make it useless or harmful.

After Compline,
Zaxo

Comment on Re: What the [sub]in 'L value do they have? Download Code

Replies are listed 'Best First'.
Re: Re: What the [sub]in 'L value do they have? by BrowserUk (Patriarch) on Dec 16, 2002 at 02:02 UTC
Given the way :lvalue works now, I came to the same conclusion, but then I set about trying to understand what uses it did have, procedural code or otherwise and I came up empty. For a good, practical use anyway, but the documentation is sparse to put it mildy, which is why I decided to move my questions and thoughts away from the original thread. The fact that I can modify the original entity directly through an lvalue sub may be an optimisation, but I don't see `substr($foo, 3, 2) = 'fred';` as intrinsically different from `substr($foo, 3, 2, 'fred');` I had never thought of doing nor encountered anything that did: `$s = "the quick brown fox"; substr($s, 4, 5) =~ s/ick/iet/; print $s; the quiet brown fox` [download] And that does have some interesting possibilities and is exactly the sort answer I was looking for. I'd like to see a real use for it and the benefits thereof described, but in the absence, you've given me a new way to look at a facility of perl that I long been intrigued by but have singularly failed to find a good use for. That said, I still like the syntactic possibility of lvalue assignment for mutators and the only thing stopping that is the exposure of information that the compiler/interpreter has available to it. As I can see at least two ways of making that information available that would not affect its current usage in anyway, and would not break any existing code, I wonder if this would be such a hard thing to do and what objections there could be to doing it? Like many features of perl, noone would be forced to use it, but it would give those that would like to (Ie. ME:^) another way to do things. Examine what is said, not who speaks.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: What the [sub]in 'L value do they have?
by BrowserUk (Patriarch) on Dec 16, 2002 at 02:02 UTC

Given the way :lvalue works now, I came to the same conclusion, but then I set about trying to understand what uses it did have, procedural code or otherwise and I came up empty. For a good, practical use anyway, but the documentation is sparse to put it mildy, which is why I decided to move my questions and thoughts away from the original thread.

The fact that I can modify the original entity directly through an lvalue sub may be an optimisation, but I don't see substr($foo, 3, 2) = 'fred'; as intrinsically different from substr($foo, 3, 2, 'fred'); I had never thought of doing nor encountered anything that did:

$s = "the quick brown fox";
substr($s, 4, 5) =~ s/ick/iet/;
print $s;
the quiet brown fox
[download]

And that does have some interesting possibilities and is exactly the sort answer I was looking for. I'd like to see a real use for it and the benefits thereof described, but in the absence, you've given me a new way to look at a facility of perl that I long been intrigued by but have singularly failed to find a good use for.

That said, I still like the syntactic possibility of lvalue assignment for mutators and the only thing stopping that is the exposure of information that the compiler/interpreter has available to it. As I can see at least two ways of making that information available that would not affect its current usage in anyway, and would not break any existing code, I wonder if this would be such a hard thing to do and what objections there could be to doing it?

Like many features of perl, noone would be forced to use it, but it would give those that would like to (Ie. ME:^) another way to do things.

Examine what is said, not who speaks.

[reply]
[d/l]
[select]