Re: [Yaml-core] Implementing Substitutability

[Clark C . E. <cc...@cl...>]

Ok.  I still don't like option B beacuse it introduces 
two new types of nodes and special support classes 
required for each binding.   A isn't all that great
beacuse it requires "asScalar()" calls everwhere, 
just-in-case.

Let us add another option, C to the list.  This 
introduces a YamlNode which is similar to a DOM
node.  The user would then have the choice of 
binding, native (where substutibility doesn't hold)
or using our object model.

In option C, a YamlNode is introduced... this
has characteristics of a map, list, and scalar.
For this case, the =% and =@ are not needed.
At parse time, the user would request if they
want YamlNodes or native constructs.

...

In any case, I'm going to start plough ahead with
the C implementation... otherwise, I feel we won't
go anywhere.

P.S.  I was wondering why the "stab" production got
added and what it proports to solve.  

Best,

Clark

On Fri, Jun 15, 2001 at 12:35:36PM -0400, Clark C . Evans wrote:
| Ok.  Two approaches:
| 
|   A. asScalar()
| 
|      + External function, don't get complexity
|        unless ask for it.
|      + No changes to YAML needed.
|      + Technique works with non-yaml maps/scalars,
|        (ones that have not been saved yet).
|      + Explicit cast...
| 
|      - Requires foresight for code to have the
|        substutibility property.
|      - Extra asScalar() fucntion littered 
|        throught code.
|      - Requires a specific "key" value, =, to
|        be reserved.
| 
|   B. =% =@ approach
| 
|      + Does not require foresight, thus substituability
|        is gaurenteed.
|      + Does not require a specific key to be reserved.
|      
|      - Changes to YAML needed
|      - Special object needed to support construct
|