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.