Re: Curious: - vs .

2001-04-27 Thread Piers Cawley

Buddha Buck [EMAIL PROTECTED] writes:

 Piers Cawley [EMAIL PROTECTED] writes:
 
  Buddha Buck [EMAIL PROTECTED] writes:
  
   Bart Lateur [EMAIL PROTECTED] writes:
   
On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
So why not

$object!method(foo, bar);
   
   In my opinion, because it doesn't provide sufficient visual
   distinction between $object and method().  At a glance, especially on
   a crowded page, it's similar in appearance to $objectImethod, for
   instance.  $object.method() has a visual separator (although I'd
   prefer $object-method()).
   
   How about borrowing from Objective C?
   
  [$object method(foo, bar)];
  
  How do you create an anonymous list now then? Not that I object to
  borrowing from Objective C you realise.
 
 I thought ($one, $two, $three) was an anonymous list.

Oops, meant anonymous array.

 Seriously, I hadn't considered that their may be a problem with the
 syntax I gave.
 
 How would you, under Perl5, interpret the expression I used.  To me,
 it looks like a syntax error.  '$object method(foo,bar)' isn't a
 valid method call, so it can't be a ref to an anonymous list of one
 value.

Hmm... I plead posting late at night.

 Other than severe dependence on the comma, is there any reason why we
 couldn't have the following?
 
 
 $foo  = [$one];   # array ref
 $baz  = [$obj,funcall()  ];   # array ref
 $quux = [$one,$two,$three];   # array ref
 $bar  = [$obj method()   ];   # method call
 $bat  = [$one $two $three];   # syntax error

Apart from the fact that we're adding one more meaning to [], one
which has no mnemonic relationship with arrays, no reason at all.

-- 
Piers Cawley
www.iterative-software.com




Re: Curious: - vs .

2001-04-27 Thread Bart Lateur

On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote:

$bar  = [$obj method()   ];   # method call

$bar = method $obj()

would be more consistent with perl's current 

$object = new Class()

syntax.

-- 
Bart.



Re: Curious: - vs .

2001-04-27 Thread Buddha Buck

Bart Lateur [EMAIL PROTECTED] writes:

 On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote:
 
 $bar  = [$obj method()   ];   # method call
 
   $bar = method $obj()
 
 would be more consistent with perl's current 
 
   $object = new Class()
 
 syntax.

Yes, well, some people want to get rid of the indirect object
syntax, not require it.  

I don't use it myself, but my understanding is that

   $bar = method $obj()

is legal right now, and that your second example isn't a special-case
but just one example of the general case.

 
 -- 
   Bart.



Re: Curious: - vs .

2001-04-27 Thread Buddha Buck

Piers Cawley [EMAIL PROTECTED] writes:

 Buddha Buck [EMAIL PROTECTED] writes:
 
  Piers Cawley [EMAIL PROTECTED] writes:
  
   Buddha Buck [EMAIL PROTECTED] writes:

How about borrowing from Objective C?

   [$object method(foo, bar)];
   
   How do you create an anonymous list now then? Not that I object to
   borrowing from Objective C you realise.
  
  I thought ($one, $two, $three) was an anonymous list.
 
 Oops, meant anonymous array.

To be overly pedantic I thought [$one, 2, 3] was a ref to an anonymous array...
 
  Other than severe dependence on the comma, is there any reason why we
  couldn't have the following?
  

[snip]

 
 Apart from the fact that we're adding one more meaning to [], one
 which has no mnemonic relationship with arrays, no reason at all.

Since it looks like we are going to be getting $object.method()
anyway, it doesn't matter much.  It was more of a facetious suggestion
to begin with -- although that doesn't mean that it wouldn't work,
it's just not going to happen, and I know it.

 Piers Cawley
 www.iterative-software.com



Re: Curious: - vs .

2001-04-26 Thread Bart Lateur

On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:

