Re: [Yaml-core] Classes

[Brian I. <briani@ActiveState.com>]

Oren Ben-Kiki wrote:
> 
> Brian Ingerson wrote:
> > I can live without class names for Scalars and Arrays, but Hashes are a
> > must. Most perl objects map into Hashes.
> 
> Yes.
> 
> > Even Array and Scalar ones can
> > be serialized into Hashes.
> 
> Sounds interesting. How?

Hacked in at least:

    key : #class %
        __type__ : ARRAY
        0 : first elem
        1 : 2nd elem
        2 : 3rd elem

Or something like that.

> 
> > Hashes work for all Python objects and
> > Javascript too, AFAIK. I'll bet they could work for Java and C++ as
> > well.
> 
> In C++ (or Java) you'd want to de-serialize map/list/scalar as standard
> library hash/vector/string; this makes it difficult to provide an extra
> "class" property to list/scalar.

But you don't need a class name to deserialize into these three. They're
automatic. Just for other classes. Right?

> 
> Clark wrote:
> > Classes will be in.  I think we should allow these
> > permutations since the syntax seems to allow them.
> > We will need a disclaimer stating that not every
> > YAML system will be able to preserve the round-trip
> > information for some combinations, namely:
> >
> >   a) Having & and * on the same line.
> >   b) Using # with @ or with a scalar
> 
> I'd rather say - "NO strict YAML 1.0 system" instead of "Not every YAML
> system". These constructs simply aren't YAML 1.0, period. Otherwise, people
> will be very surprised when they write:
> 
>     point: %
>         x: #float 1.2
>         y: #float 3.4
> 
> And notice the YAML pretty printer strips away the '#float's.
> 
> Let's think a sec about *why* we want to add classes. It seems they are
> intended to allow a de-serialization into application-specific native data
> types (that is, something other then Hash/Vector/String).
> 
> I think that 99% of the time, the application specific data type is an
> object class (like "point", above). In which case it is represented in YAML
> as a map, with a key for each data member. It follows that the data type for
> each key is already determined by the map's class; e.g., class "point"
> expects float coordinate values. So there's no need to explicitly declare
> it.

I need to go to sleep 3 hours ago. I'm trying to follow this, and I
think I'm agreeing with the logic. But I'm puzzled as to why the above
code represents a point object. I don't see a class name of "point". Is
this a typo? Or am I just as spent as I feel?

Good night, Brian