develooper Front page | perl.perl6.language | Postings from January 2004

Re: calling functions/class methods

Thread Previous
From:
Luke Palmer
Date:
January 30, 2004 04:45
Subject:
Re: calling functions/class methods
Message ID:
20040130124422.GA5466@babylonia.flatirons.org
Ph. Marek writes:
> Hello everybody,
> 
> first of all please forgive me if I'm using the wrong words - I'm not up to 
> date about the (current) meanings of methods, functions, etc.
> 
> 
> I read the article
> 	http://www.cuj.com/documents/s=8042/cuj0002meyers/
> 
> There is stated (short version - read article for details):
> In C++ there are member functions, which are called via
> 	object.member(parameter),
> and non-member (possibly friend) function, which are called via
> 	function(object,parameter).
> 
> I wondered whether perl6 could do both:
> - When called via object.member, look for a member function; if it is not 
> found, look for a function with this name, which takes an object as first 
> parameter.
> - When called the other way, look first for the function, then for a member.

Something like this has been decided.  It's not quite as permissive as
the scheme you describe.  It basically says that:

    $foo.member;

Is equivalent to:

    member $foo;

If no non-member C<member> has been defined.  However, it doesn't go the
other way 'round, because although Perl 6 is adding types, the majority
of programs will remain untyped, and that would get pretty dangerous.

I think single-invocant multimethods are synonymous with real methods.
So C<bar> in:

    class Foo {
        method bar(Baz $baz) {...}
    }

Is used the same was as in:

    multi sub bar(Foo $foo: Baz $baz) {...}

Hmm, but if you can use a comma anywhere you can a colon in a
multimethod call, that begs for:

    multi sub bar(Foo $foo, Baz $baz) {...}

To be usable as:

    $foo.bar($baz) {...}

I think it's a good thing to allow re-factoring of methods out into
multimethods and vice-versa, without changing the calls.  Regular subs
shouldn't be able to be called with method syntax, though.

Luke

> 
> So both ways are possible, and in the (not-interfering) normal situation (only 
> one of member/function defined) it would support encapsulation, in that a 
> caller does not need to know if this function was a member or not.
> 
> 
> I fear that I'm on a completly wrong track, or that this has been decided - 
> but I didn't find something about this.
> 
> 
> Regards,
> 
> Phil
> 

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About