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) {
>>
>
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 += $interestrat
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 trad
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 i
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
subscrip
> 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: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 pr
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 n
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
> > $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
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote:
> I'm sure I'll think of some more questions
Are properties subscriptable? (Can the value of a property be a
reference that can be dereferenced?)
Can properties have properties?
--
The complex-type shall be a simple-type. ISO 10206
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
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 = 9.
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
Damian Conway wrote:
> $ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
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 =
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"
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
[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
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
> > 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.
> > Exp
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
> 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 t
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()/;
> >> 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
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
> 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 =~ /
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 t
> Should properties interpolate in regular expressions? (and/or strings)
Do you mean property look-ups via the pseudo-method syntax?
In that case, yes they should
> I don't suppose they should, because we don't expect subroutines to.
> (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we ne
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
alt
30 matches
Mail list logo
