On Fri, 14 Apr 2006 16:23:17 +0100, zdennis <[EMAIL PROTECTED]> wrote:
>> I'll admit at this point that I've not deeply studied the additions Mark
>> made in the ruby code, so I may well 180 on this 'not including ruby
>> code'
>> in the near future :->
>
> The ruby stuff I am thinking of are just helpers/wrappers onto of the
> ruby-libxml bindings. Some of the changes that Mark has in
> his xml_node_set.rb file are just things that make a nicer interface to
> ruby-libxml, but don't require it to be in C. For example:
>
> - --------
> class XML::Node::Set
> def empty?
> self.length <= 0
> end
>
> def first
> self.each { |n| return n }
> end
> end
>
> class XML::Node( *args )
> def first
> arr = self.find( args )
> return arr.first if arr and not arr.empty?
> nil
> end
> end
> - --------
>
> I know Daniel Berger is currently porting alot of his win32-utils to
> ruby because it is becoming to cumbersome to maintain and
> develolp it all in C. It seems same approach should apply with libxml.
> It is easier to add things in ruby to help make the
> interface of libxml more friendly and usable if performance isn't an
> issue, like in the above example.
>
> I am thinking outloud here, and thinking it would be easier for people
> to submit things to, since not everyone needs to dabble in C.
>
> Thoughts?
>
My main concern here is the prospect of introducing bottlenecks in the
library 'just for the sake of it' - I'm the first to agree (as the guy
writing the code at the moment ;) that this would be nicer and easier done
in Ruby, but particularly on this project performance is an important
issue (or we'd all just use REXML I guess). Granted the additions are
optional, but of course they will end up being used across the board and
I'm loathe to see a situation where we have API docs saying (contrived
example):
set.empty?: Check if empty. If performance is an issue,
don't use this in loops - use <something else>
instead.
I think if we work to keep the whole core library as fast as possible
(including all the things we expect to have as rubyists, like the above)
then there won't be any unexpected gotchas that could bite in code that
would otherwise be nice and quick.
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...(?)
--
Ross Bamford - [EMAIL PROTECTED]
_______________________________________________
libxml-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/libxml-devel
