MooseX::Types to core?
Whenever we've talked about coring MooseX modules, it's mostly been MXAH and
MooseX::Types. Does anyone have any changes they'd like to see in MX::Types
before it becomes, say, Moose::Types? (Moose::TypeConstraints?)
For myself:
* Warn/die on subtype DeclaredType = as Foo = where { ... } (accidental
stringification) -- I thought someone had fixed this, but it came up as a
silent failure recently, so maybe not in all cases?
* Standardize on a best practice for parameterized non-global types (e.g.
ArrayRef[MyObject] vs. ArrayRefOfMyObject) and make documentation use it
consistently
* if the former, the RT bug about coercions needs to be fixed
* smarter renaming of imports -- e.g. if you try to import Foo from a type
library, with -prefix = 'My', it'd really be nice to get to_MyFoo and
is_MyFoo helpers instead of Myto_Foo and Myis_Foo
* MooseX::Types::Moose - Moose::Types::Native (maybe)
* Should Structured be included?
hdp.
Re: MooseX::Types to core?
On Tue, Sep 08, 2009 at 10:32:50AM -0400, Hans Dieter Pearcey wrote: Whenever we've talked about coring MooseX modules, it's mostly been MXAH and MooseX::Types. Does anyone have any changes they'd like to see in MX::Types before it becomes, say, Moose::Types? (Moose::TypeConstraints?) The one that keeps coming up whenever we have this discussion is that DateTime-new is broken, with the most straightforward usage of types. -doy
Re: MooseX::Types to core?
Excerpts from John Napiorkowski's message of Tue Sep 08 12:58:41 -0400 2009: Honestly, I'd argue that moving MooseX::Types to core is the opposite of what I'd like to see. What I'd what to see is a more cleanly and clearly defined TC system, with all the bits needed divorced from Moose (including something with the Registry that Stevan mentioned) and then Moose would leverage that and possible CMOP might define some interfaces and apis around like (like function support and attribute type checking). I'm not sure if that's the direction everyone agrees with though :) I still don't see your point. MooseX::Types is an interface to defining and using type constraints, as opposed to the core interface, which uses strings. Why would moving it into the core stop us from changing the underlying implementation later? Or, what about changing the underlying implementation later would require us to also change the interface? hdp.
Re: MooseX::Types to core?
On Sep 8, 2009, at 12:09 PM, Hans Dieter Pearcey wrote: Excerpts from John Napiorkowski's message of Tue Sep 08 12:58:41 -0400 2009: Honestly, I'd argue that moving MooseX::Types to core is the opposite of what I'd like to see. What I'd what to see is a more cleanly and clearly defined TC system, with all the bits needed divorced from Moose (including something with the Registry that Stevan mentioned) and then Moose would leverage that and possible CMOP might define some interfaces and apis around like (like function support and attribute type checking). I'm not sure if that's the direction everyone agrees with though :) I still don't see your point. MooseX::Types is an interface to defining and using type constraints, as opposed to the core interface, which uses strings. Why would moving it into the core stop us from changing the underlying implementation later? Or, what about changing the underlying implementation later would require us to also change the interface? hdp. I think the suggestion is that type constraints be completely divorced from Moose so that other possibly non-Moose/CMOP projects can use it w/ o requiring Moose/CMOP. Or is that missing the mark John? chris
Re: MooseX::Types to core?
Excerpts from Chris Fields's message of Tue Sep 08 13:14:20 -0400 2009: I think the suggestion is that type constraints be completely divorced from Moose so that other possibly non-Moose/CMOP projects can use it w/ o requiring Moose/CMOP. Or is that missing the mark John? I understand the suggestion, and it is a reasonable one. Why would such a type constraint implementation be mutually exclusive with MooseX::Types going into core? Wouldn't we just reimplement Moose::Types in terms of this new independent code? hdp.
Re: MooseX::Types to core?
The TC objects use C::MOP level attributes though, so no types. Yes, I think it could be totally pushed outside of Moose, however a few things would need fixing, such as the type registry. If you were potentially using the TC system for something non-Moose related and didn't want Moose types you would want your own registry. If you were using it along with Moose then you might want it use the Moose registry as well. The registry object itself is hierarchal, but nothing has really taken advantage of that feature (it was originally added so that we could make package level registries that would inherit from the global registry). - Stevan On Sep 8, 2009, at 12:05 PM, Jesse Luehrs wrote: On Tue, Sep 08, 2009 at 08:55:14AM -0700, John Napiorkowski wrote: I've spent a lot of time thinking about the intersections of Moose and Type Constraints. My general conclusion is that I think it's correct that TC and Moose general be detached (and I'd love to see more detachment) since people have uses for type constraints beyond Moose. That said, I think there is a bigger connection between TC and Class::MOP, since my imagination is telling me that Moose will eventually be more and more about suger and use, and functionality will migrate toward CMOP. For example, I know we keep kicking around the idea that Roles should be in CMOP. I also personally think some of the bits in MooseX::Declare related to method signatures should either be in CMOP or at least coordinated with a more rigorous interface defined by CMOP. So again, my imagination is saying type constraints are build on top of CMOP, and consumed by Moose or others. In a more radical line of thought - could the type constraint system be an entirely standalone module? Are there any parts of it that rely on either Moose or Class::MOP? I guess the main issue would be circular dependencies, since the tc objects use attributes, and attributes have type constraints, but I wonder if there isn't a way to get around that. Conceptually, the type constraint system seems pretty separate already. -doy
Re: MooseX::Types to core?
- Original Message From: Chris Prather perig...@gmail.com To: John Napiorkowski jjn1...@yahoo.com Cc: moose moose@perl.org Sent: Tuesday, September 8, 2009 1:41:39 PM Subject: Re: MooseX::Types to core? On Tue, Sep 8, 2009 at 1:32 PM, John Napiorkowskiwrote: - Original Message From: Hans Dieter Pearcey To: moose Sent: Tuesday, September 8, 2009 1:21:51 PM Subject: Re: MooseX::Types to core? Excerpts from Chris Fields's message of Tue Sep 08 13:14:20 -0400 2009: I think the suggestion is that type constraints be completely divorced from Moose so that other possibly non-Moose/CMOP projects can use it w/ o requiring Moose/CMOP. Or is that missing the mark John? I think cut from Moose yet, but not from CMOP. I think we will need to think the relationship between CMOP and TC is complex. TC would be build on CMOP, but CMOP would want a TC system for full functionality (as if someday we decided to move some of the method signature checking to CMOP, which is where I think it would be most useful, but I could be wrong). I understand the suggestion, and it is a reasonable one. Why would such a type constraint implementation be mutually exclusive with MooseX::Types going into core? Wouldn't we just reimplement Moose::Types in terms of this new independent code? hdp. Yeah, totally. As per my last email I agree with the sentiment here, with the caveat regarding backcompatibility. CMOP has always been (in my mind) a formalization of Perl5's implicit MOP. While it's not 100% accurate that is the general driving principle from what conversations we've had over the years. I like the idea of having TCs spun off into their own creature and Moose::Types built upon this creature ... but I hesitate to say things like Method signature checking should go into CMOP since there is no such facility in Perl5 itself and such a facility doesn't compile away clean like say Roles do. That said ... CMOP would should It's possible the way we are doing it now with MooseX::Declare is essentially the correct way, isolating the method sig stuff in it's own dist (as well as the actual parsing of the signature string in it's own class). I'm not sure. I can see either side. However, I think the interface for the signature might be usefully built in, rather than the actual implementation. That would offer guidance to people writing the implementations, although right now we just have the one. (eventually) have some facility for introspecting Lexical Types since those do exist in Perl5 (and as such we can push their implementation into something more useful). -Chris I don't know enough about Perl guts, but when people ask me what I'd like to see in Perl 5.12 I usually say more exposure of these lower level bits to make is easier (and probably faster and more stable) to expand upon them. Maybe we already have what we need though. I'm not enough of a C programmer to be able to tell. john
Re: MooseX::Types to core?
- Original Message From: Hans Dieter Pearcey h...@pobox.com To: moose moose@perl.org Sent: Tuesday, September 8, 2009 1:21:51 PM Subject: Re: MooseX::Types to core? Excerpts from Chris Fields's message of Tue Sep 08 13:14:20 -0400 2009: I think the suggestion is that type constraints be completely divorced from Moose so that other possibly non-Moose/CMOP projects can use it w/ o requiring Moose/CMOP. Or is that missing the mark John? I think cut from Moose yet, but not from CMOP. I think we will need to think the relationship between CMOP and TC is complex. TC would be build on CMOP, but CMOP would want a TC system for full functionality (as if someday we decided to move some of the method signature checking to CMOP, which is where I think it would be most useful, but I could be wrong). I understand the suggestion, and it is a reasonable one. Why would such a type constraint implementation be mutually exclusive with MooseX::Types going into core? Wouldn't we just reimplement Moose::Types in terms of this new independent code? hdp. Yeah, totally. As per my last email I agree with the sentiment here, with the caveat regarding backcompatibility.
Re: MooseX::Types to core?
On Tue, Sep 8, 2009 at 1:32 PM, John Napiorkowskijjn1...@yahoo.com wrote: - Original Message From: Hans Dieter Pearcey h...@pobox.com To: moose moose@perl.org Sent: Tuesday, September 8, 2009 1:21:51 PM Subject: Re: MooseX::Types to core? Excerpts from Chris Fields's message of Tue Sep 08 13:14:20 -0400 2009: I think the suggestion is that type constraints be completely divorced from Moose so that other possibly non-Moose/CMOP projects can use it w/ o requiring Moose/CMOP. Or is that missing the mark John? I think cut from Moose yet, but not from CMOP. I think we will need to think the relationship between CMOP and TC is complex. TC would be build on CMOP, but CMOP would want a TC system for full functionality (as if someday we decided to move some of the method signature checking to CMOP, which is where I think it would be most useful, but I could be wrong). I understand the suggestion, and it is a reasonable one. Why would such a type constraint implementation be mutually exclusive with MooseX::Types going into core? Wouldn't we just reimplement Moose::Types in terms of this new independent code? hdp. Yeah, totally. As per my last email I agree with the sentiment here, with the caveat regarding backcompatibility. CMOP has always been (in my mind) a formalization of Perl5's implicit MOP. While it's not 100% accurate that is the general driving principle from what conversations we've had over the years. I like the idea of having TCs spun off into their own creature and Moose::Types built upon this creature ... but I hesitate to say things like Method signature checking should go into CMOP since there is no such facility in Perl5 itself and such a facility doesn't compile away clean like say Roles do. That said ... CMOP would should (eventually) have some facility for introspecting Lexical Types since those do exist in Perl5 (and as such we can push their implementation into something more useful). -Chris
