Front page | perl.bootstrap |
Postings from July 2000
Tim Bunce <Tim.Bunce@ig.co.uk> writes:
> On Mon, Jul 24, 2000 at 05:44:00PM -0400, abigail wrote:
> > On Mon, Jul 24, 2000 at 08:49:14PM +0100, Tim Bunce wrote:
> > > On Mon, Jul 24, 2000 at 02:01:00PM -0400, Dan Sugalski wrote:
> > > >
> > > > It's a touch more open than that. Typeglobs, for example, may
> > > > get tossed, and it's possible that some of the other grotty
> > > > bits will go too. I can't picture Larry making things
> > > > un-perlish, but its all up for grabs.
> > >
> > > He's also said that it's likely that dots will be allowed for indirect
> > > object notation:
> > >
> > > $foo.method();
> > >
> > > same as
> > >
> > > $foo->method();
> >
> > Urg. Those are things I can't see the benefits of. It doesn't make
> > the syntax any less complicated. It just creates another "there is
> > more than one way to do it". But with the only benefit a
> > keystroke. It just adds to the perceived problem of Perl being
> > hard.
> >
> > (BTW, does that also mean $foo.[1] and $foo.{1} are going to be
> > legal? What about $foo.()? ;-))
>
> Don't ask me! :-)
>
> The point here is that, at this stage, everything is open. The dot
> operator might not change. Then again the -> may disappear. Then
> again I may be talking nonsense. I think this one comes down to
> trusting Larry.
I'm trying to work out how you distinguish between:
$foo.method() # method call
$foo.method() # The stringification of $foo concatenated with the
# results of the subroutine method() without making
# the parser even more hairy than it already is, or
# replacing '.' meaning concatenate with something
# dreadful like '+'.
--
Piers