the idea of a dereference operator dumbfounds lots
of folks. What's an object got to do with a reference, much less a
pointer? A p5 object is very confusing to others for this reason, and so
is the syntax.

So you want a method invocation syntax that doesn't remind people of
references. OK. But why does it have to be the dot? It is already taken.
Sorry. Use an operator that doesn't exist yet in Perl. For example, old
style VB used ! to connect objects and their properties:

label1!caption = Hi!

is the same as

label1.caption = Hi!


So why not

$object!method(foo, bar);

-- 
Bart.



Re: Curious: - vs .

2001-04-26 Thread Dan Brian

 the idea of a dereference operator dumbfounds lots
 of folks. What's an object got to do with a reference, much less a
 pointer? A p5 object is very confusing to others for this reason, and so
 is the syntax.
 
 So you want a method invocation syntax that doesn't remind people of
 references. OK. But why does it have to be the dot? It is already taken.
 Sorry. Use an operator that doesn't exist yet in Perl. For example, old
 style VB used ! to connect objects and their properties:
 
   $object!method(foo, bar);

It doesn't have to be the dot. But the plain fact is that the dot is
generally recognized in this way; why is making Perl syntax more
recognized a bad thing? If what we're after is making Perl better, then
one of the primary improvements should be making objects more readable for
the multi-language programmer. I'm really not against '-', but then
again, I *like* that
an-object-is-a-reference-which-means-I-can-poke-and-prod-it-and-embed-it-etc.
Even so, I recognize that it doesn't make Perl more readable, especially
when glob syntax is used to manipulate the reference table.

A traditionally negating symbol ('!') is the last character I would want
to see. As for VB  ;)




Re: Curious: - vs .

2001-04-26 Thread Piers Cawley

Buddha Buck [EMAIL PROTECTED] writes:

 Bart Lateur [EMAIL PROTECTED] writes:
 
  On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
  So why not
  
  $object!method(foo, bar);
 
 In my opinion, because it doesn't provide sufficient visual
 distinction between $object and method().  At a glance, especially on
 a crowded page, it's similar in appearance to $objectImethod, for
 instance.  $object.method() has a visual separator (although I'd
 prefer $object-method()).
 
 How about borrowing from Objective C?
 
[$object method(foo, bar)];

How do you create an anonymous list now then? Not that I object to
borrowing from Objective C you realise.

-- 
Piers Cawley
www.iterative-software.com




Re: Curious: - vs .

2001-04-26 Thread Buddha Buck

Piers Cawley [EMAIL PROTECTED] writes:

 Buddha Buck [EMAIL PROTECTED] writes:
 
  Bart Lateur [EMAIL PROTECTED] writes:
  
   On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
   So why not
   
 $object!method(foo, bar);
  
  In my opinion, because it doesn't provide sufficient visual
  distinction between $object and method().  At a glance, especially on
  a crowded page, it's similar in appearance to $objectImethod, for
  instance.  $object.method() has a visual separator (although I'd
  prefer $object-method()).
  
  How about borrowing from Objective C?
  
 [$object method(foo, bar)];
 
 How do you create an anonymous list now then? Not that I object to
 borrowing from Objective C you realise.

I thought ($one, $two, $three) was an anonymous list.

Seriously, I hadn't considered that their may be a problem with the
syntax I gave.

How would you, under Perl5, interpret the expression I used.  To me,
it looks like a syntax error.  '$object method(foo,bar)' isn't a
valid method call, so it can't be a ref to an anonymous list of one
value.

Other than severe dependence on the comma, is there any reason why we
couldn't have the following?


$foo  = [$one];   # array ref
$baz  = [$obj,funcall()  ];   # array ref
$quux = [$one,$two,$three];   # array ref
$bar  = [$obj method()   ];   # method call
$bat  = [$one $two $three];   # syntax error



 
 -- 
 Piers Cawley
 www.iterative-software.com



RE: Curious: - vs .

2001-04-26 Thread Sterin, Ilya

$foo = [$one, $two, $three]; # creates an anonymous list.

