[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] Re: OOXML
Subject: Re: [xsl] Re: OOXML From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> Date: Mon, 30 Jun 2008 08:11:20 -0700 |
> Case in point: I don't consider XSLT to be functional because of the hoops > you have to go through to get something resembling lambda functions. On the > other hand, it's a great model of a declarative language, at least my > definition of one. Not exactly lambda-functions, but various ways of creating dynamically new functions are well-known and have been supported with FXSL for years: Composition, Currying and Partial application, creating functions dynamically on the fly: http://fxsl.sourceforge.net/articles/PartialApps/Partial%20Applications.html > Factory classes and static methods, returning implementations . . . it's a > popular design in Java, but I am struggling to think of an application of it > in XSLT. It might even be unnatural in XSLT because of the > fixed-at-compile-time import tree. (How cool it would be if > xsl:import/@href were an AVT, and the heck with optimization.) > This is possible in FXSL, passing constructor functions as parameters. > Closures are something I'd be curious to see done in XSLT, though I still > have never come across a programming problem in real life that was best > solved by using them. > Has been done for quite some time; see: http://dnovatchev.spaces.live.com/blog/cns!44B0A32C2CCF7488!384.entry -- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- Never fight an inanimate object ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play On Mon, Jun 30, 2008 at 5:31 AM, Deborah Pickett <debbiep-list-xsl@xxxxxxxxxx> wrote: > John Cavalieri wrote: >> >> Is it really OO that people want for an alternative to functional? > > I don't think it's as clear-cut as that. People bandy about terms like > "object-oriented" and "functional" and "imperative", having a neat idea in > their head of what such a language is, not realizing that the terms are > fuzzy and unlikely to be understood as the same at the other end. > > Case in point: I don't consider XSLT to be functional because of the hoops > you have to go through to get something resembling lambda functions. On the > other hand, it's a great model of a declarative language, at least my > definition of one. > > In that vein, I think that what pops into people's minds when they hear > "object-oriented" varies. Indeed, when you said this: > >> The two main highlights of OO languages are encapsulation and inheritance: > > I immediately thought "Two? What about polymorphism?". Doubtless you count > that as part of inheritance, but in my experience you can have one without > the other. > > Anyway, my point is that these same design patterns pop up in different ways > even in the same environment. I came to XSLT through DITA, which has its > own inheritance and polymorphism mechanisms (the ancestry of any given class > is encoded in a serialized default attribute). If DITA were invented today > it would probably use XML Schema typing instead. XSLT doing polymorphism on > element types rounds out what I think of as the Big Three of OO. > >> I guess what I'm wondering is what from OO could helpful? Message >> passing? Class instantiation with public members and methods? > > Message passing is pretty natural in XSLT if you use modes. It'd be even > better if modes were AVTs, because then you wouldn't be stuck with having to > enumerate all possible messages ahead of time. (Purely a wish-list item; I > would hate to think of the optimization consequences of such a change to the > language.) > > Factory classes and static methods, returning implementations . . . it's a > popular design in Java, but I am struggling to think of an application of it > in XSLT. It might even be unnatural in XSLT because of the > fixed-at-compile-time import tree. (How cool it would be if > xsl:import/@href were an AVT, and the heck with optimization.) > > Multiple inheritance I think would be tricky in XSLT, and I don't think > that's a bad thing. You'd at least have all the dispatch ambiguities that > you get in other languages with multiple inheritance. <xsl:apply-imports> > nicely fulfills the super() chain of constructors (more correctly, > initializers), and <xsl:next-match> can fulfil some multiple-dispatch uses. > > Closures are something I'd be curious to see done in XSLT, though I still > have never come across a programming problem in real life that was best > solved by using them. > > I think Andrew's hit upon some other valid points, more from a > correctness-enforcement perspective than I've been musing. Further in that > direction, I think that sometimes the default template rules are > counter-productive. It would be nice to be able to turn them off, which I > suppose you can do, verbosely, in XSLT 2.0 now that there is mode="#all" for > templates. > > So what else is left in the OO arsenal? I should stress that I use a lot of > these programming techniques already in my XSLT, and I don't think of them > as object orientation. But among people for whom XSLT is only a second, or > third, or fifth language, things might still seem more black and white.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: OOXML, Deborah Pickett | Thread | [xsl] Split with delimiter and remo, Pankaj Chaturvedi |
Re: [xsl] Split with delimiter and , Martin Honnen | Date | [xsl] Cocoon, Andrew Welch |
Month |
Keywords