TSa wrote:
Jonathan Lang wrote:
> If you're not using "multi", then the signature is superfluous for
> type-checking purposes.
I think that signatures do matter for type-checking! It is
an error to provide too few or to many positional args or
args with an incompatible type.
Mea culpa. I thou
HaloO,
TSa wrote:
When names have to be available as well, then we get an undefined
method that has to have two positionals and two named parameters such
that all four names appear to satisfy all conceivable call sites for
the two roles.
To get four names for two positional Parameters an 'is a
HaloO,
Jonathan Lang wrote:
If you're not using "multi", then the signature is superfluous for
type-checking purposes.
I think that signatures do matter for type-checking! It is
an error to provide too few or to many positional args or
args with an incompatible type.
Regards, TSa.
--
TSa wrote:
I don't know how close leaving an undefined method as described above
to the class designer comes to automated merge. Note that at no point
I'm arguing that the body be merged. I'm seeing guarantees that the type
system tries to hold up in favour of the users of roles.
If you're not
HaloO,
Jonathan Lang wrote:
Bear in mind, though, that signatures include not only type
information, but also parameter names; and method calls are permitted
to pass an argument into a given parameter by means of its name
instead of its position, so the names cannot be disregarded. For
instance
TSa wrote:
Jonathan Lang wrote:
> Please, no attempts to merge signatures. Instead, use multiple
> dispatch
That avoids the problem before it occurs. But do you expect
every role to provide its methods as multi just in case?
Conceded.
Bear in mind, though, that signatures include not only ty
HaloO,
Jonathan Lang wrote:
Please, no attempts to merge signatures. Instead, use multiple
dispatch
That avoids the problem before it occurs. But do you expect
every role to provide its methods as multi just in case?
Also, sub is an odd choice to use while illustrating role composition;
wh
This is the "dog does bark" vs "tree does bark" problem. You can assume that
the two methods "blahh" have naything semantically to do with each other at
all. Unless ther is a specif annotation from the programmer creating the Role
union that they are the same you must assume that they are diff
On 10/11/06, TSa <[EMAIL PROTECTED]> wrote:
HaloO,
with my idea of deriving a type lattice from all role definitions
the problem of subtyping signatures arises. Please help me to think
this through. Consider
role Foo
{
sub blahh(Int, Int) {...}
}
role Bar
{
sub blahh(Str) {...}
}
role B
HaloO,
with my idea of deriving a type lattice from all role definitions
the problem of subtyping signatures arises. Please help me to think
this through. Consider
role Foo
{
sub blahh(Int, Int) {...}
}
role Bar
{
sub blahh(Str) {...}
}
role Baz does Foo does Bar # Foo|Bar lub
{
# sub bl
10 matches
Mail list logo
