Incidentally, I've seen Nicola's response, so I'll try not to duplicate too
much of what's already been said.
On Thursday 10 January 2002 07:28 am, Stefano Mazzocchi wrote:
> Hmmm, try to read it from the perspective of somebody who cames from
> XSLT or comes from other programming languages. Which one has a easier
> learning curve yours, or the one we already have?
>
> Sure, matchers and selectors *DO* partially overlap.
>
> But don't
>
> for{};
> while{};
> do {} while ();
>
> partially overlap?
>
> As stated somewhere else, syntax sugar is not always bad.
Nicola already made the point that, for and while are freely convertible, and
I agree that syntactic sugar can be a nice thing, as it helps to document and
simplifies the thinking involved (e.g. even though every while{} is
equivalent to a for{} and vice versa, once may be clearer than the
other...which is why you'll get a warning for a bodiless for(;;);) and that
<match/> and <select><when/></select> aren't perfectly equivalent.
The differences have been raised several times. And perhaps the differences
are pretty fundamental, but I haven't been suggesting that <match/> be
removed, or even that <when/> be deprecated. The point I want to make from
Nicola's observations is that <select> and <match> could be made
interchangable, and I'm not sure I can see why not to. Surely it would be
nice to have an <otherwise/> clause with a set of matchers.
The clearest dilemma I can see is that <select><match test=A><match
test=B></select> implies that if A matches, and B matches, two clauses occur,
but <select><when test=A><when test=B></select> implies that if A matches, B
won't be tested. Is this FS or useful power? Especially in terms of:
<select>
<match test="**X">
<!-- clause A>
</match>
<when test = "Y**">
<!-- clause B>
</when>
<match test ="**Z**">
<!-- clause C>
</match>
</select>
ZX would do A,C
YZ would do B only
YZX would to A,B only
But there might be the slight obfuscation of match/when means
fallthough/break, and does <otherwise/> occur if no clause is executed, or if
no <when/> clause is executed (does it mean "otherwise, if nothing else
happens" or "otherwise, if execution isn't interupted before the end of the
<select/>"?)
> And as far as implementation, it's pretty easy to write a Select and a
> Matcher using the same logic behind it.
Much discussion has been dedicated to demonstrating that Selects and Match -
groups can't serve the same sets of logic; they intersect, but are not
equivalent. Especially because <otherwise/> != <match test="**">.
> But there is more: semantic overlap triggers some deeper thinking about
> 'which one is better for this'?
Would this be so much more difficult than "do I use a for or a while?" I'm
dubious. I think the decision is similar. If you can use a for, do so,
otherwise resort to while. If you can get away without a <select>, do so.
> Moreover, matchers 'match a request' while selectors 'select paths'.
> They clearly separate concerns! Their functionality and implementations
> partially overlap because both require 'conditional operations', but one
> is declarative (matchers) and one is procedural (selectors).
Again, this may be a FS, but I'm dubious about how 'natural' a seperation
those concerns are. Matchers match anything, and on what other basis do
selectors 'select paths' that on the request? I'm concerned about pipelines
becoming unnecesarily convoluted because a single concern has been seperated.
Judson
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
