Re: Class methods vs. Instance methods
[EMAIL PROTECTED] wrote:
: class Dog {
: method tail { brown and short }
: };
:
: class Chihuahua is Dog {
: has $.color;
: method tail { $.color _ and short }
: };
:
: You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
: Chihuahua.tail. That's extremely counter-intuitive.
I don't think it's counterintuitive. You've defined Dog with an
invariant .tail but not Chihuahua. It's doing exactly what you asked
for under a prototype view of reality.
Except there are no such things as classes in a prototype view of
reality. Everything is an instance and there are no such things as
class methods. The entire idea that an object (::Dog) can call methods
that are for another object ($fido) is ... well ... it's a little off.
That's like saying any object can call any method from any other
object so long as that method is invariant.
In a prototype-instance system,
instance(Dog) isa class(Dog)
instance(Chihuahua) isa class(Chihuahua) isa class(Dog)
instance(Chihuahua) isa instance(Dog)
Note that instances inherit doubly, from own class and from parent's
instance.
But this does not imply that:
class(Chihuahua) isa instance(Dog)
So I don't see a problem.
Miro
Re: Class methods vs. Instance methods
On 1/19/06, Matt Fowles [EMAIL PROTECTED] wrote: Could you provide a concrete example of the advantage of this approach please? Failing that can you try and expand on your gut feeling a bit? May or may not be of use, but Larry's view sounds a bit like reconcilling the (again considered irreconcilable) gap between nominal and structural subtyping: http://cakoose.com/wiki/type_system_terminology#13 Where the empty class object is the degenerate case of the smallest possible structural type, so it can be fulfilled by anything more structurally rich as long as they share the same nominal constraint. Audrey
Re: Class methods vs. Instance methods
On 1/18/06, Audrey Tang (autrijus) [EMAIL PROTECTED] wrote: http://cakoose.com/wiki/type_system_terminology#13 Any practical programming language with structural subtyping will probably let you create and use aliases for type names (so you don't have to write the full form everywhere). However, the underlying type system will only consider the structure of the type when doing its job. What's wrong with Perl doing things that way? duck-typing with names ... sounds like a plan to me ... Rob
Re: Class methods vs. Instance methods
Rob Kinyon wrote:
Any practical programming language with structural subtyping will
probably let you create and use aliases for type names (so you don't
have to write the full form everywhere). However, the underlying type
system will only consider the structure of the type when doing its
job.
What's wrong with Perl doing things that way? duck-typing with names
... sounds like a plan to me ...
The thing is that people using .does(Name) and .isa(Name) is probably
expecting a nominal answer, not a structural one.
Although I do think Visual Basic's explicit duck-subtypes makes a lot of
sense:
my subset Duck where {
has $.half_life;
can doom:();
can quake:(-- Wolfenstein);
};
then you can apply it as a ducktype with names:
my Duck $donald = some_function();
$donald.quake; # assured to return a Wolfenstein object
It's already part of S12, by the way.
Audrey
signature.asc
Description: OpenPGP digital signature
Re: Class methods vs. Instance methods
On Thursday 19 January 2006 06:48, Rob Kinyon wrote: Any practical programming language with structural subtyping will probably let you create and use aliases for type names (so you don't have to write the full form everywhere). However, the underlying type system will only consider the structure of the type when doing its job. What's wrong with Perl doing things that way? duck-typing with names ... sounds like a plan to me ... Accidental structural equivalence is a problem -- it's one of the things wrong with C's so-called type system, for example. I like to think of roles as nominally-tagged (and checked) structural subtyping. When you're *defining* a type, its structure matters. When you're *using* it, its behavior matters. It would be nice to keep those two separate. -- c
Class methods vs. Instance methods
Today on #perl6, Audrey, Stevan and I were talking about $repr. A
tangent arose where Audrey said that the difference between class
methods and instance methods was simply whether or not the body
contained an attribute access.
Is this true? If it is, then I think it violates polymorphism as
demonstrated by the following:
class Dog {
method tail { brown and short }
};
class Chihuahua is Dog {
has $.color;
method tail { $.color _ and short }
};
You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
Chihuahua.tail. That's extremely counter-intuitive.
I think that class methods should be explicitly defined as class
methods and you cannot call a class method upon an instance, just as
you cannot call an instance method upon a class. Plus, this should be
determinable (for the most part) at compile time, which is a bonus,
imho.
Thanks,
Rob
Re: Class methods vs. Instance methods
On Wed, Jan 18, 2006 at 01:56:53PM -0500, Rob Kinyon wrote:
: Today on #perl6, Audrey, Stevan and I were talking about $repr. A
: tangent arose where Audrey said that the difference between class
: methods and instance methods was simply whether or not the body
: contained an attribute access.
:
: Is this true? If it is, then I think it violates polymorphism as
: demonstrated by the following:
:
: class Dog {
: method tail { brown and short }
: };
:
: class Chihuahua is Dog {
: has $.color;
: method tail { $.color _ and short }
: };
:
: You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
: Chihuahua.tail. That's extremely counter-intuitive.
I don't think it's counterintuitive. You've defined Dog with an
invariant .tail but not Chihuahua. It's doing exactly what you asked
for under a prototype view of reality.
: I think that class methods should be explicitly defined as class
: methods and you cannot call a class method upon an instance, just as
: you cannot call an instance method upon a class. Plus, this should be
: determinable (for the most part) at compile time, which is a bonus,
: imho.
I believe this is already determinble at compile time for the most part.
But I have a strong gut-feeling that over the long term it's going to
be important to be able to view a given object as either a partially
instantiated class or a partially undefined object, and for that we have
to break down the false class/instance dichotomy. And to the extent
that the dichotomy *isn't* false, we're trying to sweep classness into
the .meta object, which is the *real* class object in Perl 6.
Larry
Re: Class methods vs. Instance methods
Larry~ On 1/18/06, Larry Wall [EMAIL PROTECTED] wrote: But I have a strong gut-feeling that over the long term it's going to be important to be able to view a given object as either a partially instantiated class or a partially undefined object, and for that we have to break down the false class/instance dichotomy. And to the extent that the dichotomy *isn't* false, we're trying to sweep classness into the .meta object, which is the *real* class object in Perl 6. Perhaps I am just being short sighted, but I never saw this as a false dichotomy. In fact, every time I hear about these partially instatiated I cringe in horror about the strange halfway lands we might end up in... Oh no, this method can only be called on an object that is 3/4 initialized, and you supplied one that is 2/3 initialized that causes undefined behavior. Could you provide a concrete example of the advantage of this approach please? Failing that can you try and expand on your gut feeling a bit? Thanks, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Class methods vs. Instance methods
On 1/18/06, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Jan 18, 2006 at 01:56:53PM -0500, Rob Kinyon wrote:
: Today on #perl6, Audrey, Stevan and I were talking about $repr. A
: tangent arose where Audrey said that the difference between class
: methods and instance methods was simply whether or not the body
: contained an attribute access.
:
: Is this true? If it is, then I think it violates polymorphism as
: demonstrated by the following:
:
: class Dog {
: method tail { brown and short }
: };
:
: class Chihuahua is Dog {
: has $.color;
: method tail { $.color _ and short }
: };
:
: You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
: Chihuahua.tail. That's extremely counter-intuitive.
I don't think it's counterintuitive. You've defined Dog with an
invariant .tail but not Chihuahua. It's doing exactly what you asked
for under a prototype view of reality.
Except there are no such things as classes in a prototype view of
reality. Everything is an instance and there are no such things as
class methods. The entire idea that an object (::Dog) can call methods
that are for another object ($fido) is ... well ... it's a little off.
That's like saying any object can call any method from any other
object so long as that method is invariant.
: I think that class methods should be explicitly defined as class
: methods and you cannot call a class method upon an instance, just as
: you cannot call an instance method upon a class. Plus, this should be
: determinable (for the most part) at compile time, which is a bonus,
: imho.
I believe this is already determinble at compile time for the most part.
But I have a strong gut-feeling that over the long term it's going to
be important to be able to view a given object as either a partially
instantiated class or a partially undefined object, and for that we have
to break down the false class/instance dichotomy. And to the extent
that the dichotomy *isn't* false, we're trying to sweep classness into
the .meta object, which is the *real* class object in Perl 6.
I'm sure you understand the distinction you're making. I know I don't
and I've been trying to follow this discussion for the past year. I'm
may not be the brightest bulb in the chandelier, but I'm no 15W dimmer
switch, either.
Frankly, you should be using people like me, Matt Fowles, and the
other programmers on the list as sounding boards. If we're having
problems understanding the concept, then how are we going to explain
partially-instantiated classes on Perlmonks or #perl or clmp? Like
it or not, we're the sergeants in the Perl army. We're the guys
explaining all this stuff to the privates coming up the ranks. It may
be a nice extension to have, but I'm not sure this should be part of
the standard MOP.
Rob
