My first reaction to reading this was "Eww!"  Upon thinking, its
really not a reaction to the RFC, but to indirect object syntax.  IMHO
I'd really like to see indirect object methods eradicated in Perl 6.
Too many precidence problems, too many special cases, too confusing to
teach.  Muddles up the otherwise simple function call.

Its syntactic sugar, and there's too much crap, not enough sugar.

However, as Damian said, dumping indirect objects is a seperate issue.
This RFC is about fixing them, so let's look at it like that.

I see a flaw.

    The following order of function parsing should apply to Perl 6:
    
    1. The current package should be checked for a function
    by that name (including any imported ones), consistent
    with current behavior.
    
    2. Argument 1 should be checked to see if it is a valid
    object reference. If so, the method should be checked
    for existence as a member.
    
    3. AUTOLOAD should be called.
    
    The only new step here is step #2. Notice that this does NOT override
    current-package functions. Only if a function is not found in the
    current package is the translation attempted.

Okay, now look at this example...

    $xa = abs($x);         # main::abs($x) || $x->abs

Apparently, CORE will not be checked as part of the function parsing!
Here's a few cases where this will screw up...

- $x is an object with numerific convertion (0+) overloaded.  In this case,
  the programmer might not even be aware that $x is an object.  If 
  $x->can('abs') then instead of the expected CORE::abs($x), $x->abs will
  be called.  Unexpected behavior.  This can be generalized into any sort of 
  overloaded object.  It won't mix.

- $x is a normal object and writes this:

        foo($x);

  Intending to call main::foo() with $x as the first argument.  However, he's
  forgotten to import foo(), a common mistake.  Normally, this would
  be a simple error found by Perl.  With this RFC, if $x->can('foo')
  its not an error anymore!  It becomes a method call.


Now, about that first comma.

It smells like allowing the first comma to be optional is a potential
nightmare for the parser.  

Worse yet, you're turning a common typo into syntax!  Accidentally
dropping a comma or a period is a fairly common mistake, but its also
a simple syntax error which Perl catches easily.  Now if it suddenly
has language meaning, the error messages can become mysterious.

    foo($x @args);

This might call $x->foo(@args), or it might complain that $x is not an
object, or it might complain that foo() is not a method of $x.
Depends on the situation.  Problem is, you've taken a simple error and
turned it into a complicated on with potentially confusing messages.
Or worse, it becomes valid syntax!

(I'd like to note that the current error "Array found where operator
expected" isn't too great either.)

The caveats associated with:

    $r = new(CGI @args);

also bother me.  The conflict between CGI being a function in the
current scope and it being a class is hairy.


Which all leads me to want to dump indirect object syntax altogether,
but I already said that. :)

-- 

Michael G Schwern      http://www.pobox.com/~schwern/      [EMAIL PROTECTED]
Just Another Stupid Consultant                      Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
          - Unknown narrator speaking about Anime

Reply via email to