Re: Re: OOXML

> 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.