Nathan Wiger <[EMAIL PROTECTED]> writes:
> Nathan Torkington wrote:
> >
> > Yes! I mentioned the hypothetical
> > use strict 'types';
> > which would require all variables assigned to/from an object, and
> > all variables upon which method calls are made, to be typed like
> > this. Then the compiler can:
> > (a) optimize
> > (b) check at compile-time
>
> Hate to add a "me too", but I think this is a great idea. Nat needs to
> be able to torture himself in whatever sick C-type ways he desires. ;-)
> ;-)
>
> Seriously, though, this adds lots of potential benefits.
>
> > Polymorphic
> > types also becomes a problem: how to say that it's okay for a variable
> > to hold a Dog *or* a Cat, because we know that both of them have a
> > "pet()" method?
>
> Seems in order to satisfy this you'd have to have a common ancestor,
> Pet, which Dog and Cat inherited:
>
> my Pet $foofoo; # Can be Dog, Cat, or anything inherited
I'm kind of tempted to look at adding another pragma to go with 'use
base' along the lines of:
use implements 'Interface';
Which is almost entirely like C<use base 'Interface'> but with
'Interface' consisting of nothing but:
package Interface;
sub virtual_method;
sub virtual_method2 (#prototype);
...
1;
This is, of course, strictly unnecessary since C<use base> could do
exactly the same thing, and it is painfully Javalike. It kind of
depends on whether or not useful compiletime optimizations become
possible if a class is flagged as being 'virtual'.
> And if you didn't want inherited classes to count, you could specify
> that as an attribute:
>
> my Pet $foofoo : onlybase; # Must be a Pet, not Cat/Dog
>
> Or ":only", ":nochildren", ":justme", or any other similar word...
Why on earth would I want to do that? You just shot the polymorphism
in the head.
--
Piers
