> carp i keep sengin these to individuals by mistake. why is tha mialing
> list setup this way?
> -----Forwarded Message-----
> okay time for my $.02 on this type stuff.
> simple solution: DON'T
> advantages: speed and simplicity
> disadvantages: none, b/c there is a better way to deal with types.
> let me explain.
> IMHO, core YAML should be type agnostic, defining structure and data
> only, indifferent to the actual types of the data. i see from the
> current specs, yaml already has some implicit typecasting that it
> performs dependent on the format of the scalar. get rid of it. simplify
> the design. having to determine when to us single quotes b/c yaml will
> implicity mis-interpret what i want is a pain, as it requires me to have
> a deep understanding of yaml's implicit interpretations. at the core
> level, all data should just be strings, pure and simple. no need for
> single quotes.
> further, the explicit type operator (!) should not define an actual
> type, but merely the name of a "type". --a namespace operator, not a
> typecast operator. using !int should have no more effect than using
> now i know, at this point a lot of you are saying "but...but". but bare
> with me.
> at this core level (pure yaml without types) types can be reasonably
> delt with in implementation. a program will use the data, typecasting it
> as is suitable to its needs. this is important, because DIFFERENT
> LANGUAGES DO NOT SHARE THE SAME TYPES.
> but this does not mean that yaml should not facilitate data types, in
> fact it still does, and is one of the great advantages it holds over
> XML. it does so with, the ! operator, which acts as information for the
> implementation to determine what typecasting should be used, but still
> on the terms of the implemenetaiton, not yaml's. implicit types within
> yaml are therefore useful to this extent, but no further. in other
> words, yaml might implicitly type something as !int, but like i said
> before, this should have no actual effect on the data itself. actual
> typecasting should only occur at the point of implementation. for
> example. yaml.rb, knowing the data types that Ruby supports, would cast
> anything explicity (or implicity) of type !int into a Fixnum, or if
> beyond the range of Fixnum, into a Bignum. you see, already yaml can not
> account for a distinction that Ruby makes, and thus should not even
> attempt too.
> taking this further, when i dump a Ruby object to yaml, the type comes
> out something like: !ruby/classname. that's a problem for
> interoperability. it should just be !classname. it should not matter
> that it came from Ruby. and by my approach as given above, it would not
> matter. it's just a name, for any other implementation to interprept as
> suites it.
> so that's my HO. i hope i've explained myself well enough, and that you
> see the reasoning behind what i am saying.
> okay so maybe it was $.03 :-)
Outstanding suggestions here. I am in 100% agreement with everything Tom says
Thanks to everybody for all the great discussion this weekend.