You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#65 proposes adding a trait to turn on coercion. In Moose, coercion is declared on the type, but must be explicitly turned on at each use. Usually in an attribute, but also in signatures.
I find this very tedious. #66 will mitigate this somewhat by allowing one to make coercion the default. However I would rather it was the default as its conveniences outweigh its dangers. The Moose arguments against coercion seem to come from the C world where types don't make much sense and coercion is a far fuzzier concept.
My use cases are mostly about coercing strings into objects. URI strings into URI objects. File and directory paths into Path::Class objects. I'd rather if I'm using a type with coercion that it just worked without having to specially tell it to work.
The text was updated successfully, but these errors were encountered:
#65 proposes adding a trait to turn on coercion. In Moose, coercion is declared on the type, but must be explicitly turned on at each use. Usually in an attribute, but also in signatures.
I find this very tedious. #66 will mitigate this somewhat by allowing one to make coercion the default. However I would rather it was the default as its conveniences outweigh its dangers. The Moose arguments against coercion seem to come from the C world where types don't make much sense and coercion is a far fuzzier concept.
My use cases are mostly about coercing strings into objects. URI strings into URI objects. File and directory paths into Path::Class objects. I'd rather if I'm using a type with coercion that it just worked without having to specially tell it to work.
The text was updated successfully, but these errors were encountered: