xsl-list
[Top] [All Lists]

Re: [xsl] Re: OOXML

2008-06-30 08:11:51
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(_at_)futzle(_dot_)com> 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.

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>