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 it. Regards, Leon