This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: The evaluate function


I knew I'd be tapping into some controversy... Just didn't know how fierce
:)

I'm still unclear how the addition of a dynamic eval, if implemented as a
function, would violate the assumption that all (other) expressions are
static.  Would it be possible to treat these as special and treat the rest
as optimizable?

> Without answering your question, I'll address what I think you're implying
:)

No implication intended. I really do want to know which processors don't
support the eval function. If I end up relying on the existence of such a
capability (without the support of the standard) I'd at least like to know
that it's generally available. (Yes, I know, bad practice in the standards
world).
 
> Introducing evaluate() now, IMHO, would be an example of premature
optimization.

Hmm? Are you saying that it's too early in the language's history to
introduce such a feature (and remove the assumption of static expressions)?
If so, wouldn't it be an example of premature de-optimization ;-)

Mark


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]