On Apr 19, 2011, at 1:30 PM, Michael G Schwern via RT wrote:
Show quoted text> Queue: Moose
> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=67587 >
>
> On 2011.4.19 6:53 PM, MSTROUT via RT wrote:
>> It's only redundant in the simple case; there's no guarantee that what
>> the user wants is a simple "coerce each element if we're given an
>> arrayref of something else".
>>
>> Stevan, I and others have spent some time thinking about this, and
>> concluded that while this would DWIM for the simple case, in complex
>> cases it could easily become a footgun and as such is better explicitly
>> specified.
>>
>> Perhaps what you want here is to write a small MooseX:: module that
>> provides a one-line way to say "parameterize this and pass the coercion
>> down"? I'm not sure it'd be any simpler than
>>
>> coerce ArrayRef[Foo], from ArrayRef, via { [ map to_Foo($_), @{$_[0]} ] };
>>
>> or so (to_Foo being supplied by MooseX::Types, or you could do the
>> equivalent using the $tc object's coercion related methods).
>>
>> Either way, this isn't a bug - if you're interested in writing such a
>> MooseX:: we can discuss it further on the mailing list.
>
> Bug or over complication, it's still annoying.
> I understand that maybe someone sometime might want to do something special
> with a parameter coercion... but probably not. Moose is acting as if the user
> always wants an edge case and that makes extra work for the 90+% who don't.
I am not sure that 90+% is an accurate number, over the last 5 years this has come up a handful of times and no one found it annoying enough to actually write a MooseX:: for it.
Show quoted text> There's a simple way to resolve this and remove the ambiguity: if someone
> wants to do a weird coercion to ArrayRef[Foo] then make them, not everyone
> else, do the extra work and explicitly define a coercion for ArrayRef[Foo].
> For everyone else just do the simple coercion.
This would be a backwards incompatible change to high-level user code and therefore not something we would venture into lightly.
Show quoted text> PS What is the use case for differing parameterized coercions?
Well, I don't ever do them so I can't totally speak for mst, but my initial thought would be heterogenous lists. ArrayRef[SomeRole] might need specific coercions for each variation of SomeRole (different classes that did the role, other roles which also did the role, etc.), in which case you could not/should not trust Moose to do the type checks and coercions in a sane order and so it would be unlikely to match things correctly.
Show quoted text> PPS Assuming you like coercions, where is the potential to shoot oneself in
> the foot?
The problem here really is that types are global and coercions are attached to the global types. This is a "mistake" I made early on in Moose and no one has found a reasonable way to fix (especially since namespacing your types and MooseX::Types both fix it good enough for 90+% of peoples needs).
So there were a couple of issues that came up, I don't recall them all off the top of my head, but this has a pretty heavy action-at-a-distance possibility and we try to avoid that with coercions (see also "coerce => 1"). It was also pretty unclear what we should do if there is a coercion on the type itself *and* on the container type? Apply them both? In what order? It is hard to say what would be the common expectation here and equally hard to say what is *actually* the right way.
I know you always lean to the side of more DWIMery, this is evident in your modules and your requests of Moose, and while Moose does try to do a fair amount of DWIMery itself we avoid doing it in cases where the right thing to do it not clear and/or not something a sufficient amount of the core devs can agree on.
Now, as mst said, you are more then welcome to make a MooseX:: module that does this. And if it works well and a sufficient amount of people use it, we will certainly consider putting it in core.
And beyond all this, I recommend you take a less hostile and borderline insulting tone with your bug reports, you might want to take your own advice (
http://pghpw.org/ppw2007/talk/746) and try and different approach next time.
And finally, as mst said, take it to the list, any further comments on this bug will just be ignored and the status returned to rejected.
Thank you,
- Stevan
