in reply to Re: Get rid of the Indirect Syntax, please!
in thread On the Improvement of Exegesis 12

If I created $*OUT as an object, then yes, I would prefer to call the method on it. I don't want to have to remember that I need a colon after it an object reference just because the Perl6 parser needs it to disambiguate between a multimethod and a multisub.

Personally, I always felt that print() (and friends) has a difficult syntax to work with, given that it is different than every other other CORE function.

Frankly, if that syntax is important enough to you, you could just do something like (in Perl5 syntax): 

multisub print
{
    my $invocant = shift;

    if (UNIVERSAL::can( $invocant, 'print')
    {
        return $invocant->print(@_);
    }

    print ($invocant, @_);
}

[download]

Now, you treat it just like a regular function, if necessary.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Replies are listed 'Best First'.
Re^3: Get rid of the Indirect Syntax, please!
by adrianh (Chancellor) on Apr 18, 2004 at 23:00 UTC
    If I created $*OUT as an object, then yes, I would prefer to call the method on it.

    That's fair enough. You can of course do it that way. However some people do like the indirect syntax. I'm not such a person myself, but I can understand those who do like it. It can make slotting objects into a more procedural style of coding easier.

    I don't want to have to remember that I need a colon after it an object reference just because the Perl6 parser needs it to disambiguate between a multimethod and a multisub.

    Isn't it the difference between a subroutine call and a method call, rather than multimethod vs. multisub - the colon is just an indicator that the method (multi or otherwise) is being called in an indirect style?

    I admit I have only skimmed A12 so I may be getting the wrong end of the stick.

    Personally, I always felt that print() (and friends) has a difficult syntax to work with, given that it is different than every other other CORE function.

    But it's not just print. Is close $fh a subroutine call or a method call? I think that forcing the dot syntax for method invocation everywhere would result in something unperlish.

    Frankly, if that syntax is important enough to you, you could just do something like (in Perl5 syntax):

    Yes you could, but why should you if it can be well supported by the core? The indirect calling style has many problems in Perl 5, but in Perl 6 we have Class objects and an explicit colon syntax to disambiguate the nasty cases - so I don't really see the problem?

[reply]
[d/l]
      I thought about it last night and realized my real objection to Perl6's indirect object syntax. The indirect syntax would now require you to know whether or not the first parameter is an object where it didn't in Perl5.

      To me, the indirect syntax was a nice sugar when dealing with IO::File and friends (close $fh, in your example). That new() also played nicely was annoying, but I didn't care. I didn't have to know if $fh was an instance of IO::File or a GLOB or whatever. I just used it.

      Now, I am required to know, because I have to put the colon on if it's an instance or not if it's not. I have to keep track of whether it's an object or not. To me, that kinda invalidates the whole reason for the thing.

      Plus, do you really want close $*OUT:; all over your code, just to avoid $*OUT.close;?

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

[reply]
[d/l]
[select]
        Plus, do you really want close $*OUT:; all over your code, just to avoid $*OUT.close;?

        Nope, but then again I don't because Larry tells us:

        The colon may be omitted if there are no arguments (besides the invocant):

        Y'know it's almost like somebody spent a lot of time thinking all of this through :-)

[reply]
      Well reasoned response... adrianh++

      [Jon]

[reply]

In Section Meditations