[Yaml-core] How recursive anchoring works in Syck

[why t. l. s. <yam...@wh...>]

On Thursday 07 August 2003 10:38 am, you wrote:
>
> Let's take this example again:
>
> --- #YAML:1.0
> test: &1
>   loop: *1
>
> bad_anchor_handler needs to create some SyckNode,
> so I created a syck_new_str.
> Then, it seems that my syck_handler is called twice
> for the map with loop as its key, once with the
> id of the thing that was create in bad_anchor_handler
> (which is 0 in my case) and once with id 0.

Nodes with the most depth are created first.  So when the *1 is parsed, t=
he=20
anchor hasn't been assigned to yet.  bad_anchor_handler is called.  Then,=
 the=20
node_handler is called with the return of bad_anchor_handler.  (Reason be=
ing=20
that I believe assignment of the SYMID should be centralized in the=20
node_handler).

In Ruby, an instance of the YAML::Syck::BadAnchor class would be placed a=
s *1.=20
We'll say this instance is represented in Syck by a SYMID of 15.

>
> The second one is the "real" one, which seems strange
> because at the time that handler is called with the
> bad anchor id, the real object hasn't been created
> yet and so I can't see how the dangling references could
> be patched up.
>

So when the real anchor '1' is created, Syck passes the SYMID of 15 in as=
 that=20
SyckNode's ID.   This is the only case in which a SyckNode will be given =
an=20
ID before being passed into the handler.

We can then find the original BadAnchor in our symbol table and overwrite=
 it=20
with the Hash node.  In Ruby, we actually swap the entries of the BadAnch=
or=20
and the Hash in the symbol table.  That way the BadAnchor can be garbage=20
collected by Ruby rather than doing it manually.

> Can you enlighten me on how this should be used and
> how to differentiate between a real object creation
> and on corresponding to a bad anchor ?

Check the SyckNode's id when it comes into your handler.  If it's set alr=
eady,=20
then you're dealing with a bad anchor that is being reconciled.  If it's =
not=20
set, then it's a normal node.

I think part of what is confusing the matter is that you are passing zero=
=20
around.  Try to develop a permanent solution for bad anchors right away s=
o it=20
will be obvious to users what is happening.

See the Ruby extension for more examples of all this.  Good luck!

_why