$foo = [$object method(foo, bar)];
This would interpret as 

$foo[0] == $object, etc...

Ilya



-Original Message-
From: Buddha Buck [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 11:20 PM
To: Piers Cawley
Cc: Bart Lateur; [EMAIL PROTECTED]
Subject: Re: Curious: - vs .


Piers Cawley [EMAIL PROTECTED] writes:

 Buddha Buck [EMAIL PROTECTED] writes:
 
  Bart Lateur [EMAIL PROTECTED] writes:
  
   On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
   So why not
   
 $object!method(foo, bar);
  
  In my opinion, because it doesn't provide sufficient visual
  distinction between $object and method().  At a glance, especially on
  a crowded page, it's similar in appearance to $objectImethod, for
  instance.  $object.method() has a visual separator (although I'd
  prefer $object-method()).
  
  How about borrowing from Objective C?
  
 [$object method(foo, bar)];
 
 How do you create an anonymous list now then? Not that I object to
 borrowing from Objective C you realise.

I thought ($one, $two, $three) was an anonymous list.

Seriously, I hadn't considered that their may be a problem with the
syntax I gave.

How would you, under Perl5, interpret the expression I used.  To me,
it looks like a syntax error.  '$object method(foo,bar)' isn't a
valid method call, so it can't be a ref to an anonymous list of one
value.

Other than severe dependence on the comma, is there any reason why we
couldn't have the following?


$foo  = [$one];   # array ref
$baz  = [$obj,funcall()  ];   # array ref
$quux = [$one,$two,$three];   # array ref
$bar  = [$obj method()   ];   # method call
$bat  = [$one $two $three];   # syntax error



 
 -- 
 Piers Cawley
 www.iterative-software.com



Curious: - vs .

2001-04-25 Thread Nathan Wiger

I'm just gonna post this, then back off and listen (been yapping too
much...)

The previous discussions about string concat and how to replace . have
revealed that people are somewhat divided over whether replacing - with
. is actually good thing or not.

I'm just curious what the arguments for and against it are. PLEASE don't
turn this into an unproductive religious flamewar. I'm open-minded about
it, but I at least need a little convincing. Whether or not this has any
impact on Larry's decision is unknown, but it seems like it's good to at
least have the pros and cons clearly on the table.

Just to start it off, here are some of the arguments against changing
this that I know of. If you know of others, or are on the for side of
things, feel free speak up. Politely, PLEASE.

   Arguments Against Changing - and .
   ---
   - It gains superficial similarity to other HLL's,
 yet Perl is fundamentally semantically different
 from all of them. Plus, this is not the only
 syntactic difference.

   - JAPH compatibility. Thousands of people already
 know how deref and concat work, and they're the
 target audience for Perl 6, after all. Sure, we'd
 closer to Python, but we'd be further from Perl 5.

   - C compatibility. One of Perl's great strengths
 over other HLL's is C compatibility. Though
 this is still arguably not as good as it can be, 
 why distance ourselves from the language we're
 trying to interact with?

   - Dissimilarity between Perl and languages like
 JavaScript can actually be beneficial. If you're
 generating code, this makes it easier to scan
 and see where your Perl ends and your Java begins.

   - Two keys less to press? Ever heard of macros? :-)



Re: Curious: - vs .

2001-04-25 Thread Russ Allbery

Nathan Wiger [EMAIL PROTECTED] writes:

- C compatibility. One of Perl's great strengths
  over other HLL's is C compatibility. Though
  this is still arguably not as good as it can be, 
  why distance ourselves from the language we're
  trying to interact with?

You're thinking of objects as references and references as akin to
pointers, which makes sense because that's how they're implemented in Perl
5.  If you think of objects as their own entities, however, or think of
references as something other than pointers (in particular, something that
doesn't require explicit dereferencing), then using . to access object
members is entirely compatible with C.

I tried to make this point before, but I don't think people understood
what I was getting at.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/