XML

[Franco Ponticelli]

I am considering a thx.xml library to fill the gaps left in the std library implementation. I would like to make it robust so I need unit tests and that is something I am really not looking forward to build. Is anyone aware of some tests that I can borrow/port? I am going to use the DOM4 definitions.

Franco

[Juraj Kirchheim]

How will it be different from Daniel's DOM4 library?

On Fri, Sep 25, 2015 at 6:52 PM, Franco Ponticelli <franco.p...@gmail.com> wrote:

I am considering a thx.xml library to fill the gaps left in the std library implementation. I would like to make it robust so I need unit tests and that is something I am really not looking forward to build. Is anyone aware of some tests that I can borrow/port? I am going to use the DOM4 definitions.

Franco

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Franco Ponticelli]

In a few ways.

• it will be built (hopefully) around tests and not the other way around
• I plan to use many of the existing features in thx.core to avoid rewriting everything from scratches
• license is going to be a more permissive MIT

Also I like to reinvent wheels :)

[Franco Ponticelli]

Another important difference is that interfaces are going to be real interfaces in haxe, that should give some more flexibility in implementing different things.

[Juraj Kirchheim]

I was asking more from a user perspective.

On Fri, Sep 25, 2015 at 9:14 PM, Franco Ponticelli <franco.p...@gmail.com> wrote:

In a few ways.

• it will be built (hopefully) around tests and not the other way around

What difference does it make for me as a user? TDD arguably creates pressure to properly factor your code, but given that DOM4 is a standard, the interfaces are already carved in stone and all you need to do is implement them.

• I plan to use many of the existing features in thx.core to avoid rewriting everything from scratches

This is interesting, as thx has a nice way of leveraging some of Haxe's features. However, with the interfaces already been specified, it seems like this is purely an implementation detail. Or not?

• license is going to be a more permissive MIT

That's cool, although I wonder whether a change of the license could not be arranged with Daniel.

 

Also I like to reinvent wheels :)

I fully sympathize! It just seems like a rather big endeavor and I see no immediate benefit. Take for example all the different future/promise/signal/stream libraries in Haxe: there is quite a lot of duplication, but it yields a wide selection of flavors and that's awesome (at least to a certain degree). But reimplementing *the same interface* just for the fun of it, does strike me as quite futile ... I probably just don't get it :D

On Sat, Sep 26, 2015 at 1:11 AM, Franco Ponticelli <franco.p...@gmail.com> wrote:

Another important difference is that interfaces are going to be real interfaces in haxe, that should give some more flexibility in implementing different things.

I'm not sure this is really so important, but probably you have a use case that I've just never come across. Even then, I wonder whether this can't be added to the existing DOM4 library.

The stuff you usually do is quite creative and useful, so I'm just puzzled by the fact that you would go through all the effort to implement this really huge API with no clear (at least to me) measurable benefit. In any case, I wish you good luck with the project ;)

Best,

Juraj

[Philippe Elsass]

Personally I'd like a JS-optimised XML library as a very thin wrapper over native browser parser: I found Haxe (non-fast) Std XML was 30% slower than native XML.
Surely it could have a Have-based implementation for other targets.

--

[Franco Ponticelli]

I started working on it and some of my "smart" motivations collapsed already. The interface thing really adds no value. I was unable to find proper tests and I will write them but the API and the specs are so intricate that a TDD approach seems difficult at best.

That said I think I will still keep doing it, I am not sure exactly motivated by what.

Franco

--