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
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 formulated it this way
Luke Palmer wrote:
Jonathan Lang wrote:
> Agreed. The question is whether you think of a role as a set of
> methods ("intension set") or as a set of instances ("extension set").
> FWIW, it wasn't until this thread that I even registered that the
> latter possibility existed. Given the above con
In spite of Larry's comments, I will continue to entertain this idea
until it is solid to myself that I would be comfortable accepting it.
On 12/13/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
Agreed. The question is whether you think of a role as a set of
methods ("intension set") or as a set
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
TSa wrote:
Jonathan Lang wrote:
> Assuming that I understand the terminology correctly, I'll go further
> and say that one of the big differences between roles and subtypes
> (using the terms in their perl 6 contexts) is that roles conceptually
> operate on intension sets - everything about them
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
HaloO,
Jonathan Lang wrote:
Assuming that I understand the terminology correctly, I'll go further
and say that one of the big differences between roles and subtypes
(using the terms in their perl 6 contexts) is that roles conceptually
operate on intension sets - everything about them is defined
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
TSa wrote:
Secondly I figure you are operating on the extension set a role
defines. That is union produces a supertype aka the larger set
of instances. This is in accordance to the usual type theory
approach. Note that Jonathan operates on the intension set of roles
that is union produces a subty
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
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
22 matches
Mail list logo
