Re: "Can't return a temporary from lvalue subroutine..."
- From: Brian McCauley <nobull@xxxxxxxx>
- Date: Tue, 19 Jul 2005 19:17:05 +0100
Anno Siegel wrote:
I suppose your motivation is that you like the idea of lvalue methods,
but need more control over what gets stored by careless users in your
sensitive objects. A similar problem exists with objects that expose
(parts of) their interior though overloading a dereference operator,
say %{}. Like lvalues, it gives you pretty syntax, but leaves your
objects wide open. I have used tied hashes to correct this (that is,
returned a reference to a tied hash in response to %{ $obj}, and haven't
encountered the particular difficulty you're seeing. That may be
an alternative approach.
Here be dragons.
There are bugs in Perl. In particular if the reference returned by the %{} overload is the only reference to the tied hash some very nasty things happen very soon. Even if it's not, nasty things seem to happen after a while.
I wrote whole load of in-house classes that used this API technique and then had to labourously go through all our programs to use a direct method-call API rather than the overload-tie API.
.
- Follow-Ups:
- Re: "Can't return a temporary from lvalue subroutine..."
- From: Ilya Zakharevich
- Re: "Can't return a temporary from lvalue subroutine..."
- From: Anno Siegel
- Re: "Can't return a temporary from lvalue subroutine..."
- References:
- "Can't return a temporary from lvalue subroutine..."
- From: J Krugman
- Re: "Can't return a temporary from lvalue subroutine..."
- From: Anno Siegel
- "Can't return a temporary from lvalue subroutine..."
- Prev by Date: Re: "Can't return a temporary from lvalue subroutine..."
- Next by Date: Re: Expanding tree paths
- Previous by thread: Re: "Can't return a temporary from lvalue subroutine..."
- Next by thread: Re: "Can't return a temporary from lvalue subroutine..."
- Index(es):
Relevant Pages
|