thod foo { "Foo::foo" } }
Imagine a code which would like to execute all submethods of all classes and
roles. Normally, it would traverse mro and all role concretizations of each
class from mro. In the example above such code would call submethod foo() from
R1 twice: for R2 and R1 itself! Of cou
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 91635d4f63b87815a9cd7605a8359a8914e1f6b5
https://github.com/perl6/specs/commit/91635d4f63b87815a9cd7605a8359a8914e1f6b5
Author: jnthn
Date: 2015-07-30 (Thu, 30 Jul 2015)
Changed paths:
M S14-roles
-special-names.pod
Log Message:
---
change Application to Systemic and Universal roles
The word Application is entirely misleading for describing the
various systems that form the execution context of your program, so
instead we'll have the role Systemic to express the notion of
-setting-library/Rules.pod
Log Message:
---
try to make S32::Roles useful by taking info from S05
/Exception.pod
Log Message:
---
Name exception roles more consistently
Martin D Kealey wrote:
George Boole also worked in several areas of mathematics. One of those was
what he termed "algebra of logic", hence "Boolean algebra" as mathematicians
know it now.
But what we (programmers) call "Boolean", although in line with his original
concept, is a pale shadow of wh
At 10:25 +1300 3/17/10, Martin D Kealey wrote:
>On Mon, 15 Mar 2010, Mark J. Reed wrote:
>> > Anything that can be made into a list is discrete.
>>
>> Not quite, since you can create lists whose members belong to
>> continuous sets, e.g. real numbers. Anything that naturally forms a
>> list, mayb
On Mon, 15 Mar 2010, Mark J. Reed wrote:
> > Anything that can be made into a list is discrete.
>
> Not quite, since you can create lists whose members belong to
> continuous sets, e.g. real numbers. Anything that naturally forms a
> list, maybe.
A discrete non-finite set is isomorphic to the se
On Sun, 14 Mar 2010, Jon Lang wrote:
> Ruud H.G. van Tol wrote:
> > Did you consider "discrete"?
>
> I think that "Discrete" could work quite well as the role that
> encapsulates the ways in which Integer and Gauss are alike. It may
> even be genralizable beyond that, although there might be some
On Sun, Mar 14, 2010 at 11:26 PM, Doug McNutt wrote:
> Anything that can be made into a list is discrete.
Not quite, since you can create lists whose members belong to
continuous sets, e.g. real numbers. Anything that naturally forms a
list, maybe.
> The other option is a function in the sense
At 18:14 -0800 3/14/10, Jon Lang wrote:
>There are discrete things that are not ordered (such as gaussian
>integers), and there are ordered things that are not discrete (such as
>real numbers or strings).
The word discrete as in "atoms are the discrete view of matter" may turn out to
be confusin
scussions
about core features only to the extent that the core needs to
anticipate such things.
I agree, in general.
Presumably, the core doesn't have to have any roles built-in that aren't already
composed into at least 2 core classes or roles, to keep things simpler.
I would
Darren Duncan wrote:
> I'm inclined to consider a "Discrete" to be broad enough to include Boolean,
> as well as every single enum type in general; it would also include Order,
> say. So I would also then add a more specific something, say
> "DiscreteNumeric".
There are discrete things that are n
Jon Lang wrote:
Ruud H.G. van Tol wrote:
Did you consider "discrete"?
I think that "Discrete" could work quite well as the role that
encapsulates the ways in which Integer and Gauss are alike. It may
even be genralizable beyond that, although there might be some discord
between theory and pra
Ruud H.G. van Tol wrote:
> Did you consider "discrete"?
I think that "Discrete" could work quite well as the role that
encapsulates the ways in which Integer and Gauss are alike. It may
even be genralizable beyond that, although there might be some discord
between theory and practice. (In theory
Darren Duncan wrote:
For the integer version, my understanding is that number theory already
provides a suitable term, "Gaussian integer", which is a complex number
whose real and imaginary parts are both integers.
So I suggest using "Gaussian" as the name option for an "IntComplex".
Or mayb
> "DD" == Darren Duncan writes:
Some tiny thoughts:
DD> ... I would consider "Numeric" more broad, such as to include
DD> anything that might conceivably be called a number, probably
DD> user-defined, that isn't representable by a "complex".
Is Numeric intended to have a guarantee of commut
, lcm, remainders, etc.) Perhaps we need a role to encapsulate
that notion, much like we have one that encapsulates the notion of
order (e.g., before/after). Or would that turn out to be unnecessary
clutter, seeing as how we only have two examples of roles that would
compose it (Integral and G
definitely has analogs comparable to the differences
between Integral vs. Real, in that Gaussian and Integral have the
concept of factors and everything that goes with them (e.g., primes,
gcf, lcm, remainders, etc.) Perhaps we need a role to encapsulate
that notion, much like we have one that enc
Follow-up, ...
4. If "Integral" is better called "Integer", or regardless ...
Would "Numeric" be better called "Number"? Would there by any objection to
renaming it such? What are advantages of the former over the latter?
Basically, same idea, if we're going more for nouns or adjectives ro
So, I've been looking more closely at Perl's native value types and associated
roles, and there are a few matters of their naming or availability that I have
questions or suggestions on.
1. As a general observation, I note that it is a common pattern for basic Perl
6 value types t
Darren Duncan wrote:
> Or actually, there is just one main thing I want to know right now ...
>
> You have roles that look like they're supposed to match one specific class
> each
> in particular, such as Boolean for Bool, Integral for Int, etc, ostensibly in
> cas
On Mon, Mar 8, 2010 at 12:40 PM, Darren Duncan wrote:
> Starting with the context of this piece of Synopsis 2:
>
> These types do (at least) the following roles:
>
> Class Roles
> = =
> Str Stringy
> Bit Numeric B
Starting with the context of this piece of Synopsis 2:
These types do (at least) the following roles:
Class Roles
= =
Str Stringy
Bit Numeric Boolean Integral
Int Numeric Integral
Num Numeric Real
Rat
Am Montag, den 19.10.2009, 16:43 -0700 schrieb Jon Lang:
> Raphael Descamps wrote:
> > I personally don't understand why we don't have a exclude and alias
> > operator in Perl 6 but I have not read all the synopses and don't have
> > an overview.
>
> I don't think that it's explicitly spelled out
traits paper and "freezing roles" try to
> solve this problem.
It's a problem that doesn't exist if you don't alias. However, you
run into another problem; namely, what to do if two roles provide
semantically incompatible definitions for the same method. To be
fair, ail
Raphael Descamps wrote:
> I personally don't understand why we don't have a exclude and alias
> operator in Perl 6 but I have not read all the synopses and don't have
> an overview.
I don't think that it's explicitly spelled out anywhere; but the
reason is fairly straightforward: exclude and alias
it might
do); I want to affect everything else that does both roles. That is,
I don't want my special log() method to work only for other types that
explicitly do NumLog; I want it to work for any type that directly
"does Numeric does Logging".
In fact, I can already refe
Am Freitag, den 16.10.2009, 10:54 +0400 schrieb Richard Hainsworth:
> Arising out of "Freezing Roles" is a related question.
>
> Suppose I download a module from CPAN with a role I want to use, but it
> introduces a method that I want that is in conflict with an existing
&
David Green wrote:
> Jon Lang wrote:
>>
>> This implies that both Logging and Math do Numeric, since the invocant
>> ought to be of a type that the class does.
>
> I would expect that
> role Logging { method log(Numeric $x:) {...} }
> means the invocant is really of type Numeric & Logging, witho
On 2009-Oct-17, at 1:55 am, Jon Lang wrote:
This implies that both Logging and Math do Numeric, since the
invocant ought to be of a type that the class does.
I would expect that
role Logging { method log(Numeric $x:) {...} }
means the invocant is really of type Numeric & Logging, without
th
isn't a class; it's a module. Modules generally don't do roles,
assuming that they even can.)
Note further that in the setting, you actually have Math::log:(Numeric
$x). Modules usually don't have methods, and so their routines
generally don't have invocants.
I thi
would be handy to be able to import it
under another name.
use Bar ;# import Bar::foo
use Baz :foo;# import Baz::foo as boo()
use Baz foo=>'boo'; # or spelled this way
)
Moreover, suppose that the two modules have roles with the same
name,
Arising out of "Freezing Roles" is a related question.
Suppose I download a module from CPAN with a role I want to use, but it
introduces a method that I want that is in conflict with an existing
method (say one taken from another CPAN module).
How should the method be aliased to
On 2009-Oct-5, at 3:41 pm, Jon Lang wrote:
Concerning that last one: would it be reasonable to have a Discrete
role
that provides a .succ method, and then overload the Range role?
I think a type needs to be Discrete and Ordered for successors to make
sense (e.g. consider a discrete unordere
tor ) { ... }
}
If so, then this approach might also be used to handle the special behavior
that comes with Numeric types:
role Range[Ordered Numeric ::T] { ... }
If the question is "can you define multiple roles with the same name,
but taking different signatures", then the
Consider a Range role that is parameterized (i.e., "Range of T" is a
perfectly valid thing to do). According to the spec, the definition of
Range depends on the nature of T:
* If the lower bound is Numeric, certain coercion rules are attempted on the
upper bound; otherwise, the two boundaries mus
Darren Duncan wrote:
> Jon Lang wrote:
>> So what about custom delimiters?
>>
>> q:2<1100100101>
>> q:8[57013]
>> q:16~DEADBEEF~
>
> Well, sure, if its useful; the idea is to amalgam numeric and Str syntax.
> However, because a Blob literal presumably just has 0..9,A-Z,_ characters in
> its payload
Jon Lang wrote:
Darren Duncan wrote:
On another tangent, since I'm not sure that Blob literals have been defined
in Perl 6 yet, I suggest something that combines aspects of numeric and
character string literals, meaning a radix prefix plus string quotes; for
example:
0b'1100100101'
0o'57013'
Darren Duncan wrote:
> These generally look like good changes, but I have a few points on which I'd
> like clarification or to make suggestions.
>
>> +Perl supports generic types through what are called "roles"
>> +which represent capabilities or interfaces. Th
pugs-comm...@feather.perl6.nl wrote:
Author: lwall
Date: 2009-09-29 19:50:27 +0200 (Tue, 29 Sep 2009)
New Revision: 28502
Log:
[S02,S03,S32]
add Stringy role
attempt to distinguish numeric objects from Numeric, Real, Integral, etc roles
split Pair into immutable PairVal and mutable Pair
split
uot;suggest" pairing.
For clarity, let me propose the following terminology: an "interface"
is a role with methods that suggest their implementations by default;
a "mixin" is a role with methods that mandate their implementations by
default. I could see adopting one of thes
HaloO,
Jon Lang wrote:
Well, yes and no. The class still has the final say on how a given
method is to be implemented; the only thing being debated here is
whether or not the class should have to explicitly pull rank to
redefine a method being provided by a role, or if it does so silently.
The
HaloO,
Jon Lang wrote:
I'd still like to get a synonym for "mandate role", though - a word
that captures the meaning of "unit of behavior".
A bit burdened with conflicting meaning but I think "mixin" is what
you are looking for.
Regards, TSa.
--
"The unavoidable price of reliability is simpl
would normally take precedence over
>> them.
>
> I really dislike this because it is contrary to the original idea of the
> "stateless traits" as defined in the original paper from Nathanael
> Schärli.
Agreed. OTOH, Roles are already contrary in this respect, because
ved
explicitly. The traits paper propose 3 different operators to solve such
conflicts: overriding, excluding or aliasing.
I definitively think that perl 6 roles should also have an excluding
operator because I think that *every* composition conflicts arrising
should be solvable by the class co
role's methods can be overridden as easily
> as they are.
As originally conceived in Perl 6 or in the original traits papers? In the
original research, the purpose of roles was to allow the decoupling of
responsibility and behavior (code reuse) found in inheritance-based OO systems.
T
Daniel Ruoso wrote:
> Jon Lang wrote:
>> The key to understanding roles is to note that roles don't implement
>> methods; classes implement methods.
>
> Er, while I see your point, Roles are not just interfaces... they are OO
> components that can be plugged into other
On 2009-Jul-12, at 12:43 pm, Daniel Ruoso wrote:
role R1 {
method foo() {...} # degenerates to interface
}
Just wondering: since merely declaring an interface will be common
enough, should we be able to say simply "method foo;" inside a role,
and drop the {...}?
class Bla does R2 {
m
Em Sex, 2009-07-10 às 15:39 -0700, Jon Lang escreveu:
> The key to understanding roles is to note that roles don't implement
> methods; classes implement methods.
Er, while I see your point, Roles are not just interfaces... they are OO
components that can be plugged into other classes.
Jon Lang wrote:
> "supersede" already has a meaning with respect to classes; and what
> I'm thinking of would apply to classes as well as roles; so I'm going
> to suggest another keyword.
>
> How about this: in role composition, "mandate" causes methods
ady have syntax that can be applied here:
>
> supersede method fuse {...}
> augment method fuse {...}
>
> It only remains to spec what those mean... :)
"supersede" already has a meaning with respect to classes; and what
I'm thinking of would apply to classes as well
On 2009-Jul-8, at 1:49 pm, Ovid wrote:
That being said, roles also have two competing uses (though they
don't conflict as badly). As units of behavior, they provide the
functionality your code needs. However, they can also serve as an
interface.
Maybe there are Interfaces, whic
Hi all,
It's been interesting to participate in the roles discussion so far, and
I'm happy to see there's a lot of interest in getting the right options
and the right defaults. I'm leaving tomorrow morning on vacation, and
will be mostly offline for a week or so (
On Wed, Jul 08, 2009 at 01:59:53PM -0700, Dave Whipp wrote:
> Ovid wrote:
>
>> I'd like to see something like this (or whatever the equivalent Perl 6
>> syntax would be):
>>
>> class PracticalJoke does Bomb does SomeThingElse {
>> method fuse() but overrides { ... }
>> }
>>
>> The "overrid
Ovid wrote:
I'd like to see something like this (or whatever the equivalent Perl 6 syntax
would be):
class PracticalJoke does Bomb does SomeThingElse {
method fuse() but overrides { ... }
}
The "overrides" tells Perl 6 that we're overriding the fuse() method
> from either Bomb or Som
Em Qua, 2009-07-08 às 12:49 -0700, Ovid escreveu:
> Behavioral: if you are primarily relying on roles to provide behavior
> (as we do at the BBC), then silently discarding the role's behavior by
> providing a method of the same name in your class can lead to very
> confusing b
real life find yourself needing to do things like this
> in
> real life? This is a sort of strained, if amusing, example. :-)
We use roles very, very heavily. We've found that the important thing is
choosing descriptive names. Thus, we rarely need to exclude methods from roles
becau
On Tue, Jul 7, 2009 at 7:13 AM, Jonathan Worthington wrote:
> (Note to the bored: feel free to beat me to adding something like these last
> two to the spectests...I'm away for the afternoon/evening.)
In r27483, I added these tests to S12-methods/multi.t:
http://dev.pugscode.org/changeset/27483
curious to hear the experiences of Ovid and others working with
roles a lot too. Is this a serious lacking in Perl 6's roles as
currently specified, or something that, in being absent, makes people
consider their design more? Knowing that will influence the solution we
choose, which has options
Jon Lang wrote:
Jonathan Worthington wrote:
Ovid wrote:
Though I have issues with Jonathan's approach (I don't like classes
silently discarding role methods as this has caused us many bugs at the
BBC), it's much cleaner that what I see here.
s/Jonathan's approach/Perl 6's approa
Jonathan Worthington wrote:
> Ovid wrote:
>> Though I have issues with Jonathan's approach (I don't like classes
>> silently discarding role methods as this has caused us many bugs at the
>> BBC), it's much cleaner that what I see here.
>
> s/Jonathan's approach/Perl 6's approach/ # at least, so fa
use the roles
as roles; it uses them punned as classes. But it does what you asked :).
Though I have issues with Jonathan's approach (I don't like classes silently discarding role methods as this has caused us many bugs at the BBC), it's much cleaner that what I see here.
On Wed, 8 Jul 2009, Ovid wrote:
Note that I have no idea where (if anywhere) the type goes in this.
Hopefully someone will correct me here. Note that this does not use the roles
as roles; it uses them punned as classes. But it does what you asked :).
Though I have issues with
e. Note that this does not use the
> roles
> as roles; it uses them punned as classes. But it does what you asked :).
Though I have issues with Jonathan's approach (I don't like classes silently
discarding role methods as this has caused us many bugs at the BBC), it's mu
rthless piece of junk! Why I should ...' }
}
class PracticalJoke does Bomb does Spouse {
}
class PracticalJoke {
has Bomb $bomb handles ;
has Spouse $spouse handles ;
}
Note that I have no idea where (if anywhere) the type goes in this.
Hopefully someone will correct me here
s only half of it; we want a() from one role and
b() from another, when both roles do a() and b(). Looks painful to me.
Right, and deference is the Wrong Tool For The Job in that case. The
right answer is more like:
class C does R1 does R2 {
method a() { self.R1::a() }
method b() { self.R2::b() }
}
Thanks,
Jonathan
() from one role and
b() from another, when both roles do a() and b(). Looks painful to me.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon univ
Brandon S. Allbery KF8NH wrote:
On Jul 7, 2009, at 07:34 , Jonathan Worthington wrote:
Jon Lang wrote:
I believe that the official word is to say:
class PracticalJoke does Bomb does Spouse {
method fuse () { Bomb::fuse }
method explode () { Spouse::explode }
}
This way won't work, be
On Jul 7, 2009, at 07:34 , Jonathan Worthington wrote:
Jon Lang wrote:
I believe that the official word is to say:
class PracticalJoke does Bomb does Spouse {
method fuse () { Bomb::fuse }
method explode () { Spouse::explode }
}
This way won't work, because:
* It's doing a sub call t
Jon Lang wrote:
I believe that the official word is to say:
class PracticalJoke does Bomb does Spouse {
method fuse () { Bomb::fuse }
method explode () { Spouse::explode }
}
This way won't work, because:
* It's doing a sub call to something that's a method
* The lookup won't wor
Ovid wrote:
Giving a talk about roles at YAPC::EU in Lisbon
Hey, me too! :-)
and I'm a bit stuck on how to translate a Perl 5 example into Perl 6. Basically, Imagine
a "PracticalJoke" class which has fuse() and explode methods(). It needs the
timed fuse() from a Bomb role a
On Tue, Jul 7, 2009 at 2:48 AM,
Ovid wrote:
>
> Giving a talk about roles at YAPC::EU in Lisbon and I'm a bit stuck on how to
> translate a Perl 5 example into Perl 6. Basically, Imagine a "PracticalJoke"
> class which has fuse() and explode methods(). It needs the
Giving a talk about roles at YAPC::EU in Lisbon and I'm a bit stuck on how to
translate a Perl 5 example into Perl 6. Basically, Imagine a "PracticalJoke"
class which has fuse() and explode methods(). It needs the timed fuse() from a
Bomb role and a non-lethal explode() fro
27;t call
'do_setup'. Oops.
Requiring methods and requiring methods to be called are different things. It might be a
nice feature to have roles which tie into "events". If a particular condition
doesn't hold true by, say, INIT time, the role fails.
How would I implement so
Ovid wrote:
> Requiring methods and requiring methods to be called are different things.
> It might be a nice feature to have roles which tie into "events". If a
> particular condition doesn't hold true by, say, INIT time, the role fails.
>
> How would I implement
setup'. Oops.
Requiring methods and requiring methods to be called are different things. It
might be a nice feature to have roles which tie into "events". If a particular
condition doesn't hold true by, say, INIT time, the role fails.
How would I implement something like
Timothy S. Nelson wrote:
> Another question for everyone - is there some way I can extend a class
> in such a way that it implements another role?
class A does B does C { ... }
where B and C are roles.
> For example, say I have a
> class Class::A that implements role Ro
Timothy S. Nelson wrote:
> On Mon, 23 Feb 2009, Moritz Lenz wrote:
>
>> Timothy S. Nelson wrote:
>>> Another question for everyone - is there some way I can extend a class
>>> in such a way that it implements another role?
>>
>>
>> class A doe
On Mon, 23 Feb 2009, Moritz Lenz wrote:
Timothy S. Nelson wrote:
Another question for everyone - is there some way I can extend a class
in such a way that it implements another role?
class A does B does C { ... }
where B and C are roles.
For example, say I have a
class Class::A
Adding roles to classes question:
Another question for everyone - is there some way I can extend a class
in such a way that it implements another role? For example, say I have a
class Class::A that implements role Role::A, and I want it to also implement
Role::B (and I provide an
On Fri, Feb 20, 2009 at 05:11:31PM +0100, TSa wrote:
> I'm unsure if the method dispatcher still falls back to subs,
It doesn't do that anymore, as it happens. You mark methods with "is
export" if you want that, and they automatically show up as both multis
and methods in any lexical scope that u
ven better
unless ($footree ~~ RootedTree) { warn "Unrooted tree"; }
or yet even better
my RootedTree $footree = something()
and it fails automatically...
*That's* what Roles are for...
I strongly support that position! A rooted tree to me also implies
the presence of parent no
e ~~ RootedTree) { warn "Unrooted tree"; }
or yet even better
my RootedTree $footree = something()
and it fails automatically...
*That's* what Roles are for...
daniel
On IRC, ruoso wrote:
wayland, one important thing I didn't mention in the mail is that I
understand that if some attribute is going to be undefined for some cases in
a Role, then it doesn't belong in that role, but in a more specialized
one...
the good thing about roles is that
On 2009 Feb 16, at 22:44, Timothy S. Nelson wrote:
So you can have a stream handle which does IO::Writeable, but will
throw an error on any attempt to write? Anyway, you've answered my
question in the other e-mail.
Not sure what you're getting at, but the obvious example is a
writeable h
ot;is export"
method in the generic IO role), that does whatever it needs to do to
provide you an IO object, including composing the roles according to the
features it supports.
An important concept of testability is to decouple the use of objects
from their creation. Global factory functions
nts on this].
One important thing here, is that the roles are not intended to
represent attributes of the object. For instance, IO::Readable and
IO::Writeable are not going to be composed depending on the parameters
you send to "open", but if you're in a Linux system, it should prob
b (maybe a "is export"
method in the generic IO role), that does whatever it needs to do to
provide you an IO object, including composing the roles according to the
features it supports.
One important thing here, is that the roles are not intended to
represent attributes of the object. For
Timothy S. Nelson wrote:
>Also, is there a simple way to know when I should be using a class
> vs. a role?
If you plan on creating objects with it, use a class. If you plan on
creating classes with it, use a role.
--
Jonathan "Dataweaver" Lang
Quick question about implementing things like the DBI/DBD split in
Perl6. In Perl5, you have code in DBI that essentially says:
-
$driverpackage = "DBD::$driver";
eval "use $driverpackage; \$obj = $driverpackage->new(\%params);";
-
This has always seemed ugly to me. Is there
27;£ File' would mean
'anything that can be used in the same sort of ways as File'. That
is, perl 6 uses nominative typing by default, while '£' would cause it
to use structural typing (i.e., "duck-typing") instead.
FWIW, I'd be inclined to have anonymous role
t 9:23 AM, Dmitry Karasik wrote:
Wouldn't the proposed solution raise an error if an unsupported role
method is tried? It's not that the proposed solution is inappropriate,
but the problem that I think you're trying to solve won't be solved
by it.
In the worst case scenario, you&
On Fri, Dec 12, 2008 at 3:04 AM, Jon Lang wrote:
> One of the things about roles is that once you have composed a bunch
> of them into another role, they're considered to be composed into
> whatever that role is composed into. So "does File" would be
> equivalent to &
Hi Leon!
Leon> Perl 5's solution is to use a fat interface, and raise an error if
Leon> an unsupported action is tried.
Wouldn't the proposed solution raise an error if an unsupported role
method is tried? It's not that the proposed solution is inappropriate,
but the problem that I thi
On Thu, Dec 11, 2008 at 8:16 PM, Leon Timmermans wrote:
> What I propose is using role composition for *everything*. Most
> importantly that includes the roles Readable and Writable, but also
> things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered
> (does Reada
On 2008 Dec 11, at 20:16, Leon Timmermans wrote:
One main problem with filehandles is that are rather diverse. The only
operation that all of them have in common is close. Reading versus
Be glad Xenix is dead. There were filehandles which didn't even
support close() (they were actually handl
Leon Timmermans wrote:
> What I propose is using role composition for *everything*. Most
> importantly that includes the roles Readable and Writable, but also
> things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered
> (does Readable), Socket, Acceptable (does Pollabl
very well.
What I propose is using role composition for *everything*. Most
importantly that includes the roles Readable and Writable, but also
things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered
(does Readable), Socket, Acceptable (does Pollable), and more.
That may however make some
On Wednesday 20 August 2008 15:16:12 Aristotle Pagaltzis wrote:
> It therefore seems necessary to me to specify dispatch such that
> method calls in the Dog role invoke the original Dog role methods
> where such methods exist. There also needs to be a way for a
> class that assumes a role to expli
1 - 100 of 420 matches
Mail list logo
