Sorry for the delay in responding. I got distracted by YAPC. On Mon, Jun 22, 2009 at 9:35 AM, Ovid<[email protected]> wrote: > > ----- Original Message ---- > >> From: Chris Prather <[email protected]> >> >>That >> said afaik currently methods are only composed at the Class level. >> Moose's Role application to Instances create an anonymous subclass, >> apply the role to the anonymous subclass, and then rebless the >> instance into that subclass. In your example you wouldn't have an >> instance that is blessed into a class that lacks an as_xml method, if >> you did and composed the Role against it you would *want* that >> composition to choke. You seem to be trying to make contractual >> obligations for Runtime at Compile time, but I think you're doing it >> poorly here. The promises() keyword here doesn't resolve the fact that >> the method *might not* exist at runtime, at which point we want the >> composition to fail, all it does is let us do an end-run around what >> is effectively a Runtime operation (applying a Role to an instance) so >> we can do it at compile time instead ... what's the benefit here? > > To summarize what I think you've said, you think that this is a bad idea: > > package My::Class; > use Moose; > with 'Does::A::Role::Which::Requires::A::Method'; > > promises qw( methods a role might require ); > > Your objection is that the method(s) might not exist at runtime, therefore > making a promise which might not be kept is a bad thing.
Sort of. We already make promises which might or might not be kept with the tools you mention below, I think the problem I have is making an explicit promise that may not be kept. The explicit-ness of the having a special keyword for these cases to me worries me. > You may very well be right. Giving people the flexibility to hang > themselves, though, seems to be what Perl is all about :) > > There are few use cases I see. First is the obvious example of another role > being applied at runtime and supplying the promised method. The second is a > method being provided via AUTOLOAD. I certainly don't recommend AUTOLOAD, > but sometimes it's useful. Applying another Role at runtime is I think a valid case, but I believe if you apply both roles at hte same time Moose will sort it out just as if you'd done it with with(). If this doesn't happen (and stevan may argue with me) I'd consider it a bug. Methods provided by AUTOLOAD ... well there are forward declarations and other ways around that that are similar to promise, I really dislike the idea of even tangentially promoting a anti-best-practice by adding a keyword. > Someone also might try to use SelfLoader to load methods on demand. When > this happens, ->can($method) fails until we have our first method call > (again, I'm unsure this would be a good idea with Moose). This seems similar to AUTOLOAD (I actually had never heard of SelfLoader before this) and I might argue that using the MOP would be a better solution and there may be a way to do this with MooseX:: to make things work cleanly. Certainly actively installing the method using ->meta->add_method() would be the reccomended solution for dynamic method loading ... > So while there are a number of areas in which we find that methods might not > exist at composition time and implementing promises() might help, I also > understand your concern and I'm not strongly wedded to this proposal, so if > it doesn't make people's socks roll up and down, so be it :) I understand better now what you were getting at, but I'm really not convinced that a new keyword is the right solution. I'll try to corner stevan (again) and ask about it some more. Certainly there is always implementing an idea in the MooseX:: space to test out these ideas. If something like this *couldn't* be implemented in MooseX:: then *that* is certainly a bug. -Chris
