Bug #91751 for Types-Core: Types:: namespace is for type libraries for M* OO, please move

On Mon Dec 30 21:43:26 2013, mst@shadowcat.co.uk wrote: Show quoted text
----- This was discussed some time ago on the module-authors list I'm not using the 'Type' namespace, nor the Types namespace. It was recommended (Brian Katzung, David Mertens) that I use Types::Core Mail dated 11/13/2013 (a whole bunch if you read the archives). Unless you want me to you 'Types', instead, I'm not willing to consider the headache of changing all the modules that use this module -- was bad enough to change from Types to Types::Core. This is about checking if a ref is a core Type... just because MOO uses types doesn't mean it's the only thing out there that uses Types. If it is M*OO-types, Shouldn't it be under the M*OO::Types namespace?

On Tue Dec 31 07:05:13 2013, mst@shadowcat.co.uk wrote: Show quoted text
---- Then where does Type::Tiny come in or were you referring to a Types::Tiny? Show quoted text
---- When I look at Type:: on my system, I see: Show quoted text
MooX::Types::MooseLike (3pm) - some Moosish types and a type builder MooX::Types::MooseLike::Base (3pm) - Moose like types for Moo MooseX::Types::Base (3pm) - Type library base class MooseX::Types::CheckedUtilExports (3pm) - Wrap Moose::Util::TypeConstraints t... MooseX::Types::Combine (3pm) - Combine type libraries for exporting MooseX::Types::Common (3pm) - A library of commonly used type constraints MooseX::Types::Common::Numeric (3pm) - Commonly used numeric types MooseX::Types::Common::String (3pm) - Commonly used string types MooseX::Types::DateTime (3pm) - DateTime related constraints and coercions fo... MooseX::Types::Email (3pm) - Email address validation type constraints for Mo... MooseX::Types::LoadableClass (3pm) - ClassName type constraint with coercion ... MooseX::Types::Moose (3pm) - Type exports that match the types shipped with M... MooseX::Types::Path::Class (3pm) - A Path::Class type library for Moose MooseX::Types::Path::Tiny (3pm) - Path::Tiny types and coercions for Moose MooseX::Types::Perl (3pm) - Moose types that check against Perl syntax MooseX::Types::Set::Object (3pm) - Set::Object type with coercions and stuff. MooseX::Types::Stringlike (3pm) - Moose type constraints for strings or strin... MooseX::Types::Structured (3pm) - MooseX::Types::Structured - Structured Type... MooseX::Types::Structured::MessageStack (3pm) - (unknown subject) MooseX::Types::Structured::OverflowHa... (3pm) - (unknown subject) MooseX::Types::TypeDecorator (3pm) - Wraps Moose::Meta::TypeConstraint object... MooseX::Types::URI (3pm) - URI related types and coercions for Moose MooseX::Types::Util (3pm) - Common utility functions for the distribution MooseX::Types::Wrapper (3pm) - Wrap exports from a library Reaction::Types::Core (3pm) - (unknown subject) Reaction::Types::DBIC (3pm) - (unknown subject) Reaction::Types::DateTime (3pm) - (unknown subject) Reaction::Types::Email (3pm) - (unknown subject) Reaction::Types::File (3pm) - (unknown subject) Types::Core (3pm) - Basic types defined as tests and literals (ease of use) Types::Serialiser (3pm) - simple data types for common serialisation formats Types::Serialiser::Error (3pm) - dummy module for Types::Serialiser ----------- I don't see a problem. I'm not in the same namespace as any of the M*OO modules. I see a problem with your terminology it is inconsistent with perl's documentation. I.e. perlvar doesn't say it has built-in PARAM Types, it uses the word type to refer to the types of data perl implements. I used Types::Core, to refer to the CORE Types referred to in perldata & perlref. The types you are talking about are M*OOx specific and really do NOT belong at the top level hierarchy as they are not Perl Data Types, but are M*oo data types. It seems they are already under the namespace M*OO::Types -- which is perfectly descriptive of what they are -- but you want to move them to 'Types' and reserve Types for only M*OO stuff -- that precludes anything referring to the standard perl Types or Types for any other system. That doesn't seem to be very 'fair'. It's not like I took up the entire 'Types' namespace, and my module does have to do with the Core Types -- not types of some specific library. I don't see how moving all the MooX specific types to the generic 'Types' namespace is helpful for CPAN or MooX. I've seen no discussion on the module-authors list about Types being or becoming reserved for MooX only Type -- but if I did, I would tend to think that's a bit 'classist' or 'elitist' to presume that the only Type modules that can exist are M*oox modules. I've suggested before enhancing the 'use' command to make it more flexible that would allow you to prepend a default prefix or a default prefix that would only apply to a specific list, but the idea of allowing any changes to 'use' to make it extensible or take expressions was shot down. It seems that would be a better way to solve what seems to be an issue of wanting to delete the typing of 'M*OO...::' before the M*oox-specific Type modules. Perhaps it would be more useful for Moose and perl to reconsider ideas like allowing 'use' in expressions as well as allowing expressions in 'use'?

