[m-rev.] for review: add xmlable typeclass to term_to_xml module

Julien Fischer juliensf at cs.mu.OZ.AU
Mon Jul 25 17:00:02 AEST 2005


On Mon, 25 Jul 2005, Ian MacLarty wrote:

> > > +% Method 1
> > > +% --------
> > > +% The first method requires a type to be an instance of the xmlable typeclass
> > > +% before values of the type can be written as XML.
> > > +% Members of the xmlable typeclass must implement a to_xml method which
> > > +% maps values of the type to XML elements.
> >
> > That seems redundant.  Members of a typeclass must implement the methods
> > by definition.
> >
>
> I don't see the problem.  Do you think it reads badly?  It is slightly
> redundant, but it gives new information: i.e. what the method names is
> and what the method does.
>
No, it doesn't read badly.  I just though it a little redundant, but
feel free to leave it there.

...

> > > +% In both methods the XML document can be annotated with a stylesheet
> > > +% reference.
> >
> > Presumably once we have typeclass reflection you could use both methods,
> > using the non-typeclass one as a fallback method.
> >
>
> I suppose.  Though I can't think of a situation where that would be useful
> outside of the debugger.
>
I was thinking of its use in the debugger actually ;-)

> > > +
> > > +	% Instances of this typeclass can be converted to XML.
> > > +	%
> > > +:- typeclass xmlable(T) where [
> > > +	func to_xml(T::in) = (xml::out(xml_doc)) is det
> > > +].
> >
> > Is there a reason the method delcaration just isn't:
> >
> > 	func to_xml(T) = xml
> >
>
> Yes.  An XML document must have one element at its root (its root can't be
> CDATA for example).  See the xml_doc inst below which you said seemed
> redundant.
>
Sorry, I overlooked the fact you were using it for subtyping.


> > I prefer either 'to_xml' or just 'xml' as names for the typeclass.
> >
>
> I don't mind to_xml, but xml is too vauge.  Are there any other opinions?
>
Actually, having had a hunt around for libraries with similiar
functionality this morning, I've come to the opinion that I could
live with xmlable.


> > > +	% We do not format sibling entities if there is anything besides
> > > +	% elements, Cdata or comments in the siblings, since then whitespaces
> > > +	% are more likely to be significant.
> >
> > I suggest:
> >
> > 	We do not format sibiling entities if they contain anything
> > 	besides ....
>
> That's not right.  The siblings themselves can contain anything, but the set of
> siblings must not contain anything besides elements, Cdata or comments.
> Reworded to:
> 	% We do not format an entity if any of its siblings is anything
> 	% besides an element, a CDATA entity or a comment, since then
> 	% whitespaces are more likely to be significant.
>
s/is/are/


> Thanks for that.
>
> Do you still have more comments?
>
No, although can you post a relative diff?

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list