Re: More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)
chromatic wrote:
On Tue, 2005-07-19 at 18:47 +0200, TSa (Thomas Sandlaß) wrote:
I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of
class Foo {...}
roleFoo {...}
sub Foo {...}
method Foo {...}
subtype Foo of Any where {...}
in the same scope should be a simple redefinition/redeclaration error.
I don't understand this. What does a scope have to do with a namespace?
I meant a scope of source code, basically everything delimited by braces.
And that nesting of braces *is* the namespace, or not? Well, at least the
compile time view of it.
The Perl6 namespace is available at runtime as well. But it is beyond me
how much these differ. But for the specification of the language only the
source code aspect is relevant.
Why does a code object constitute a type?
Is this more a 'how do function types work' question or
are you doughting the usefullness of this concept for Perl6?
The sort function e.g. takes a parameter of type Comparator
which is a code type describing instances that accept two parameters
of the type that is to be sorted and return a value of a type
that describes the relative order implemented by the comparator.
Actually the Comparator is usually a parametric type, that is
instanciated with concrete types and thus forming a non-parametric
code type. The invokation of such a type are the instances of the
type. During a sort run many of these instances are created.
I can understand there being separate types, perhaps, for Method,
Submethod, MultiSub, MultiMethod, and so on,
... and subtypes thereof.
but I don't understand the
purpose of sharing a namespace between types and function names,
What should 'mysubtype' in the following signature
sub blah ( mysubtype sref )
{
my Int $x = sref( Str, 23, Foo.new );
}
mean if not a constraint of the type of sref?
Above it is used as a function that accepts (Str, Int, Object)
and returns Int. Depending on the definition of ::mysubtype
this usage is erroneous or not. I ask myself---or @Larry---how
the same effect could be achieved without the indirection through
a name. Perhaps:
sub blah( Code[Str, Int, Object -- Int] sref ) {...}
The same question arises when ::subtype shall be declared:
subtype mysubtype of Code[Str, Int, Object -- Int];
subtype mysubtype of Code:(Str, Int, Object) returns Int;
nor of
having funcitons declare/define/denote/de-whatever types.
Here's an attempt of code joke around foo (ignore at will)
class foo
{
submethod postfix:{'( )'} ( $x ) { say $x }
}
sub foo( foo ) { say foo }
sub bar ( foo $foo, foo foo )
{
$_ = foo.new;
my foo $f = \foo;
my foo f = \foo;
my foo @f = foo;
say foo(23);
say .(42);
}
--
TSa (Thomas Sandlaß)
Re: More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)
HaloO chromatic,
you wrote:
Have I mentioned before that I think you should be able to say:
class Foo
{
method foo { ... }
method more_foo { ... }
}
class Bar does Foo
{
method foo { ... }
}
... probably get a compile-time error that Bar doesn't support
more_foo()?
We've discussed that when I was ranting about the type lattice
and co- and contravariance...
I'm not sure what my position back then was but now I agree
because I see CLASS as a subtype of ROLE. The only problem
is that $Larry said that he doesn't want parametric classes.
I see a reason to differentiate between roles and classes on the
metalevel, but the argument is not as strong on the user-level.
I go further to see little reason to distinguish between role, class,
and type names (and what reason there is is for introspective
capabilities, not standard user-level type checking).
I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of
class Foo {...}
roleFoo {...}
sub Foo {...}
method Foo {...}
subtype Foo of Any where {...}
in the same scope should be a simple redefinition/redeclaration error.
OK, sub and method can escape from this fate by means of the keyword
multi and different sigs.
Since sigils somehow define references Foo could mean e.g. a classref
while ::Foo could be a Code type. If we then also promote . to a primary
sigil for Method... hmm have to think about that!
--
TSa (Thomas Sandlaß)
More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)
On Mon, 2005-07-11 at 17:47 -0400, Stevan Little wrote:
I actually agree with you on that. But I would like to clarify it to
say that:
Foo.isa(Bar) # Foo.meta.isa(Bar) || Foo.meta.does(Bar)
... meaning that the .isa() which is supposed to be aliased into the
class from .meta is actually this.
I've always thought that .does() should check .isa() as well. That's
how Class::Roles works in Perl 5.
If you *really* need to know that Bar inherits from Foo, there's .isa().
If all you really care about is that Bar is Liskov-a-rific with respect
to Foo, use .does(), which checks that Bar inherits from or does the
role of Foo, whether it mixes in any methods or not.
Have I mentioned before that I think you should be able to say:
class Foo
{
method foo { ... }
method more_foo { ... }
}
class Bar does Foo
{
method foo { ... }
}
... probably get a compile-time error that Bar doesn't support
more_foo()?
I see a reason to differentiate between roles and classes on the
metalevel, but the argument is not as strong on the user-level.
I go further to see little reason to distinguish between role, class,
and type names (and what reason there is is for introspective
capabilities, not standard user-level type checking).
-- c
