On Nov 13, 2007 8:52 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > On Nov 13, 2007 8:07 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > On Nov 13, 2007 3:46 AM, Claude Brisson <[EMAIL PROTECTED]> wrote: > > > Le lundi 12 novembre 2007 à 16:18 -0800, Nathan Bubna a écrit : > <snip/> > > > > > > My feeling here is that although foo.int is a cool syntax, it has too > > > > > many backwards ; especially, we should always return the integral type > > > > > (string, boolean or number) when available rather than a wrapper > > > > > around > > > > > it to avoid nasty side effects. > > > > > > > > c'mon, ValueParser is no less a wrapper than ValueParserSub would be. > > > > even a returning a simple HashMap would be returning a wrapper. as > > > > long as we make the subkey business configurable (with it off when in > > > > deprecation support mode), and only return the > > > > ValueParser/ValueParserSub/HashMap for $params.foo when there are keys > > > > that start with "foo.", then i think we'll be fine. > > > > > > You don't get my point. > > > > i would say the same... :) > > > > > By construction, an application should usually > > > know when expecting a map or an integral type. Let's consider those > > > points separately: > > > > > > - maps: both implementations do wrap them. I guess both are valid but I > > > prefer the new one because I don't see why we should use two different > > > wrappers (ValueParser itself is already a wrapper around a map). Having > > > the wrapper extend Map respects the principle of least surprise for > > > template coders. > > > > that helps only for Maps, which i suspect will not often be found > > inside the source map. > > > > > - integral types: wrapping them is not a problem as long as they're > > > used directly for display (and it allows the foo.int syntax), but > > > whenever those values will be used as arguments to other tools or > > > objects methods you will encounter side effects (and don't even think of > > > trying to detect the appropriate conversion by reflection, it only works > > > for very simple cases). $list.add($params.foo) would add the > > > ValueParserSub to the list, not the integral type... and there are > > > plenty of examples like this one. In fact, specifying the type > > > (.int, .string, ...) becomes mandatory to get rid of the wrapper. Which > > > is rather cumbersome. > > > > and what gets added to the $list in your current implementation when > > subkeys are allowed and there is also a "foo.bar" available in the > > source map? $list.add() receives a ValueParser instead of the > > integral type, right? so once again, it becomes necessary to get rid > > of the wrapper. but how? the new ValueParser returned by $params.foo > > provides no means to unwrap itself, cumbersome or otherwise. if you > > really just want the "foo" parameter and not a "foo.bar" one, then it > > seems you are out of luck. > > i just re-examined the current code. i wasn't wrong. in your current > implementation, $params.foo *will* return the integral type for "foo" > if there is one. However, the presence of "foo" means that > $params.foo.bar syntax will fail. This unsettles me somewhat as it > seems rather fragile and unpredictable. Granted, to do things as i > had anticipated (have $params.foo return a wrapper anytime a "foo.bar" > type parameter is available), makes the type returned by $params.foo > unpredictable, but this seems less troublesome than making it > unpredictable whether anything at all will be returned. > > i've got to get some other work done now, but i'll be thinking about > this more...
ok, after much thought, i think i prefer the better backwards compatibility of always having $params.foo return its string value to returning a ValueParser or ValueParserSub when subkeys for "foo" are available and a string when there are no "foo" subkeys. the better backwards compatibility is slightly more important to me than having the subkey syntax work consistently. we will, however, need to be sure and document clearly that the subkey syntax is unreliable in such situations. of course, i could be swayed the other way on this in the future if this starts to pose problems, but for now, i'm onboard with the current implementation. thanks for bearing with my obstinance and inattention... :) > > > Re-introducing the foo.int syntax would be cool, of course, but why not > > > try to do it in the engine itself (so it is generalized to every value)? > > > It'd be cool to be able to do "$foo.int" on every value (once one have > > > checked that "int" is not a valid key for "foo"). > > > > that is a very interesting idea. it won't solve the problem i > > describe above, but it could be cool. > > > > > > > > > > Claude > > > > > > > <snip/> > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
