Re^3: constraining the keys of a HashRef in Moose

Thanks kennethk and tobyink - really helpful.

kennethk: I did think of making the hash into an object as per your first suggestion, but this would mean creating a large number of new packages (I think! The real situation is more complex than the simplified example). Using Hash::Utils is a very good idea though - this does what I need perfectly.

tobyink: nice - this is the kind of Moosey thing I had in mind in the first place. There seem a great many packages which *might* be relevant (to me starting out at least) so its very helpful to know which someone experienced would pick. Congratulations on your 2000th post!

Comment on Re^3: constraining the keys of a HashRef in Moose

Replies are listed 'Best First'.
Re^4: constraining the keys of a HashRef in Moose by kennethk (Abbot) on Aug 30, 2013 at 15:33 UTC
It could mean a large number of new packages, but that doesn't necessarily mean a large number of new files. If I have a type that is only going to appear once as the field value of another type, I will frequently put the object declaration, a.k.a. the package, in the same file. This avoids the type of file proliferation you are concerned about, while still leveraging the full power of the Moose type system. #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply]

Replies are listed 'Best First'.

Re^4: constraining the keys of a HashRef in Moose
by kennethk (Abbot) on Aug 30, 2013 at 15:33 UTC

Moose

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

[reply]