> I think you're right that this is a valid distinction, I'm just not
> sure if it's not a little too subtle and that the two different
> notations won't cause confusion.
Well, I had been hoping to appeal to the mathematical mindset of the list,
but there is a second reason for = in addition to /
On Thu, 2002-04-11 at 00:47, Damian Conway wrote:
> sub load_data ($filename) { load_data($filename, 1) }
>
> sub load_data ($filename, $version) {...}
Interesting. This brings goto to mind. Above, I could just assume that
inlining will happen, but what about goto? Obviously:
s
On Wed, Apr 10, 2002 at 10:45:55PM -0600, Luke Palmer wrote:
> Indeed, and with the //= thing, you can let parameters in the middle
> default.
Except that I haven't heard anyone say that given
sub foo ($a//=1, $b//=2, $c//=3) {...}
foo(5,,6); # that
On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
> > Ah, but I think the mnemonic value of the '.' more than earns its keep
> > here. C is doing a slightly different job
> > anyway. And instance variables are *not* the same as 'normal'
> > variables, they hang off a different symbol table (or syte,
On Thu, 2002-04-11 at 09:36, Jonathan Scott Duff wrote:
> On Wed, Apr 10, 2002 at 10:45:55PM -0600, Luke Palmer wrote:
> > Indeed, and with the //= thing, you can let parameters in the middle
> > default.
>
> Except that I haven't heard anyone say that given
>
> sub foo ($a//=1, $b//=2, $
[Apologies to Aaron Sherman, who gets this twice due to my
dunderheadedness]
Aaron Sherman <[EMAIL PROTECTED]> writes:
[...]
> Also, another though:
>
> sub foo($a = 1, $b, $c) { ... }
>
> In C++ at least, I think this is an error. However, it seems to me that
> in Perl it could be inte
>sub foo($a=1, $b, $c=3) { ... }
>
> is ambiguous: While foo(2) sets $a=1, $b=2, $c=3, it's impossible to
> say what foo(4,5) should do.
foo(2) means that $a = 2, $b defaults to undef, $c defaults to 3
foo(4,5) means $a = 4, $b = 5, and $c defaults to 3.
-Miko
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: > > Ah, but I think the mnemonic value of the '.' more than earns its keep
: > > here. C is doing a slightly different job
: > > anyway. And instance variables are *not* the same as 'normal'
: > > variables, they hang off a
On Thu, 2002-04-11 at 09:59, Ariel Scolnicov wrote:
> [Apologies to Aaron Sherman, who gets this twice due to my
> dunderheadedness]
No problem. I usually reply to the person and CC the list because some
folks have filters that will make discussions easier if I'm replying to
them vs. sending just
On Thu, 2002-04-11 at 11:49, Larry Wall wrote:
> Aaron Sherman writes:
> : This should not be allowed.
>
> Well, that depends on what you mean by "this". :-)
[...]
> : In Perl5 C<$object{instancevar} = 7> is just frowned on. In Perl6, I
> : thought we had agreed that it would flat out be imposs
At 7:25 AM -0700 4/11/02, Randal L. Schwartz wrote:
> > "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>Dan> (Or maybe attributed string eval, like:
>
>Dan> $foo = eval.Parrot set I0, 12
>Dan> sub I0, I0, 5
>Dan> EOP
>
>That would make more sense
On Thu, 2002-04-11 at 11:55, Aaron Sherman wrote:
> 1. The first default marks the beginning of optional parameters.
> 2. An optional parameter with no default will automatically default to
> undef.
Interestingly, I just said something that I did not mean to, but it
opens up an interesting avenu
> class myobj {
> ...
> int a,b,c;
> myobj(int aa, int bb, int cc) :
> a(aa), b(bb), c(cc) const {}
> ...
> };
Ummm no. Straight from Bjarne: "You can't have a const constructor." You
just do what you did w
On Thu, 2002-04-11 at 12:44, Luke Palmer wrote:
> > class myobj {
> > ...
> > int a,b,c;
> > myobj(int aa, int bb, int cc) :
> > a(aa), b(bb), c(cc) const {}
> > ...
> > };
>
> Ummm no. Straight from Bjarne: "You can't ha
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Thu, 2002-04-11 at 00:47, Damian Conway wrote:
>
>> sub load_data ($filename) { load_data($filename, 1) }
>>
>> sub load_data ($filename, $version) {...}
>
> Interesting. This brings goto to mind. Above, I could just assume
> that inlining
Miko O'Sullivan writes:
: > I think you're right that this is a valid distinction, I'm just not
: > sure if it's not a little too subtle and that the two different
: > notations won't cause confusion.
:
: Well, I had been hoping to appeal to the mathematical mindset of the list,
: but there is a
On Thu, 2002-04-11 at 14:34, Larry Wall wrote:
> Miko O'Sullivan writes:
> : Well, I had been hoping to appeal to the mathematical mindset of the list,
> : but there is a second reason for = in addition to / /=: it's simpler to
> : understand. I just think that the potential Perl hackers will un
> "David" == David Whipp <[EMAIL PROTECTED]> writes:
David> If every object has a C method (C?), then you could
David> always call class-methods as class.m2().
Wouldn't that be .class.m2(), or did I miss something in the flurry?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc.
At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
>On Thu, 2002-04-11 at 14:34, Larry Wall wrote:
> > Miko O'Sullivan writes:
>
> > : Well, I had been hoping to appeal to the mathematical mindset of the
> list,
> > : but there is a second reason for = in addition to / /=: it's simpler to
> > : un
> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes:
Dan> (Or maybe attributed string eval, like:
Dan> $foo = eval.Parrot sub I0, I0, 5
Dan>EOP
That would make more sense to me (for whatever that's worth) as
$foo = Parrot.eval < http:
20 matches
Mail list logo
