On Mon, 17 Apr 2006 15:43:37 +0100, TRANS <[EMAIL PROTECTED]> wrote: > On 4/17/06, Ross Bamford <[EMAIL PROTECTED]> wrote: >> On Mon, 17 Apr 2006 01:35:59 +0100, Sean Chittenden <[EMAIL PROTECTED]> >> wrote: >> >> >> On the other hand, I'm not necessarily adverse to having some kind >> >> of 'easy' API built on top of the core library, if there was enough >> >> to it, and it was sufficiently 'easy', but then again that's >> >> probably for another (dependent) project. But in this sense I don't >> >> consider methods like 'first' and 'empty?' as easy - I consider them >> >> essential parts of the core library. >> >> >> >> Anyway, that's just me. Sean might have a different view...(?) >> > >> > And I do! The C library could easily include, mixin, or inherit bits >> > from a plain text ruby library. As bottlenecks and performance issues >> > are identified (or as time permits), the ruby library could be >> > converted to C. The `require 'libxml'` line should include the .so, >> > but if the .so includes additional ruby files, who cares... this'll >> > provide an easy way for us to prototype new APIs before they get >> > integrated into the core. >> > >> >> Okay, I've set this up in CVS. Basically, the C library is now >> xml/libxml_so, and 'xml/libxml' is a Ruby file that requires libxml_so, >> then goes on to make the modifications Mark and I put together. I'd >> still >> like to get empty? implemented in C at least but as you say it's a good >> way to get it in quick. > > Hmm... adding functionality. I would tend to give that the new name > since it is over and above the libxml binding.
Well, my plan is that people shouldn't really need to require 'xml/libxml_so' directly, but rather the ruby file which just really acts as a front. As I said before I think much of it (especially stuff like the various each methods) will end up implemented in C but in the meantime this is a way to get them in and try things out. (I've :nodoc:'d all the new stuff for the time being). There are no cases where the new functionality replaces C-side methods, so unless you deliberately use the undocumented methods you shouldn't need to worry about any performance or upward-compatibility issues. >> What do you think to having an 'xml/libxml2' require as well, maybe >> lightly deprecating 'xml/libxml'? > > What's the point? Personaly I find such numberd names useless. Unless > the original libxml (not 2) is in common use, why bother? If you > really want create a file, libxml2.rb with content: > > require 'xml/libxml' > > But peronally I don't want to *have* to use require 'xml/libxml2'. > Yeah, that was what I was thinking of. I tend to be in agreement on this kind of thing but a few people have already mentioned that it's a potential source of confusion. In this context, by 'lightly deprecate' I really meant refer in the docs to the 'xml/libxml2' name, but still support 'xml/libxml' - there would be no warnings or anything like that. Cheers, -- Ross Bamford - [EMAIL PROTECTED] _______________________________________________ libxml-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/libxml-devel
