> > DT::TZ::LINKS is still the only internal structure that is modified. > > Yes, but you access @DT::TZ::ALL as well.
I was necessary to verify that what an alias was pointing to was valid. Once the dependency was already there I implemented the rest. Everything thats there (and it is pretty small) is IMO what I would want as a user. I want to know if a value is a built in or user defined. I want to know what aliases are pre-defined for me. I want to know what the value of an alias is. And everything thats there is relatively safe. The only dangerous operation is to set an alias int he first place. None of this was pre-existing functionality and it's pretty consistent to have it all in the same place. > Yes, we should. I don't object to some sort of "is_olson_timezone" method > for DT::TZ. Well it really ALL should be part of TimeZoneCatalog but that name isn't any better then Alias. > Send me a patch, don't just implement a totally redundant method in > another module. That's silly. Alias was intended as a "user" interface. Whats in TZCatalog looks to me like it's intended for use in the internals. > > > All of the stuff about dying if an alias is defined and so on seems > > > like total overkill. The purpose of this module, AFAIC, is for > > > individual end-users to be able to define some useful _local_ aliases, > > > in an I'd like to add to my original comments that this is for the same reasons you want DT to be picky about inputs. > You mean localize it differently on different requests under mod_perl? It's so somebody else doesn't step on your alias. > Sure, we can give them enough rope, but I don't want to include code aimed > at dubious uses. This is the same reason I want DateTime constructors to > always validate input. Can you give me an example of a dangerous use? -J --
