Bug #74574 for MooseX-Types-NumUnit: Doesn't actually use MooseX::Types

For the purposes of staying in the fold, I would rather try to have MX::T:NumUnit rely on MX::T. As you notice, there really isn't a well defined place to put non-MX::T types. It was for that reason that I made my 2 global types things that weren't likely to be stumbled on. My fear is how well my logic can handle the namespaced types. It might be fine, I'm just not sure. If I really can't fit it into the framework I guess it should leave the namespace. Still it goes to show that being under a namespace can give a certain (sometimes false) impression. My blog knows it, even if my modules don't. Sorry about this, I didn't mean to be a bother, but I also didn't know where it should go. Perhaps this is `MooseY::Types::NumUnit` :-0 On Tue, Jan 31, 2012 at 4:32 PM, Dave Rolsky via RT <bug-MooseX-Types-NumUnit@rt.cpan.org> wrote: Show quoted text

From a Devil's advocate point of view, perhaps MooseX::Types should have been named MooseX::TypeLibrary. I have been racking my brain trying to think of a good namespace for this module. My favorite so far is further polluting MooseX:: with MooseX::NumUnit. You can see how this again just confirms the point of blog post. Moose:: is by convention (and rightly so) for official Moose business only. But since MooseX::Types squats on what really is the most descriptive name for an Unofficial Type for Moose, I am left in the cold. Again the best solution is to work MooseX::Types::NumUnit back into the fold. Its been a frustrating day. Show quoted text

Show quoted text
Please take what I am about to say impersonally because I think the work that you and Jesse and Stevan and Florian have done for Perl is spectacular. Moose has been a godsend. That said, if the type system is so global and fragile that the built-in simple way to make types should not be used by anyone, and further they must use the fairly magical and (sorry) inscrutible MooseX::Types, then the type system needs to be re-thought. MooseX::Types::NumUnit has an elaborate system of anonymous type generators which represent subtypes of NumUnit which is a subtype of Num, but with automated from_Str conversions. Even were this the only consideration, I could probably make this all work, but I also have an internal implementation of MooseX::AlwaysCoerce which will set coerce => 1 for all NumUnit types. This is the logic that I worry about when sitting under MooseX::Types. When I get a chance I will try to see how well it can work. A much easier fix might be to emulate the way that (I think) MX::T does its magic. I could make an anonymous type to represent NumUnit (say $numunit), then I could make a nullary exportable function NumUnit() which returns that anonymous type. This could then let me use the fully qualified path to the anonymous type inside the logic which emulates MX::AC. I know that seems convoluted, but it would keep from polluting the now universally guarded types namespace. Breathe. Ok I'm back. Sorry, you have caught me on a couple of days where perhaps I shouldn't be answering mail.

Show quoted text
/me wipes brow I'm glad to hear you say that. I was afraid I was being irrational. I would be happy to try to think of something. For a first step, would it be hard to implement a warning when a second type of the same name is created? I will think about this. And I will get to trying to work out this module's global-ness the next time I have a chance. Again, and I really mean it. Thanks for all you (and the other devs) do. Pardon that previous rant of mine, its not who I usually am. Joel Berger

Fixed in GitHub repo. Will be 0.02 release. On Wed, Feb 1, 2012 at 1:41 PM, autarch@urth.org via RT <bug-MooseX-Types-NumUnit@rt.cpan.org> wrote: Show quoted text