HaloO,
Larry Wall wrote:
Then we'd write our "done_by" role above as:
role Num-1.3-JRANDOM does STD:Num does Complex;
method re (--> STD:Num) { self }
method im (--> STD:Num) { 0.0 }
The first issue I see with this approach is that we get one
more contender for the plain name Comp
Larry Wall wrote:
I've been sloshing all this through my muddled head again, and I'm
beginning to see this as more of a naming policy issue, that is, an
authority issue. The problem with "done_by" is that you're modifying
something in place, which mixes up the one name to mean two different
thin
On Wed, Dec 13, 2006 at 11:13:32PM -0800, Jonathan Lang wrote:
: Unfortunately, this approach completely misses the boat in terms of
: what I was looking for in supertyping - namely, the ability to reuse
: portions of an existing interface (such as the aforementioned "extract
: an Order rol
HaloO,
Larry Wall wrote:
Or we could say that you can't reopen the Num role; you can only
reopen the Num class and mix in the Complex role. That's where it
stands at the moment.
This is not too bad an outcome. One question though: is the
augmentation of the class lexically scoped? Or does a m
TSa writes:
> Larry Wall wrote:
>
> >role Num is also does Complex {
> > method im {...}
> >}
>
> Is that the actual syntax?
Larry's words that you snipped introducing that code fragment were:
We might *possibly* get away with reopening roles like we can reopen a
class:
It see
HaloO,
Larry Wall wrote:
role Num is also does Complex {
method im {...}
}
Is that the actual syntax? I mean is it the keyword pair
'is also' or does 'also' by itself have a meaning? With
a more natural 'role Num also does Complex'.
but roles are really supposed to be fairly
HaloO,
Luke Palmer wrote:
For now (because of this example, in fact), I'm inclined to change the
proposal to "please don't design the language to prevent a module from
implementing supertyping". I think disallowing reopening of roles
will prevent that.
I might not have fo
the
creator of the new role has the responsibility to ensure that any
additions that he makes doesn't break any existing classes.
Unfortunately, this approach completely misses the boat in terms of
what I was looking for in supertyping - namely, the ability to reuse
portions of an existing interface
doesn't. For example, let's assume that whoever created the
Num role forgot to define an Order role for it. Supertyping would let
you create that role for yourself and would ensure that it has the
proper relationship with Num. That's what supertyping of roles should
be about: extract
On Wed, Dec 13, 2006 at 11:25:40AM +, Smylers wrote:
: Jonathan Lang writes:
:
: > For the record, I think that "superdoes" should be spelled "done_by".
:
: I think it's unlikely that Larry will incorporate any keywords that
: contain underscores -- certainly not without at least searching fo
n't. For example, let's assume that whoever created the
Num role forgot to define an Order role for it. Supertyping would let
you create that role for yourself and would ensure that it has the
proper relationship with Num. That's what supertyping of roles should
be about: extractin
HaloO,
Luke Palmer wrote:
Woah, that was a terrible passage. Let's try again. If your
declaration is "role Foo superdoes Bar".
* it is illegal to add a required method to Foo if Bar doesn't
already implement it or require it
With "required method" you mean an unimplemented method with a
t;supertype", "subtype", "superrole",
"subrole", etc. strictly due to a lack of a better alternative.
"Supertyping" only leads to a larger set of instances because a
parameter that asks for the supertype is willing to accept a subtype
in its stead.
Yes
Jonathan Lang schreef:
> what we need here is something that very
> clearly says "the reverse form of 'does'": if A does B, then B ___ A.
> Far more important that if it's one word or two is: "what fits most
> naturally in the gap?"
follows, trails, tracks, enforces, obeys, tolerates, enacts, end
Smylers wrote:
Jonathan Lang writes:
> For the record, I think that "superdoes" should be spelled "done_by".
I think it's unlikely that Larry will incorporate any keywords that
contain underscores -- certainly not without at least searching for a
single word that sums up the concept in question.
et of capabilities - while subtypes (i.e., objects with
"where" clauses) operate on extension sets - they're defined in terms
of the valid set of instances.
Incidently, I'm using terms like "supertype", "subtype", "superrole",
"subrole",
TSa schreef:
> Smylers:
>> Jonathan Lang:
>>> For the record, I think that "superdoes" should be spelled
>>> "done_by".
>>
>> I think it's unlikely that Larry will incorporate any keywords that
>> contain underscores -- certainly not without at least searching for a
>> single word that sums up the
HaloO,
Smylers wrote:
Jonathan Lang writes:
For the record, I think that "superdoes" should be spelled "done_by".
I think it's unlikely that Larry will incorporate any keywords that
contain underscores -- certainly not without at least searching for a
single word that sums up the concept in
HaloO Luke,
good to hear from you again!
you wrote:
I'd tend to agree. This is an important feature of an object system
for me,
And I hope for the rest of @Larry, too.
There is a nice duality in this specification. When you say:
role Foo does Bar does Baz {...}
You are saying Foo = B
Jonathan Lang writes:
> For the record, I think that "superdoes" should be spelled "done_by".
I think it's unlikely that Larry will incorporate any keywords that
contain underscores -- certainly not without at least searching for a
single word that sums up the concept in question.
Smylers
Luke Palmer wrote:
When you say:
role Foo superdoes Bar superdoes Baz {...}
You are saying Foo = Bar (+) Baz (+) ...; # union of Bar, Baz, and
the following spec
For the record, I think that "superdoes" should be spelled "done_by".
It may seem like that should be Foo = (Bar (+) Baz) (*)
On 12/13/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
Things work a little differently for required methods. When a
superrole requires a method be implemented, we (the language
designers) have a choise to make: it is illegal if the superrole
requires a method that the subroles don't implement or d
On 12/12/06, TSa <[EMAIL PROTECTED]> wrote:
HaloO,
Jonathan Lang wrote:
> In any case, one should never add
> anything while going from specific to general.
The crux of my example is that one indeed adds methods
in the supertype. The subtype receives a standard
implementation. This pattern is a
HaloO,
Jonathan Lang wrote:
In any case, one should never add
anything while going from specific to general.
The crux of my example is that one indeed adds methods
in the supertype. The subtype receives a standard
implementation. This pattern is applicable whenever
you have a case like the Num
For those of us who don't think in terms compatible with Type Theory,
the suggestion is essentially this: instead of going from general to
specific, go from specific to general. E.g., for a given relationship
::A.does(::B) or ::A.isa(::B), include a way to start with ::B and
then to define ::A in
HaloO,
I've mentioned the concept of supertyping in several posts
but now I want to dedicate a thread to it because it increases
the expressive power of Perl 6 if one can form abstractions
not only by creating subclasses and subroles but also by going
in the other direction. Here are som
26 matches
Mail list logo
