From: Tom S. <tra...@tr...> - 2002-09-07 06:56:07
|
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 !my.com/mytype. 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 :-) -- tom sawyer, aka transami tra...@tr... -- tom sawyer, aka transami tra...@tr... |
From: why t. l. s. <yam...@wh...> - 2002-09-07 17:58:15
|
Tom Sawyer (tra...@tr...) wrote: > 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. My problem with this argument is that if we really believe it, then YAML crumbles. See, the Integer and the String and the Float generally typecast well between languages. It's the sequence and mapping that give us more trouble! For example, PHP doesn't have a seperate Array and Hash. It's all the associative array. So round-tripping an array properly would involve scanning all the keys of the array for 0-(n-1) keys. And then there is the possibility of just one of those keys missing. At that point is it still a sequence? Perhaps it is a sequence with a Nil entry. Perhaps it's a mapping at that point. We can't very well have the emitter making up new entries to compensate. Brian has said it before: We're trying to make YAML a config file syntax, a serialization format, an intermediary format for everything and anything. But what is it really? If we have typing, then it sure starts to sound a lot more like a serialization language. It certainly doesn't sound like a config file! I have some objections to the config file view of YAML, which appears to want to present YAML as Not-YAML. As a no-nonsense, stripped bare (no headers, no typing) syntax leading a hidden life somewhere else as a full-fledged graph. I mean what's the big deal with configuration files? How hard is it to write a config file parser and how many people are going to look at YAML and say, "Screw this! I can write five regexps to do my config file!" I can see YAML's case for config (I'm thinking of Neil's recent spam project) but somebody needs to stand up for YAML's individuality. If somebody is going to use YAML for config, then their users will likely have to know some YAML. I wouldn't seek to disguise it. I'd rather hear this: "Wow, YAML is cool because you have a language-neutral technique for storing and loading data. It's like config files on crack!" Than this: "Oh, YAML's this config file format that's TRYING to be a data serialization format, too." I guess I don't see the big deal about implicit types because I see YAML as data serialization. And when it comes to a discussion about surrounding data with '(' ')' so that you don't have to surround your strings with '"' '"' then it seems to me that YAML is a config file at heart. > 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. I think we'll make this transistion once we see how the implementations work together and once we have implicit typing down. Certainly I'd like to see classes transfer smoothly between languages. For now, we use the language identifier as a sandbox for proofs of concept. _why |
From: Clark C. E. <cc...@cl...> - 2002-09-07 18:50:59
|
On Sat, Sep 07, 2002 at 12:07:32PM -0600, why the lucky stiff wrote: | For example, PHP doesn't have a seperate Array and Hash. It's all the | associative array. So round-tripping an array properly would involve | scanning all the keys of the array for 0-(n-1) keys. And then there is | the possibility of just one of those keys missing. At that point is it | still a sequence? Perhaps it is a sequence with a Nil entry. Perhaps | it's a mapping at that point. We can't very well have the emitter making | up new entries to compensate. I have a question about PHP. It says that it is an "ordered map" but all of the examples I've seen show an associative container. In other words, is array( 'a' => 'b', 'c' => 'd') distinguishable from array( 'c' => 'd', 'a' => 'b'). If not, it is an associative container and not a "ordered map" as it says. If it is an ordered map, what is the syntax to get the nth key? Quite clearly this isn't a perfect fit to the YAML generic model, also since the generic model will allow containers as keys. Anyway, this is another thread, but I'm interested more in PHP limits. Best, Clark |
From: <ir...@ms...> - 2002-09-07 20:09:58
|
On Sat, Sep 07, 2002 at 06:52:37PM +0000, Clark C. Evans wrote: > I have a question about PHP. It says that it is an "ordered map" but > all of the examples I've seen show an associative container. In other > words, is array( 'a' => 'b', 'c' => 'd') distinguishable from > array( 'c' => 'd', 'a' => 'b'). If not, it is an associative container > and not a "ordered map" as it says. If it is an ordered map, what > is the syntax to get the nth key? I haven't looked at this specifically in a while, but from memory it's ordered because they keys stay in the order you define them. If you print_r the array or use the iteration functions, the keys come out in their original order. There are several functions to sort the array in various ways, and then the new order persists. In contrast, Python dictionaries do not preserve the order at all. If you print a dictionary or do dic.keys(), they come out in a random order. Sometimes this is frustrating because it means you have to keep a separate list around to show which order you want the elements processed in. Of course, there's no concept of sorting a dictionary in Python. You'd have to get the keys as a list and sort that. I assume your two arrays would compare equal. As for getting the nth value, $arr[5] gets the item with numeric subscript 5. If you mean the absolute fifth element, you could run the next() iterator function five times or... I don't know. What does foreach do? A C-like for loop would get only the numeric subscripts. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Clark C. E. <cc...@cl...> - 2002-09-07 20:33:05
|
On Sat, Sep 07, 2002 at 01:09:55PM -0700, Mike Orr wrote: | In contrast, Python dictionaries do not preserve the order at all. If | you print a dictionary or do dic.keys(), they come out in a random | order. Right. And I believe that Perl's Hashtable is the same. I see this has the LCD behavior (which happens to align nicely with 'function') thus key order shouldn't be part of the generic model -- as we'd like most generic YAML tools to operate on native Perl and Python constructs directly without requiring a wrapper. | Sometimes this is frustrating because it means you have to keep | a separate list around to show which order you want the elements | processed in. Right. But this is a "formatting" issue, and I'm sure we will have functions in the YAML toolset which work on the "syntax" model where key ordering, node style, and other formatting information is available. This model will obviously require a DOM or third-party object to store the YAML-specific attributes. Of course, "C" language doesn't have a generic "container" so that binding will have to use a YAML specific structure. But "C" isn't a scripting language (which is our target audience) Best, Clark |
From: why t. l. s. <yam...@wh...> - 2002-09-07 20:34:36
|
Mike Orr (ir...@ms...) wrote: > In contrast, Python dictionaries do not preserve the order at all. If > you print a dictionary or do dic.keys(), they come out in a random > order. Sometimes this is frustrating because it means you have to keep > a separate list around to show which order you want the elements > processed in. Of course, there's no concept of sorting a dictionary > in Python. You'd have to get the keys as a list and sort that. Ruby is the same. There's a new !ruby/pairs type in the latest YAML.rb that solves this by leveraging the seq-map shortcut in YAML. Here's the example from the YAML Cookbook: test: The !ruby/pairs type brief: > The sequence-mapping shortcut in YAML allows you to place the first line of the mapping on the same line as the dash for the entry containing the mapping. The !ruby/pairs type takes advantage of this shortcut to create (instead of a sequence including maps) a single object of pairs which can be accessed like an ordered hash. Entries in which the last value in the pair is null can simply show the first value in the pair. yaml: | --- !ruby/pairs - Minh Thai: 22.95 - Guus Razous-Schultz: 24.32 - Zoltan Labas Hungary: 24.49 - Lars Petrus - Ken`ichi Ueno Japan ruby: | winners = YAML::Pairs.new winners[ 'Minh Thai' ] = 22.95 winners[ 'Guus Razous-Schultz' ] = 24.32 winners[ 'Zoltan Labas Hungary' ] = 24.49 winners[ 'Lars Petrus' ] = nil winners[ 'Ken`ichi Ueno Japan' ] = nil winners _why |
From: why t. l. s. <yam...@wh...> - 2002-09-07 20:30:36
|
Clark C. Evans (cc...@cl...) wrote: > > I have a question about PHP. It says that it is an "ordered map" but > all of the examples I've seen show an associative container. In other > words, is array( 'a' => 'b', 'c' => 'd') distinguishable from > array( 'c' => 'd', 'a' => 'b'). If not, it is an associative container > and not a "ordered map" as it says. If it is an ordered map, what > is the syntax to get the nth key? // Two identical lists. $a1 = array( 'a', 'b', 'c', 'd' ); $a2 = array( 0 => 'a', 1 => 'b', 2 => 'c', 3 => 'd' ); // An associative array $a3 = array( 'a' => 'b', 'c' => 'd' ); foreach ( $a3 as $k => $v ) { echo "$k -> $v\n"; } // => a -> b // c -> d // Finding the nth element $n = 1; $a3keys = array_keys( $a3 ); echo $a3keys[ $n ] . " -> " . $a3[ $a3keys[ $n ] ]; // => c -> d There are probably other ways to find the nth key. I don't have my PHP manual handy and there are a million array functions. I don't think this is too much of a barrier, though. I'm sure some code could be salvaged from the WDDX or XML-RPC serializers. I know some XML-RPC encoders won't output arrays though, only structs. Interoperability is definitely a problem, though, in cases where array entries are null or in which one or all of the indices in a flat list are accidentally turned into strings in PHP. > Quite clearly this isn't a perfect fit to the YAML generic model, > also since the generic model will allow containers as keys. Anyway, > this is another thread, but I'm interested more in PHP limits. Keys in PHP are definitely limited. I don't know of a way to add complex keys to an array. And floats have a problem as well: why@stungun:~$ cat test.php <? $a = array(); $a[10.01] = array(2, 3); $a[10] = 20.01; print_r( $a ); ?> why@stungun:~$ php -q test.php Array ( [10] => 20.01 ) If PHP had something like TIE, then shadowing could be done as Brian has suggested, which would help mimick "the real thing." But as it stands, you have to look at PHP use cases and PHP user goals. I think it's okay for YAML.php to say "Sorry, you can't load complex keys in PHP." Hacking it in would likely be a bigger fuss than is worth. _why |
From: Steve H. <sh...@zi...> - 2002-09-08 16:32:25
|
> 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 > !my.com/mytype. > > 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 here. Thanks to everybody for all the great discussion this weekend. Cheers, Steve |