Darren Duncan [EMAIL PROTECTED] writes:
At 7:10 AM +0100 3/29/05, Piers Cawley wrote:
Doesn't that rather depend on the type of the attribute? Personally, if I get
an object back from accessor method then I expect that any modifications of
that object's state will be seen the next time I look at
Darren Duncan [EMAIL PROTECTED] writes:
At 11:26 PM -0700 3/16/05, Luke Palmer wrote:
For each of the above cases, is a copy of or a reference to the
attribute returned? For each, will the calling code be able to
modify $obj's attributes by modifying the return values, or not?
Well if
At 7:10 AM +0100 3/29/05, Piers Cawley wrote:
Doesn't that rather depend on the type of the attribute? Personally, if I get
an object back from accessor method then I expect that any modifications of
that object's state will be seen the next time I look at the results of that
accessor method. This
On Thu, Mar 17, 2005 at 07:21:18PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: That's actually weirdly symmetrical with the notion that only subs can
: impose compile-time context on their arguments, while methods always
: have to assume list context because you have to generate the
I suppose, generally ignore most of my last comments as they seem to
be ill-informed.
There's just one thing I need to know that will make everything clear:
Does 'return' always impose a scalar context on its arguments? Has
this been decided for sure, or is it still under debate?
If it does,
I was just informed by IRC that 'return' propagates the context of the caller.
If that's the case, then we can just drop this discussion, problems solved.
Sorry for wasting your time.
-- Darren Duncan
At 12:07 AM -0800 3/18/05, Darren Duncan wrote:
I suppose, generally ignore most of my last
Larry Wall writes:
Perl 5 always makes a copy of return values, but that just turns
out to not matter for references, since a copy of a reference is as
good as the original reference. Perl 5 also propagates scalar/list
context into subs. For $:foo it doesn't matter--it always behaves
as a
On Thu, Mar 17, 2005 at 02:06:46AM -0700, Luke Palmer wrote:
: I'll just point out, the rest of this message, with all the autocopy
: complexity (according to /some/ people), uses this assumption. It all
: happily goes away if $self.:bar returns a list if @:bar is declared.
: And I can't, off
Thank you, Luke and Larry, for your replies. They did help.
For now, I will use the syntax $obj.:bar[] and $obj.:baz{} in the
get_bar|baz() accessor methods to get copies returned; if the rules
change again, I'll update later.
I noticed that the example seemed incomplete, saying only what
Larry Wall wrote:
That's actually weirdly symmetrical with the notion that only subs can
impose compile-time context on their arguments, while methods always
have to assume list context because you have to generate the argument
list before you can know which method you're going to dispatch to.
It occurs to me that I may have requested something before that would
cause more problems than it solves if implemented. So I have a
different idea that would hopefully be efficient, powerful, and easy
to learn. In short, make it work much like Perl 5.
The idea is Perl methods and subs will
As an addendum, my idea would also apply to non-attribute variables.
If you say 'my %abc' in a method or sub, and later say 'return %abc',
then a reference to %abc will be returned by default.
So its not like I'm treating attributes differently.
-- Darren Duncan
At 3:27 PM -0800 3/17/05, Darren
Darren Duncan writes:
I need some clarification on the semantics of subroutine or method
return statements, regarding whether copies or references are
returned. It will help me in my p6ification of p5 code.
Say I had a class with 3 private attributes, named [$:foo, @:bar,
%:baz], and I
At 11:26 PM -0700 3/16/05, Luke Palmer wrote:
For each of the above cases, is a copy of or a reference to the
attribute returned? For each, will the calling code be able to
modify $obj's attributes by modifying the return values, or not?
Well if you're making accessors, why the heck are you
On Wed, Mar 16, 2005 at 09:49:47PM -0800, Darren Duncan wrote:
: I need some clarification on the semantics of subroutine or method
: return statements, regarding whether copies or references are
: returned. It will help me in my p6ification of p5 code.
:
: Say I had a class with 3 private
On Wed, Mar 16, 2005 at 11:10:40PM -0800, Darren Duncan wrote:
: When I last asked a related question here, I was told that simply
: returning an attribute will allow the caller to modify the original
: attribute by default.
That used to be true for arrays and hashes, but I just changed my
mind
16 matches
Mail list logo
