At 07:40 PM 4/10/2002 +0100, Piers Cawley wrote:
>Melvin Smith <[EMAIL PROTECTED]> writes:
>
> > At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
> >>"Mark J. Reed" wrote:
> >> >
> >> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> >> > > method m1
> >> > > {
> >> > > m2; # calls method m2 in the same class
> >> > Yes, but does it call it as an instance method on the current invocant
> >> > or as a class method with no invocant? If the former, how would you
> >> > do the latter?
> >>
> >>Should both be allowed to exist? Do both exist? Why do both exist?
> >>(with the same name). If only one exists, then that would be the one
> >>that gets called.
> >
> > I'd hope it would assume "instance" method until told otherwise,
> > since static methods (class methods) are seldom used in OOP.
>
>Um... don't you use factory methods? I know I do.
Sure I do, but it doesn't comprise more than 5% of the methods I call
on objects. And in C++ or Java, when I need a class method, I
specify it with the keyword 'static'. Along with it comes the restrictions
of not accessing instance data, etc. etc.
I wiiiiill admit my applied usage of OOP is biased by the C++/Java
lense. :)
While I may be misunderstanding Perl6 syntax, I'm not misunderstanding
OOP, these are basic concepts to C++ and Java and how many
other languages; granted, I'll try to play catchup with reading the Apocs and
Exegeses over, but it appears from the discussion thread that people
are discussing class/instance method mixing as if this were a new
concept to OOP. My feeling is you ask yourself: "What makes sense and what
does the compiler and runtime engine have to do based on the given
rules that we choose".
Its clear if invocant of foo() is the class, and not the instance, calling
an instance method from class scope without creating an object to work
with should either be disallowed, or analyzed to check whether it actually uses
instance data. I'd choose former which is what C++ and Java does.
-Melvin
