[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-xml
Subject:    Re: What would you like to see in XML::LibXML ?
From:       Shlomi Fish <shlomif () shlomifish ! org>
Date:       2012-01-31 9:04:35
Message-ID: 20120131110435.392b3f70 () lap ! shlomifish ! org
[Download RAW message or body]

Hi Aristotle,

On Tue, 31 Jan 2012 08:44:55 +0100
Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:

> Hi Shlomi,
> 
> * Shlomi Fish <shlomif@shlomifish.org> [2012-01-29 21:15]:
> > * Aaron Crane <arc@cpan.org> [2012-01-29 15:55]:
> > > I believe the tricky bit is ensuring that the annotations always
> > > have their reference counts updated at precisely the right time.
> >
> > Yes, it would be very tricky. One option to overcome this may be to
> > make these annotations be "tokens" which are arbitrary perl strings
> > or numbers, but not arbitrary perl scalars. The XML-LibXML programmer
> > will be able to map or unpack these tokens into something more
> > complex, but it would be their responsibility to allocate unique
> > tokens and to free their resources later.
> 
> that manages to just barely allow Aaron's use case at all, but it does
> not make it possible to do it solidly, much less do it with a semblance
> of convenience. It leaves what is essentially LibXML's responsibility
> as an exercise to the client code, which does not have exact knowledge
> of what is going on in the DOM data structure, and is thus left to try
> doing an approximate job of managing its own associated resources.
> 

You are right.

> Aaron may feel differently about this, but to be honest, if this is your
> final offer (so to say), then I would rather prefer that the feature not
> be added at all than tie up the _private slot and stunt the possibility
> of a more a elegant interface in the future.

"No problem in computer science is too hard that it cannot be solved by adding
another level of indirection". We can always store a dictionary whose only
key are these string annotations and leave the other keys for future use.

Thanks for directing my attention to this issue. 

> 
> If it is *impossible* to do correctly, then that is another matter. If
> it merely is very tricky, though, then it is the job of an API to hide
> this exact kind of complexity behind a veil of magic. LibXML does quite
> a good job of this for libxml2 in other areas.

I don't think it's impossible, just incredibly hard and possibly very
error-prone. And as they say, a bird in the hand is better than two in the bush.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Optimising Code for Speed - http://shlom.in/optimise

If his programming is anything like his philosophising, he would find ten
imaginary bugs in the "Hello World" program.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
_______________________________________________
Perl-XML mailing list
Perl-XML@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

[prev in list] [next in list] [prev in thread] [next in thread]