On Tue Dec 31 20:34:23 2013, mst@shadowcat.co.uk wrote: Show quoted text
----- You are convincing me that it does not belong under Params, as that is not what I use it for. I just checked one program and found: Initialization: our %field_types = (Paths=>{type=>ARRAY,...}) Flow routing: return _path_stat_2_Ino_t($path,$arg) if $ref_arg eq ARRAY; return _path_stat_t_2_Ino_t($path, $arg) if $ref_arg eq 'stat_t' } else { _path_2_Ino_t($path) } }; Error/return value checking (not params): my $Inos = $mp->get_sorted_Ino_t_Array; return undef unless ARRAY $Inos and @$Inos >= 2; Param checking: sub popable (+) { my $ar=$_[0]; ARRAY $ar or die P "popable only works with arrays, got %s", ref $ar; Data verification (data from a data base): sub Type_check($;$) { return if $MP->{optimize}; my $v = shift; my $class = scalar @_ ? $_[0] : __PACKAGE__; die "Invalid type: undef passed" unless defined $v; my $ref = ref $v; die "Invalid type: value is not a reference" unless $ref; die P "Wrong type %s for type check in %s", $ref, $class unless $ref eq $class ; my $cfp = $class."::fields"; if (ARRAY $cfp) { for (@$cfp) { die P "Field %s does not exist", $_ unless exists $v->{$_}; my $cls_ftpp = $class."::field_types"; if (HASH $cls_ftpp) { if ($cls_ftpp->{type} eq 'ARRAY') { Debug "checking for Paths in ino_t"; die "Field %s is empty array", $_ unless scalar @{$v->{$_}}; } die P "Field type of %s, %s, should be %s", $_, ref $v->{$_}, $cls_ftpp->{$_}{type} unless ref $v->{$_} eq $cfp->{$_}{type}; } } } } Return Value Type-checking: sub Array_of_Scalars_check($$) {return if $MP->{optimize}; my ($valp, $name) = @_; die P "Got useless length when wanted ref for %s", $name unless ref $valp; $valp = $$valp if ref $valp eq 'REF'; die P "Needed array ref %s, got %s", $name, ref $valp unless ARRAY $valp; die P "Got useless ref to Array ref for %s", $name if ARRAY ARRAY $valp; } ---------------------- In 1 place out of 6 I use it for param checking. Putting it under Params would give people the impression that it is the purpose of the routines to do Param checking, when that is a minority of what it does. In all of the places it does it's work it is verifying data is of the right Type or is a shorthand for Perl's types themselves. Your insistence that it belongs under Params only underscores the reason that it doesn't belong under Params -- because too many people would think that was all it was about. Obviously I need to add more examples to the POD section. I'll work to address that deficiency. Thanks for pointing that out.

On Tue, Dec 31, 2013 at 11:56:19PM -0500, Linda A Walsh via RT wrote: Show quoted text
All of those things could also be done with Params::Classify - a very similar module that's under the correct namespace. Params:: is where modules with this sort of functionality live. Keeping to that convention is a good idea - if you're looking for searchability then put 'core types' in the NAME line. If you want to invent your own module hierarchy, the tradition is to put it under your PAUSE id. So you could rename this to LAWALSH::Types instead if you prefer. Otherwise, please follow the convention and use the Params:: namespace. It'll make other CPAN users more likely to find your module and less surprised by what it does. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team.