Bug #97516 for Type-Tiny: InstanceOf[Class::Name] is not cached, makes declaring coercion inconsistent

Moose/Mouse will certainly always return the same object reference, but that's a consequence of them having global type libraries. If you have a named type constraint, that means the same everywhere. This leads to action at a distance. A coercion to URI defined by the routing part of your application can have unintended consequences on the web-scraping part. While Type::Tiny type constraints play nicely with Moose and Mouse, I did aim to change some aspects of the system I thought were flawed. Type::Tiny's type constraints are essentially lexical. And then Type::Library basically gives you a way to give them (namespaced) global names. So the solution, such as it is, is to create a type library, and declare a new type in it: declare MyURI, as InstanceOf["URI"]; And then attach the coercion to "MyURI". Once you've created a child type, the child "belongs to you", and you can coerce to it freely. Certainly it would be nicer if the example you provided at least emitted a warning though. I'll keep this ticket open while I think about things.

Regardless of the lexical vs global type philosophy, the current situation where SOME of Types::Standard's types act globally and some do not, is the worst case. It's unclear and undocumented to the user which types will persist and which will just toss changes out. The changes made to things like InstanceOf["URI"] don't even persist lexically, they immediately disappear because of the hidden lexical nature of the type. UNLESS that type happens to have been coincidentally cached by something else. For example... subtype "AbsDir", as InstanceOf["Path::Tiny"], where { $_->is_absolute }; coerce "AbsDir", from InstanceOf["Path::Tiny"], via { return $_->absolute; }; coerce InstanceOf["Path::Tiny"], from "Str", via { return path($_); }; Now that final coercion will persist but only because AbsDir happens to contain an instance of InstanceOf["Path::Tiny"] which it keeps in existence. Something has to be done about that. (Note: that something is NOT to document the broken behavior). Now I get a bit long winded as I have Opinions about type coercion. The MyURI work around, as a long term solution, is problematic from my point of view about type coercion. Unlike the Moose POV about type coercion, that it should be under the control of the consumer of the type, I prefer the ease of transparent type coercion. If my method wants InstanceOf[URI] all I care is my method receives InstanceOf[URI]; I don't care what the original input was so long as I have a faithful representation of it as a URI instance. Similarly, when I add a coercion to a type I expect it to just work with all the things that take that type. I do not want to have to declare a new type and then hunt down all the places which used InstanceOf[URI] and change it to MyURI. It's funny, each POV views the other as causing an encapsulation violation. I guess it depends on whether you look at type coercion as altering the input (I gave you a string and suddenly it's a URI object) or as guaranteeing the input (I said I want a URI object, I don't care what it was before). Or as proscriptive (my method takes only URI objects, it's wrong to give it a string) vs descriptive (my method takes URI objects, or anything which can be reasonably coerced into one). Anyhow, the work around I'm using for Gitpan is: our $URI_Type = InstanceOf["URI"]; To the action at a distance issue... global types are global and inherently have action at a distance issues. This is like saying the method modifiers after, before and around have action at a distance issues. They do. It's part of their nature. It's accepted. Adding coercion is a far less severe action at a distance issue. Moose style conversion has to be turned on by the type user. If I add coercion to InstanceOf[URI] it only effects the places which have already decided they want coercion. The nature of that coercion may change, but that's what you accept by using global types and coercion. The action at a distance issue already exists with the standard types cached by Types::Standard. I can add a coercion to Str and it will appear elsewhere. Action at a distance is only a problem when a global entity is changed in two different places. If one library declares and modifies a global type, and at the same time, it's not really action at a distance. For example, the Gitpan project has Gitpan::Types to collect all its custom types and custom type modifications together in one place. https://github.com/evalEmpire/gitpan/blob/rewrite/lib/Gitpan/Types.pm It was in converting this to Moo/Type::Tiny that I encountered the problem. This only works for Gitpan because it is an application. If a CPAN module starts messing with standard types, that's the bad sort of action at a distance... unless it's a CPAN module about types. As to Type::Tiny's intent to make types lexical, that's fine. If you want lexical protections for your types, you can make lexical types. If you want global types, you can make global types. Type::Tiny presents a lexical type system with types declared lexically. Types::Standard presents a global type system with types declared in a separate file and exported. Changes to lexical types should be lexical. And changes to global types should be global. If you start adding coercions to global types declared elsewhere, you incur the same problems as messing with any global. This is a known problem with global entities and one which is accepted. All that said, mutable global entities are a problem because they can be changed anywhere and cause action at a distance. IMMUTABLE global entities are less of a problem. Perhaps types can be locked to prevent further changes, and unlocked as an "I thought about this and know what I'm doing" check? Another possibility is to have Types::Standard export *copies* of their types so they can be safely messed with without danger of causing action at a distance. Then if one wants to modify standard types for their own project they have to write their own local type library like Gitpan::Types. Another possibility is to accept that Types::Standard produces global types, to make all standard types persist, and document that standard programming practices about modifying globals apply.

Show quoted text
Oh, OK. But I'm marking it as unstable.