[
Lists Home |
Date Index |
Thread Index
]
Arjun Ray wrote,
> | InnerXml _is_ printf ... but that doesn't mean we couldn't have
> | something analogous to printf which has its nice features (domain-
> | specific little language) without the risk of non-well-formedness.
>
> I suppose by "nice features" you mean variable substitution, which is
> the value of a template. I also assume that there's protection
> against the classic printf disaster of short arglists.
Err ... no, not especially. I mean that the template syntax can fit the
job, rather than having to be shoe-horned into the host languages
syntax (example later).
> I think the bigger fight is not with Java syntax, but with GP
> expectation. The default mindset first time in the door is probably
> one of "I gotta write strings, why can't I write strings?"
Hire smarter programmers?
> 1. &Deity; forbid that I should make a mistake in *xpath* syntax!
> (who catches that, how, and when? Looks like runtime to me.)
Sure, at runtime ... tho' presumably the _first_ runtime, so it's not
too dreadful.
> 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" } );
> 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.
> 4. Do concise arrays allow a mixture of heterogenous objects? How
> do substitute subtrees in?
Yup, and illustrated above.
> I'm really not convinced this is a win. Not to mention that XPath
> reeks too much of Obligatory HighTech. I have to write a xpath-expr
> parser too just to support this? Aiyaiyai!
Probably _you_ don't. An implementor of such an API could do it just the
once, and it'd be applicable across all vocabularies. OTOH you'd have
to write (or generate) a new library for every vocabulary. FWIW, I
don't think code generation is going to do a very good job without
manual intervention, cp. JAXB's mapping schemas.
> | Oh, and BTW: Hungarian notation is an abomination ;-)
>
> I agree (it wasn't quite Hungarian notation, except perhaps for the
> 'e' prefix on the locals). Hungarian notation is a decent idea taken
> to a ridiculous extreme.
>
> 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. There are a few nasty examples in the HTML DOM.
Cheers,
Miles
|
