At 09:06 PM 4/24/2001 -0700, Larry Wall wrote:
>Edward Peschko writes:
>: Ok, so what does:
>:
>: my %hash = ( 1 => 3);
>: my $hash = { 1 => 4};
>:
>: print $hash{1};
>:
>: print?
>
>4. You must say %hash{1} if you want the other.
I was teaching an intro class yesterday and as usual, there were
Ah.. I knew I'd find the thread in here somewhere.
The problems go away if you allow white space to signify.
> [...] Consider
>
> print "Foo"
> foo("bar");
>
> Did the author forget a semi-colon, or did they intend to concatinate
> there? Also, consider this...
they for
1: use adjacency w/o white space for string cat.
2: allow, as in C, consecutive double-quoted strings
with no intervening tokens (i.e. just whitespace and comments) to
be considered as one string
3: as Uri pointed out, it's all syntactic sugar for convolutions
of C
That means,
Larry Wall wrote:
> (And juxtaposition is out because we're not going to destroy indirect
> object syntax
How often is indirect object syntax used without some whitespace? Having
the perl5->perl6 converter locate it and insert a space shouldn't be too
very tricky.
$these=$this$that$the_
Edward Peschko writes:
: Ok, so what does:
:
: my %hash = ( 1 => 3);
: my $hash = { 1 => 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
Larry
At 06:40 PM 4/24/2001 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > [BTW, was this meant to be CC'd to one of the perl 6 lists? My copy wasn't]
>
>yeah, I have perl6-language as a alias but not "language" by itself
Fixed.
> > At 05:55 PM 4/24/2001 -0500, David L. Nicol wrote:
> > >Da
On Tue, Apr 24, 2001 at 06:39:09PM -0700, Larry Wall wrote:
> Edward Peschko writes:
> : I guess my question is what would be the syntax to access hashes? Would
> :
> : $hashref.{ }
> :
> : be that desirable? I really like ->{ } in that case..
>
> It won't be either of those. It'll simply be
On Tue, Apr 24, 2001 at 06:54:18PM -0700, Larry Wall wrote:
> Nick Ing-Simmons writes:
> : Larry Wall <[EMAIL PROTECTED]> writes:
> : >I think using overloading to write a parser is going to be a relic of
> : >Perl 5's limitations, not Perl 6's.
> :
> : I am _NOT_ using overloading to write a par
IMHO, . can DWIM in most cases even if it's both object deref _and_
concat--without paying any attention to whitespace.
Let's think about this for a minute. What are the common cases for use of
concat?
$a."b";
"a".$b;
$a.$b;
a.$b;
$a.b;
a.b;
The first two are obviously concat, since that code
Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
:
: $hashref.{ }
:
: be that desirable? I really like ->{ } in that case..
It won't be either of those. It'll simply be $hashref{ }.
Larry
On Wed, 25 Apr 2001 00:37:53 +0100, Simon Cozens wrote:
>>$string3 = $string1 . $string2;
>>$string3 = "$string1" + "$string2";
>
>That's now *five* characters required to perform a very common operation.
>
>Rather than one.
I'm really beginning to like
$string3 = $string1 _ $s
On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote:
> THESE ARE NOT THE SAME TIRED ARGUMENTS!
Ooh, different tired arguments!
>$string3 = $string1 . $string2;
>$string3 = "$string1" + "$string2";
That's now *five* characters required to perform a very common operation.
Rathe
Dan Sugalski wrote:
> Most of the parser switching is going to be of the nesting variety. Every
> time the parser processes a double-quoted string constant or a regular
> expression you're going to be jumping parsers. That's all temporary, and we
> really do want them to nest. (You really don't w
At 03:38 PM 4/24/2001 -0700, Nathan Wiger wrote:
>"Stephen P. Potter" wrote:
> >
> > You still haven't given a good explanation of
> >
> > $a += sub(); # is it a string or a number?
> >
> > Does your plan mean that we can no longer have subs that are context
> > dependent?
>
>No, Schwern aske
"Stephen P. Potter" wrote:
>
> Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~
> and !~ went away and were replaced by match(string, [pattern], options),
> replace(string, [pattern], options) and trans(string, ["pattern"], options)
> or some such. This is one place wher
"Stephen P. Potter" wrote:
>
> You still haven't given a good explanation of
>
> $a += sub(); # is it a string or a number?
>
> Does your plan mean that we can no longer have subs that are context
> dependent?
No, Schwern asked me this same thing off list, here's what I said:
One possibi
> I still think it's a good idea - better than any other proposed so far.
>
> Are we so afraid of a little mandatory disambiguating white space
> that we are willing to pay the price of contorting other syntax
> beyond the bounds of sanity? :-)
>
> It's perfectly obvious to me that
>
> $x
> | Under what I originally posted:
> |
> |$a += "$b";# string
> |$a += $b; # numeric
>
> You still haven't given a good explanation of
>
> $a += sub();# is it a string or a number?
The quotes don't work. Anything but the most basic statement introduces
way more ambiguity
Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
ed:
| Michael G Schwern wrote:
| >
| > Oh, not to seed the clouds or anything, but what about "+=" and ".="?
| > Any proposal will have to deal with those.
|
| Under what I originally posted:
|
|$a += "$b";#
Lightning flashed, thunder crashed and Garrett Goebel <[EMAIL PROTECTED]> w
hispered:
| cmp ~<=>
| .= ~+=
| ~=+ (concat after)
| =~ =~
| !~ !~
It's not bad enough that we're getting a proliferation of trigraph
operators, now you w
On Tue, Apr 24, 2001 at 01:42:43PM -0700, Nathan Wiger wrote:
> Uri Guttman wrote:
> >
> > on the other hand, i use .= all the time and wouldn't like to lose
> > it. schwern idea of ce doesn't work for me as only the op= stuff means
> > assignment and ce would break that (e for = isn't visual eno
On Tue, 24 Apr 2001, Michael G Schwern wrote:
> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on
> > either side with white space?
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
To: "Nathan Wiger" <[EMAIL PROTECTED]>
Sent: Tuesday, April 24, 2001 4:08 PM
Subject: Re: YA string concat proposal
> On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
> > Under the above plan, maybe this is:
> >$a ca $b;
> > For "con
Uri Guttman wrote:
>
> on the other hand, i use .= all the time and wouldn't like to lose
> it. schwern idea of ce doesn't work for me as only the op= stuff means
> assignment and ce would break that (e for = isn't visual enough).
I was just thinking, too bad that Larry's claiming the colon
curr
On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
> While we're brainstorming a wish-list, here's something I've always
> wanted, a replacement for:
>
>$a = $b . $a;
I don't think there's any pressing need for this unless you can show a
common case where a prepend op would make t
For those of us who came in late...I gather that -> is expected to be
replaced by '.', which means that we need to find something else for '.'.
Somehow, however, I missed out what the exact benefits are of this
replacement--I'm not saying that there *aren't* any, I just never saw the
message whe
~ looks like a string to me Larry sycophant that I am.
, also looks a little like a string. And is keyboard friendly.
Its doubtless naive to suggest it, but why not:
Perl 5 Perl 6
--- ---
-> .
+ +
. ~+
eq ~==
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW>$a = $b . $a;
NW> Under the above plan, maybe this is:
NW>$a ca $b;
substr( $a, 0, 0, $b ) ;
$a =~ s/^/$b/ ;
just my $.02 on this. i rarely use bare . for concat. as someone else
mentioned, it is usually o
On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
: Michael G Schwern wrote:
: >
: > cc and ce
: >
: > Perl 5 Perl 6
: > print "foo" . "bar";print "foo" cc "bar;
: > print 2 . 4;print 2 cc 4;
: >
Michael G Schwern wrote:
>
> Oh, not to seed the clouds or anything, but what about "+=" and ".="?
> Any proposal will have to deal with those.
Under what I originally posted:
$a += "$b";# string
$a += $b; # numeric
Seems easy enough...
-Nate
On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote:
>$a = $b . $a;
>
> Under the above plan, maybe this is:
>
>$a ca $b;
>
> For "concat after"?
I'd rather it be called "pp" for prepend. :-)
It's good that we decided to let Larry design the language, otherwise
we'd be mired
> This is going to make finding syntax errors a bit difficult, as many
> will simply become concatination operators. Consider
>
> print "Foo"
> foo("bar");
>
> Did the author forget a semi-colon, or did they intend to concatinate
> there? Also, consider this...
*sigh*. Ok,
Michael G Schwern wrote:
>
> cc and ce
>
> Perl 5 Perl 6
> print "foo" . "bar";print "foo" cc "bar;
> print 2 . 4;print 2 cc 4;
> print "foo " . ($i + 1);print "foo " cc ($i + 1);
> $foo .= "
Michael G Schwern wrote:
>
> On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> > ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> > language compatible, etc...) so what are the arguments against it?
>
> This one seems to have slipped by...
> http://arch
> The only reason you'd have to use the op form of a string concat is when
> you have to add stuff in that isn't evaluated inside quotes, like funcs.
That doesn't make sense. Your proposal was to cause quotes to force concat
context, but here you say the op is only useful when evaluating stuff
ou
Lightning flashed, thunder crashed and Casey West <[EMAIL PROTECTED]> whispere
d:
| I would consider thinking about the bigger problem of:
|
| $string = foo() [something here] bar();
In either case, quoting the operands isn't going to work.
$string = "foo()" + "bar()";
And, my one argument sti
"Stephen P. Potter" wrote:
>
> | In Perl 6, you would do this like so:
> |
> |$string3 = "$string1" + "$string2";
>
> Once you go this route, you've pretty much destroyed the usefulness of
> having a concat operator. It is far less typing to do
>
>$string3 = "$string1$string2";
Ag
Ok, time for me to shot down.
I've already voiced my views about trying to make addition and
concatination into a single operator in a typeless language
http://archive.develooper.com/perl6-language%40perl.org/msg06550.html
and I think its a losing proposition.
So here's something simple. Sort o
On Tue, Apr 24, 2001 at 08:42:10PM +0100, Michael G Schwern wrote:
: On Tue, Apr 24, 2001 at 02:32:39PM -0500, Jarkko Hietaniemi wrote:
: > Has the road of just putting things next to each other been extensively
: > tried? It works for Awk... "juxtapose", the Famous Invisible Perl
: > Operator.
On Tue, Apr 24, 2001 at 08:32:09PM +0100, Michael G Schwern wrote:
: On Tue, Apr 24, 2001 at 12:23:24PM -0700, Austin Hastings wrote:
: > Some of the objections have gone by, but what if you reverse the
: > quotes?
: > Make operator-in-quotes be a string operator (hell, make that true for
: > the
On Tue, Apr 24, 2001 at 02:32:39PM -0500, Jarkko Hietaniemi wrote:
> Has the road of just putting things next to each other been extensively
> tried? It works for Awk... "juxtapose", the Famous Invisible Perl
> Operator.
>
> Perl 5 Perl 6
>
> $a = $b . $c;
From: "Austin Hastings" <[EMAIL PROTECTED]>
> Perl 5Perl 6
> -
> $name = "This" . "that"; $name = "This" "+" "that";
$name = "+" "+" "+" "+"; # uh???
On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote:
> ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> language compatible, etc...) so what are the arguments against it?
This one seems to have slipped by...
http://archive.develooper.com/perl6-language%40per
I think the magical "+" isn't going to work.
Has the road of just putting things next to each other been extensively
tried? It works for Awk... "juxtapose", the Famous Invisible Perl
Operator.
Perl 5 Perl 6
$a = $b . $c; $a = $b $c; # or $b$c
On Tue, Apr 24, 2001 at 12:23:24PM -0700, Austin Hastings wrote:
> Some of the objections have gone by, but what if you reverse the
> quotes?
> Make operator-in-quotes be a string operator (hell, make that true for
> the other ops, too)
>
> Perl 5 Perl 6
> --- ---
> ok, well.. I've heard arguments for '+' (namely that its intuitive, other
> language compatible, etc...) so what are the arguments against it?
Well, it looks like I'm a little bit behind. Spend 15 minutes typing something,
and you get 7 messages in your mailbox on the exact topic that you had
On Tue, Apr 24, 2001 at 05:44:49PM +0100, Michael G Schwern wrote:
> On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> > I think someone may have mentioned this already, but why not just say
> > that if you want '.' to mean concatenation, you have to surround it on
> > either side
Some of the objections have gone by, but what if you reverse the
quotes?
Make operator-in-quotes be a string operator (hell, make that true for
the other ops, too)
Perl 5 Perl 6
--- ---
-> .
+ +
. "+"
eq "=" or
On Tue, Apr 24, 2001 at 03:09:18PM -0400, Stephen P. Potter wrote:
: Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
: ed:
: | Under this proposal, string concatenation would be acheived by the
: | *combination* of "" and +. So, in Perl 5 you would have something li
Nathan Wiger wrote:
> string concatenation would be acheived by the
> *combination* of "" and +.
>$string3 = "$string1" + "$string2";
> Here's the key: The quotes are REQUIRED. If you left them
> off, you'd get numeric addition. There is no magic type
> inference.
That, imho, is bending way
Lightning flashed, thunder crashed and Nathan Wiger <[EMAIL PROTECTED]> whisper
ed:
| Under this proposal, string concatenation would be acheived by the
| *combination* of "" and +. So, in Perl 5 you would have something like
| this:
|
|$string3 = $string1 . $string2;
|
| In Perl 6, you woul
On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote:
>Perl 5Perl 6
>-
>$res = $var + $var2; $res = $var + $var2;
>$name = "This" . "that"; $name = "This" + "that";
>$name = "
On Tue, Apr 24, 2001 at 11:53:49AM -0700, Mark Koopman wrote:
: >Perl 5Perl 6
: >-
: >print "Next is " . $i + 1;print "Next is " + $i + 1;
:
:
: this is the root of the problemPerl 5 version is e
On Tue, Apr 24, 2001 at 11:53:49AM -0700, Mark Koopman wrote:
> >Perl 5Perl 6
> >-
> >print "Next is " . $i + 1;print "Next is " + $i + 1;
>
>
> this is the root of the problemPerl 5 version is e
> If, instead, you wrote:
>
>$me = $name + getpwuid($<);
>
> You would get numeric addition. Always. In this way, you maintain a
> reliable semantic separation of string concat and numeric addition,
> while gaining a syntax that is similar to other HLL's. Having "$var"
> expand $var is the r
Seems servicable. Doesn't exactly make me jump up and down, though.
A few nits...
On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote:
> More Details
>
> Ok, if you're still reading, cool. Let's get down to the nitty-gritty.
> Here are some more examples of code:
>
>
>Perl 5Perl 6
>-
>print "Next is " . $i + 1;print "Next is " + $i + 1;
this is the root of the problemPerl 5 version is easy to
understand, Perl 6 version is still ambiguous
THESE ARE NOT THE SAME TIRED ARGUMENTS! If you're on p5p, you're
probably already rolling your eyes. However, I searched p5p all the way
back to 1997 and could not find this proposal anywhere. Even though it
looks similar to the standard "Java + concat overload" stuff, it is not,
so please try to
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
:
: On Tue, 24 Apr 2001, Graham Barr wrote:
:
: > On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
: >
: > > At the moment I'm leaning toward ^ for concat, and ~ for xor. That
: >
: > I think that would lead to confusio
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote:
> I think someone may have mentioned this already, but why not just say
> that if you want '.' to mean concatenation, you have to surround it on
> either side with white space? If there's no white space around it, then
> it is force
On Tue, 24 Apr 2001, Graham Barr wrote:
> On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
>
> > At the moment I'm leaning toward ^ for concat, and ~ for xor. That
>
> I think that would lead to confusion too. In many languages ^ is
> xor and ~ is a bitwise invert. It is that way i
From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
> > >
> > > It seems relatively unlikely in the course of normal Perl
> > > that you're going to end up with very many references to
> > > objects.
> >
> > Well, right
On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:
> At the moment I'm leaning toward ^ for concat, and ~ for xor. That
> will help with ^= not resembling =~, though ~= would still mean The
> Wrong Thing...
As has been mentioned by others, ^ has established meaning in other
programming
Simon Cozens wrote:
> Let's put it a different way - if we can find a short operator which
> is readily accessible on most people's keyboards, then that would
> score over a longer operator which is readily accessible on most
> people's keyboards. Maybe ~ isn't that operator. Maybe & is, or ^ or
On Tue, Apr 24, 2001 at 12:29:23AM -0700, Russ Allbery wrote:
> How do you concatenate together a list of variables that's longer than one
> line without using super-long lines?
join '', $var1, $var2, $var3, ..., $varN;
TMTOWTDI, remember.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Tue, 24 Apr 2001, Simon Cozens wrote:
> On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote:
> > Well, right now in Perl, an object *is* a reference.
>
> No. An object is a referent. Two blessed references can refer to the
> same data; however, that's only one object.
Oops, that's
At 08:01 PM 4/23/2001 -0500, David L. Nicol wrote:
>Larry Wall wrote:
> >
> > David L. Nicol writes:
> > :
> > : [this parser switch thing]
> > : sounds a lot like an "exec" system call: there are some things
> > : which remain in effect (open file handles, current directory,
> > : environment) bu
On Tue, Apr 24, 2001 at 08:38:58AM -0500, David M. Lloyd wrote:
> Well, right now in Perl, an object *is* a reference.
No. An object is a referent. Two blessed references can refer to the
same data; however, that's only one object.
--
teco < /dev/audio
- Ignatios Souvatzis
On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote:
>Let's put it a different way - if we can find a short operator which
>is readily accessible on most people's keyboards, then that would
>score over a longer operator which is readily accessible on most
>people's keyboards. Maybe ~ isn't th
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> It seems relatively unlikely in the course of normal Perl that you're
>> going to end up with very many references to objects.
> Well, right now in Perl, an object *is* a reference.
Precisely. So there's almost
At 09:33 AM 4/24/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > The one downside is that you'd have essentially your own private language.
> > Whether this is a bad thing or not is a separate issue, of course.
>
>IIUC, this ability is precisely what Larry was saying Perl6 would have.
I a
At 06:34 AM 4/24/2001 -0700, Russ Allbery wrote:
>David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
>
> >> The switch from -> to . makes perfect sense from a C perspective if we're
> >> turning objects into first-class entities rather than pointers; think
> >> about
On 24 Apr 2001, Russ Allbery wrote:
> David M Lloyd <[EMAIL PROTECTED]> writes:
>
> > What's wrong with using both? You could use -> if you're working with a
> > reference to an object, and you could use . if you're working with the
> > object itself.
>
> It seems relatively unlikely in the co
On Tue, Apr 24, 2001 at 03:26:04PM +0200, Henrik Tougaard wrote:
> > From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > > Please don't use the keypresscount as an argument.
> > Why not? We're making easy things easy, remember.
> B
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> The switch from -> to . makes perfect sense from a C perspective if we're
>> turning objects into first-class entities rather than pointers; think
>> about a struct versus a pointer to a struct.
>>
>> -> makes you
Dan Sugalski wrote:
> The one downside is that you'd have essentially your own private language.
> Whether this is a bad thing or not is a separate issue, of course.
IIUC, this ability is precisely what Larry was saying Perl6 would have.
--
John Porter
On 24 Apr 2001, Russ Allbery wrote:
> Branden <[EMAIL PROTECTED]> writes:
>
> > 1) Use $obj.method instead of $obj->method :
>
> > The big question is: why fix what is not broken? Why introduce Javaisms
> > and VBisms to our pretty C/C++-oid Perl? Why brake compatibility with
> > Perl 5 code (a
At 02:55 AM 4/24/2001 -0400, John Porter wrote:
>Dan Sugalski wrote:
> > It wouldn't be all that tough to change this if you were so inclined--it'd
> > certainly be a simpler parser modification than some others that have been
> > proposed.
>
>Yes, I hadn't thought of that. Yay again.
The one do
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> > Please don't use the keypresscount as an argument.
>
> Why not? We're making easy things easy, remember.
>
Because your keyboard layout isnt mine! I have nice letters like
'æ',
On Tue, Apr 24, 2001 at 12:31:44PM +0200, Henrik Tougaard wrote:
> On my keyboard '~' is 3 keystrokes - and rather complicated ones
> at that:
Then maybe ~ isn't best.
> Please don't use the keypresscount as an argument.
Why not? We're making easy things easy, remember.
--
Rule 3: If the char
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> > Make concatination be "$a cat $b". ("eq" and friends
> already provide
> > precedent for string operators being words rather than symbols.)
>
> While that's true, concatenation is quite a common operation
> (Introspection
> is cool. Run "perl
On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote:
>While that's true, concatenation is quite a common operation
>that I'd be really
>uncomfortable with it necessitating 4 keystrokes (" cat") instead of one.
Er, "~" is an extremely annoying character to type at many keyboards. It
may depen
On Tue, Apr 24, 2001 at 02:01:11AM -0700, Damien Neil wrote:
> If you're dead-set on reassigning ., please consider leaving it at
> that, rather than juggling all the other operators around.
Don't forget that binary ~ doesn't currently exist, so this is adding
syntax rather than reassigning it.
On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:
>How do you concatenate together a list of variables that's longer than one
>line without using super-long lines? Going to the shell syntax of:
>
>PATH=/some/long:/bunch/of:/stuff
>PATH="${PATH}:/more/stuff"
>
>would really be a shame.
On Mon, Apr 23, 2001 at 11:31:18AM -0700, Larry Wall wrote:
> There are many people who would prefer . to ->, if for no other reason
> than it's cleaner looking and is one less character to type. The fact
> that it's become the industry standard for method call syntax is also
> a point in its fav
This may or may not be related to Dave's post, but I just remembered
why I don't like a dual-natured +. I'm sorry if this was gone through
before.
Consider the following...
sub foo { $_[0] + $_[1] }
What do the following return?
foo(1,1); obviously 2
foo(
Branden <[EMAIL PROTECTED]> writes:
> 1) Use $obj.method instead of $obj->method :
> The big question is: why fix what is not broken? Why introduce Javaisms
> and VBisms to our pretty C/C++-oid Perl? Why brake compatibility with
> Perl 5 code (and Perl 5 programmers) for a zero net gain?
$obj.m
Bart Lateur <[EMAIL PROTECTED]> writes:
> My vote is to ditch the concat operator altogether. Hey, we have
> interpolation!
> "$this$is$just$as$ugly$but$it$works"
How do you concatenate together a list of variables that's longer than one
line without using super-long lines? Going to the
88 matches
Mail list logo
