Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: InnerXml is like printf (WAS: Underwhelmed)
Miles Sabin <miles@m...> wrote:
| Arjun Ray wrote,
| I mean that the template syntax can fit the job, rather than having to
| be shoe-horned into the host languages syntax (example later).
Ah, okay, this goes back to your comment about "little languages".
|> "I gotta write strings, why can't I write strings?"
|
| Hire smarter programmers?
From where?:-( Most specimens walking in the door are printf jocks.
|> 2. How do I splice other stuff? Or do I have to put the entire
|> tree into a single expression?
|
| How about,
|
| Element link =
| new Element(
| "link[@rel='stylesheet',@type='text/css',@href=%0]",
| { "/ss/style.css" } );
|
| Element e =
| new Element(
| "html/("+
| "head/(title/text(%0),%1),"+
| "body/text(%2))",
| { "Example 3", link, "Hello World" } );
Okay, I'm liking this much more, now. Homogenous arrays would have been a
real downer. This has value for constructing "canned" fragments.
|> 3. What about adding more than one child to an element?
|
| Already in that example (head and body, title and link). Like I said,
| this is a mish-mash of XPath and s-exprs.
Sorry about this one, I missed the commas.
| OTOH you'd have to write (or generate) a new library for every vocabulary.
Yes, that's the price of "lifting" taxonomic names out of grubby GP hands.
Well, that's uncharitable. It's also to relieve the GP of the burden of
getting those names right at compile time, which he can't with strings.
One doesn't write libraries unless one believes that it will make the GP's
job easier. But a lot of that is imagination and judgement. There is no
One True Way.
And there are relatively obvious things to avoid. What I really dislike is
something like an early example in this thread:
String s = "InnerXml";
int i = 2;
Element usability = new Element("usability");
usability.add(new Attribute("factor", Integer.toString(i)));
usability.appendChild(s);
Having to do stuff like Integer.toString(i) - an essential silliness of
APIs that talk strings, only strings, and nothing but strings - is out and
out abuse of the GP. At least make his job easier by eliminating the
*language* gruntwork! Any library that wants the GP to do things as
easily assimilable into the API as Integer.toString() must have been
written by a purist or an idiot for a masochist.
There's a piece somewhere that I can't recall offhand about designing
packages for Perl, where there's a point about not forcing the Perl
programmer to "think" in some other language, but rather to make things
available in ways intuitive to the Perl programmer (which also involves
judgement as to the correct level of abstraction.) Paul Graham makes a
similar point in his books on Lisp, where often the best approach to
program design is to start with a thought experiment - what do you think
what the programmer will be doing will look like? or, how should the "how
to do it" look? - and build the infrastructure to realize that vision.
I personally believe it is a fundamental mistake to require that taxonomic
names be dealt with as strings. I could easily be wrong, but I've seen
too many horrors that can be traced back to precisely that circumstance
not to want compelling reasons to change my mind.
| FWIW, I don't think code generation is going to do a very good job without
| manual intervention, cp. JAXB's mapping schemas.
Well, JAXB is mostly about interfaces, from what I can see - the work of
implementing those suckers is left as an um, exercise. I've been using
DTDs to generate classes. The only interfaces are for a common generic
package, which the programmer has access to if he *really* wants. This
xpath stuff could fit into that package, I'm thinking...
And I cheat: I use SGML DTDs to get some extras in, like the DATA declared
value. This is to get around some obvious intervention points, such as
URI values for some attributes.
|> The 'a' prefix on element construction methods and 'w' (for "with")
|> on attribute methods were necessary in order to prevent clashes with
|> Java reserved words.
|
| This is the example of fighting the host languages syntax I alluded to
| earlier.
Indeed, true.
But I still think string-based approaches ultimately [expletive deleted] ;-)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
