On Mon, Jun 11, 2001 at 10:39:51PM -0500, David L. Nicol wrote:
Hopefully, we'll get a with operator and everything:
with %database.$accountnumber {
.interestearned += $interestrate * .balance
}
anything short of that, in my opinion, is merely trading old
Graham wrote:
Now I may be wrong here, but I thought I remembered something about
.foo being the same as $_.foo
It's certainly a possibility.
In which case you could do
for (%database.$accountnumber) {
.interestearned += $interestrate *
Damian Conway wrote:
Graham wrote:
Now I may be wrong here, but I thought I remembered something about
.foo being the same as $_.foo
It's certainly a possibility.
In which case you could do
for (%database.$accountnumber) {
Simon asked:
Are properties subscriptable? (Can the value of a property be a
reference that can be dereferenced?)
Property values can be any scalar value, including array, hash, and code refs.
Can properties have properties?
No, but their scalar values can.
Damian
Graham asked:
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This is intended. I'm not
On Tue, Jun 12, 2001 at 09:08:04AM +1000, Damian Conway wrote:
Can properties have properties?
No, but their scalar values can.
What I was asking, in a roundabout way, was if
$foo.bar.baz
makes sense; your answer suggests that it does. In which case, we can
teach the parser that a
What I was asking, in a roundabout way, was if
$foo.bar.baz
makes sense; your answer suggests that it does. In which case, we can
teach the parser that a property query is just like a method call is
just like a hash or array element (with optional dereference if you're
On Tue, Jun 12, 2001 at 09:20:20AM +1000, Damian Conway wrote:
Subscripts don't fit here at all. And, in my option, shouldn't be made too.
Oh good, I was hoping you would say that; I misunderstood your message from
the 7th of June further up this thread to mean that dot was optional in
Damian Conway wrote:
Graham asked:
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
Damian Conway wrote:
$ref.{a}can be $ref{a}
which can also be
$ref.a
Dereferencing a hashref is the same as accessing a property?
I hope not.
--
Did you know that 1 barn yard atmosphere =
On Thu, Jun 07, 2001 at 08:15:46AM +0100, Simon Cozens wrote:
On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
Damian Conway wrote:
$ref.{a}can be $ref{a}
which can also be
$ref.a
Dereferencing a hashref is the same as accessing a property?
$ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
Err..no.
$ref.{a}/$ref{a} is an access on a hash element through the hashref in $ref.
$ref.a is a call to the method a() of the object referred to by $ref.
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote:
print $a-{test2};
Oh, hrm. Shouldn't it be $a{test2}? That works too, at any rate.
Does that mean that arrow between variable and subscript is optional,
or should this be some kind of error? Or should it mean something else
Thanks *very* much for your answers; I still have a lot of work left
to do, it seems. But I'm still a little confused:
On Thu, Jun 07, 2001 at 06:08:23AM +1000, Damian Conway wrote:
Should properties interpolate in regular expressions? (and/or strings)
Do you mean property look-ups via the
So, to match $foo's colour against $bar, I'd say
$bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
Great, but how do I match $foo followed by any character followed by the
literal colour?
$bar =~
On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote:
So, to match $foo's colour against $bar, I'd say
$bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
Hm, I thought Larry said you would need to use $() to
So, to match $foo's colour against $bar, I'd say
$bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
Hm, I thought Larry said you would need to use $() to interpolate
a method call.
On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote:
So, to match $foo's colour against $bar, I'd say
$bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
Hm, I
But with the above you still have abiguity, for example what does this do
$bar =~ /$foo.colour($xyz)/;
Looks like a method call with parens, so *is* a method call with parens.
I may be remembering about interpolation into strings as $file.ext is
going to be
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
But with the above you still have abiguity, for example what does this do
$bar =~ /$foo.colour($xyz)/;
Looks like a method call with parens, so *is* a method call with parens.
I may be
But it's not as *convenient* as unadorned interpolation.
Sometimes convenient has to give way
Here we differ. I think the frequency of the
/$var.ident(whatever)/
pattern is likely to be low enough that method interpolation is a
better use for the syntax.
Expecially
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
But it's not as *convenient* as unadorned interpolation.
Disagree. Adorning a piece of syntax reminds the programmer that
something out of the ordinary is happening. It's a mental speed limit
sign - a traffic light, if you like -
[EMAIL PROTECTED] writes:
: What should $foo = (1,2,3) do now? Should it be the same as what
: $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
: $foo = \@INC; does now.) Putting it another way: does a list in scalar
: context turn into a reference, or is
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
[EMAIL PROTECTED] writes:
: What should $foo = (1,2,3) do now? Should it be the same as what
: $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
: $foo = \@INC; does now.) Putting it another way:
On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
Can someone post a few ? I am open to what are the pros/cons
but right now my mind is thinking Whats the benefit of making
$a=(1,2,3); be the same as $a=[1,2,3]; when it could do something
different, ie what it does in perl5
A
Graham Barr [EMAIL PROTECTED]:
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
[EMAIL PROTECTED] writes:
: What should $foo = (1,2,3) do now? Should it be the same as what
: $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC
does what
: $foo = \@INC; does
Damian Conway wrote:
$ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote:
On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
Can someone post a few ? I am open to what are the pros/cons
but right now my mind is thinking Whats the benefit of making
$a=(1,2,3); be the same as $a=[1,2,3];
28 matches
Mail list logo
