On Fri, Dec 12, 2008 at 3:04 AM, Jon Lang <datawea...@gmail.com> 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 "does Mappable does Pollable does Statable does Ownable"
> (barring potential conflicts between Mappable, Pollable, Statable, and
> Ownable which File would presumably resolve).
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. 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?
On Fri, Dec 12, 2008 at 3:52 AM, Mark J. Reed <markjr...@gmail.com> wrote:
> As Jonathan said, I think composition makes more sense here... but what if
> you have an interface that expects an IO object and does nothing with it but
> pass it into some other interface? How does it declare that? It seems like
> there still needs to be a generic superrole that means "some non-empty but
> unspecified subset of these roles" - maybe "Closable" would work, but it's
> not real clear.
Yeah, I wasn't clear on that, but I agree there should be some base
role shared by all these roles, though I'm wondering if that should be
shared by all handles or just IO handles. I see no reason why
"Closable" should be limited to IO handles, but I do see a use for
being able to indicate you're talking about an IO handle. I'd say it
makes sense to define IO as Readable | Writable.
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