Hi,

finally I'm able to go on with the YAML component.

Derick, thanks for your feedback. One point needs some clarification:

Am Donnerstag, 30. April 2009 12:00:54 schrieb Derick Rethans:
> @TODO: we are not sure about the ``eczYamlString*`` classes.
>
> - I think it's important to have, as they provide the exact same
>   interface as the stream reader classes. Or if not, they really should
>   be the same. It would make it easy to switch from string to file by
>   just instantiating a different class.

That's not possible as the signatures differ:

- string eczYamlStringGenerator::generate( $yamlDocument ) vs.
  void ezcYamlStreamWriter::writeDocument( $yamlDocument )

- arrayOfEzcYamlDocuments ezcYamlStringParser::parse( $serializedData ) vs.
  ezcYamlDocument ezcYamlStreamReader::readDocument()

At the moment I do not see how this could work. We could change the
parsing/reading thing to be more similar. But I do not see (nice) a solution
for the generation of serialized data because of the return value. (Of course
you could provide a reference variable where the string is filled in if
given.)

The question is if this is really what we want/need. I try to explain the
situation from another perspective:

- We have the ezcYamlAbstractBackend that unifies the API of the backends and
  supports generation (one method) and parsing (two methods: line by line or
  a full YAML document in one step)

- We have this mapping:

              \     backend | parseLine +  | parseStream | generateStream
               \            | getFinished- |             |
  high level    \           | Document     |             |
  --------------------------+--------------+-------------+----------------
  eczYamlStringGenerator    |              |             |       +
  ezcYamlStringParser       |              |      +      |
  --------------------------+--------------+-------------+----------------
  ezcYamlStreamWriter       |              |             |       +
  ezcYamlStreamReader       |      +       |             |

- syck::load and syck::dump are analog to parseStream and generateStream;
  parseLine does some magic and finally uses syck::load

- our implementaion: parseLine and generateStream use the relevant method of
  our parser/generator; parseStream feeds parseLine line by line with the
  provided document

- ezcYamlStreamReader|Writer are conveniant wrappers around the classical
  load and dump doing some stream handling. ezcYamlStringParser|Generator do
  nothing similar - they just pass the methods to the backend API.

  The only difference: the backends provide three ways to work with YAML
  (line-by-line parsing, complete string parsing, generation) whereas the
  four high-level classes just provide one method so you can't confuse (our)
  parser implementation when messing around with line-by-line and string
  parsing mode.

Thus the question was: do we want to prevent misusing the backends by
providing the ezcYamlString* classes? Or is this just an issue of good
documentation how to use the backend directly in a correct way? This could
also achieved by declaring the methods of the abstract backend for
line-by-line parsing mode as "for internal use only".

In fact, we can decide this original question later, as those two
ezcYamlString* classes are very simple.

Why did I wrote this email then? I just wanted to make clear: it's not that
easy to exchange Stream and String as the first reads/writes to streams
whereas the latter gets a string parameter resp. returns a string.

Is this ok then? Or do you still want to change the API?

Have a nice day

Thomas
-- 
Thomas Nunninger
Steinhalde 108
79117 Freiburg

Tel.:  0761 1201850
Mobil: 0163 7115153
http://nunninger.info

USt-IdNr: DE259832548
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Reply via email to