develooper Front page | perl.perl6.language | Postings from April 2005

Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?

Thread Previous | Thread Next
Larry Wall
April 5, 2005 08:45
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Message ID:
On Tue, Apr 05, 2005 at 04:00:09PM +0200, Thomas SandlaƟ wrote:
: Larry Wall wrote:
: >Roles cannot be derived from, so they're always final in that sense.
: >We should probably consider them closed by default as well, or at least
: >closed after first use.  If a role specifies implementation, it's always
: >default implementation, so overriding implementation always occurs in a 
: >class
: >instead.
: Ohh, is the following illegal?
: role Blahh does Blubber {...}
: Or is that just not considered derivation but, hmm, specialisation, 
: subtyping
: subroleing or some such?

It does composition.

: So, does the above produce the subtyping relation Blahh <: Blubber?

It means that both .does(Blahh) and .does(Blubber) return true.
It implies that Blahh contains the Blubber interface, but does not
imply that it has the same default implementation.  (It can, in fact,
advertise that it does Blubber but mangle the Blubber interface
completely if it chooses to, but that might be considered antisocial.
So the compiler might feel free to issue various warnings in that case.)

I, er, kinda fibbed above when I said that overriding implementation
only occurs in a class.  What I really meant was that, once you've
declared a role, it's closed, and you can warp its meaning only via
composition into some other role or class.  In isolation, a role
isn't really about subtyping--it's just a form of generic code.
But that same purity is what makes it useful for specifying subtype
relationships elsewhere.  And once roles start composing other roles,
it can be construed as a form of subtyping.

So, basically, yes.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About