Tom Sawyer [mailto:transami@...] wrote:
> > The '- ' tells everyone that the order is significant; changing it
> > _will_ change semantics. If there's no '- ', anyone is allowed to
> > randomize the order at will, knowing for certain that it will _not_
> > change any semantics.
>
> and i haven't made myself clear :) you don't get an ordered
> list with this, you get a collection of collection.
You get whatever the loader produces. The PHP loader is free to convert this
directly into a PHP-thingie (what _is_ its name?).
> so here's the danger: Ruby dumps and array:
>
> Myarray:
> - one
> - two
>
> PHP loads it, but when PHP dumps you get:
>
> Myarray:
> - 0: one
> - 1: two
That _is_ a problem if you do dump it this way.
> b/c phps arrays are also maps, i.e. what is yaml.php going to
> do? it can't right decide a php array is a sequence or it is
> a mapping on its own.
You are right, there should be some sort of logic operating here, plus
optional external instrictions (the latter is normal; every language has
some types for which such instructions are necessary). I'm guessing that a
default that says:
- If all integer that are exactly 0 .. N, ordered as expected, then dump as
a sequence
Would go a long way to eliminate the need for such instructions. As for
mappings vs. ordered-mappings, I have the suspicion that a default saying
that key order is _not_ significant and requiring ordered maps to be
declared explicitly would work most of the time.
I expect Yaml->dump() in PHP would have some flags that control this
behavior.
> and even if the user intervens, what if
> he used his php array in both manners?
If he used his collection as an ordered map - e.g., he has "just one"
non-integer key and the key integer 7 appears as the first one, then
obviously this isn't a sequence. And forcing ruby to handle it as an ordered
mapping is exactly what you want, since otherwise it would lose significant
information.
> you can't rightly ask
> a php'er to deal with this. they simply won't and won't use yaml.
First, note that PHP-ers will never have a problem loading back data that
was dumped from PHP. Even if that's all YAML will do, I think it is enough
to gain a reasonable foothold. As Brian often points out, load/dump from the
same application is the most common use case by _far_.
Second, before we twist YAML out of shape, I think it is best to look at
some PHP code, consider what flags would be needed for Yaml->dump() in PHP
to control this behavior, and then decide whether the extra effort is
reasonable or not.
I've asked this many times and I'll ask again - how many PHP-thingies are
used as anything other than a simple array or a simple hash table?
> don't know about perls references, but int and float are
> distiguishable in yaml, i don't see your point with that example.
They are only distinguishable in the TYPED model. I was referring to the
core types trio - map/seq/str. Suppose I have an XyPoint class in Java that
expects Float coordinates. However I'm generating the input for it in Perl,
that doesn't care much about floats vs. ints, so it prints:
Point: { x : 1, y : 2.5 }.
My Java app barfs because X is an Integer instead of a Float. But a Perl
application would have no problem reading it. And there's no way to look at
a "1" and decide whether it is "1.0" or "1" without some knowledge of the
application... So you see the problem with omaps really isn't unique to them
or to PHP; it is a problem that is universal to writing cross-platform
applications.
A cross-platform application usually has a schema that is designed detached
from a particular language (you could say "by definition"). Hence when
dumping data that is expected to match such a schema, you _have_ the proper
instructions to give the loader (even if only in the form of a paper
document that needs transcribing).
It is the "semantics-aware" vs. "semantics-blind" issue again.
Cross-platform documents tend to get _loaded_ by semantics-aware code, not
by semantics-blind code (they may be _parsed_ by semantics-blind code,
certainly, but there's no problem at all there).
> > The core types we've chosen are "the least common denominator"...
> yes, indeed your approach is LCD, mine is GCM (greatest
> common multiples)...
OK, it is good to clarify this. I don't think YAML should try for a GCM. It
would end up being SGML.
> yes that's interesting and curious. ruby map keys can be any
> object and yaml supports this, but would bomb perl - LCD
> would toward only supporting string key and make ruby people
> deal with it.
Brian raised this point at the time, and we had drafts where keys were
limited to scalars. However, Parrot (Perl 6) will allow objects as keys, and
all the other languages already do, so we decided to include it in the LCD.
It was touch and go for a while even so :-)
> certainly there is no wrong or right here, just the
> determination of what yaml will be capable of and what it will not.
Right. It is a case of diminishing returns... And we don't want to end up
with another SGML.
Have fun,
Oren Ben-Kiki
|