HaloO,
Leon Timmermans wrote:
I assumed a new role makes a new interface. In other words, that a
type that happens to do Pollable, Mappable, Statable and Ownable
wouldn't automatically do File in that case.
I also think that a new role File that does also the four others
is a new type on its own, particularly if it has a body that defines
additional stuff.
If I was wrong my abuse
of subset wouldn't be necessary. Otherwise, maybe there should be a
clean way to do that. Now I'm thinking of it, wouldn't something like
our ::File = Mapable & Pollable & Statable & Ownable;
do the trick?
IIRC, we deemed junctions as unfit for type constructors. A type
constraint that requires all types to match uses juxtaposition
and if one interface is enough a non-junctive | is used. So without
the ampersands it should be fine.
On Fri, Dec 12, 2008 at 9:23 AM, Dmitry Karasik <dmi...@karasik.eu.org> 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're right. However if you use the roles
properly this shouldn't happen because you'd get an error much sooner.
If your interface expects a Seekable and you pass it a pipe, it will
immediately raise an error, instead of waiting until you try to use
it.
Yes, I like the idea of a fine-grained set of roles and types
composed of it by juxtaposition. This allows signatures to state
their requirements clearly and machine enforcable. IOW, your approach
precisely solves the problem that fat interfaces can raise errors
only lately, that is when a call is attempted.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
