Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Date: Thu, 12 Dec 2002 15:34:34 -0800 (PST)
From: Rodney Waldhoff <rwaldhoff@apache.org>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [Jelly] Towards Functional programming in Jelly scripts
In-Reply-To: <BA1E7358.C39E%tvj@pobox.com>
Message-ID: <20021212153209.I30017-100000@icarus.apache.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'll withhold judgement on the doTag returns Object idea for now, except
to say I've also run into situations where it something like that would be
useful (and it may not be that disruptive if most folks extend TagSupport
and we did something like: Object doTagWithReturn(XMLOutput out) {
doTag(out); return null; }) but as to how one might accomplish this in the
current API, I think something like this might suffice:

interface FunctionalTagParent {
  void addResult(Object obj);
}

class FunctionalTagParentBase extends TagSupport implements FunctionalTagParent {
  List results = new ArrayList();
  void addResult(Object obj) {
     results.add(obj);
  }

  Iterator getResults() {
     return results.iterator();
  }
}

class AndTag extends FunctionalTagParentBase implements FunctionalTagParent {
  public void doTag(XMLOutput out) {
    invokeBody(out);
    boolean result = true;
    for(Iterator iter = getResults(); iter.hasNext();) {
      result &= ((Boolean)(iter.next())).booleanValue();
    }
    FunctionalTagParent parent = findAncestorWithClass(FunctionalTagParent.class);
    if(null != parent) { parent.addResult(new Boolean(result)); }
  }
}

etc.

This is what I've done in similiar circumstances (e.g., this is how
<j:invoke> and <j:new> work with <j:arg>).  Is this an approach you've
already considered?

On Thu, 12 Dec 2002, Todd Jonker wrote:

> Hey Jellyfolk,
>
> I'm trying to write some Jelly tags specific to a custom component
> framework.  In doing so, I realized that it would be extremely helpful to be
> able to write functional tags.  In effect, I'd like Jelly to be able to
> support a functional programming paradigm in addition to its current
> procedural paradigm.
>
> In short, I suggest that Script.run() and Tag.doTag() both be modified to
> return Object.  In other words, every tag becomes an expression that can
> evaluate to a single value.  Those tags for which this isn't meaningful can
> simply return null.
>
> People familiar with Scheme or Lisp will immediately recognize what I'm
> looking for and why: it will enable even easier scripting with more flexible
> evaluation models.
>
> Let me explain with a concrete example.  I want to extend JellySwing to have
> an expression language that can perform Action enabling, eg:
>
> <and>
>   <instanceof value="${something}" class="MyClass" />
>   <isNotNull value="${another}/>
>   <core:invoke method="isReady" on="${another}"/>
> </and>
>
> The value of this script would be a Boolean.  Functional tags like these
> would also be of obvious utility in JellyUnit, since this can express more
> things than Jexl (as far as I can tell).  It can also be transparently
> extended by any tag library without relying on variable-naming conventions.
>
>
> The problem I've run into is that the only way to get a value out of a
> script is via the JellyContext, by defining a variable name and making sure
> my tag sticks the result in the right place.  But it order to get this model
> to interact with existing logical and expression tags, the "result" variable
> has to be scattered all over the file.
>
> (Harking back to grad school, one observes that the functional model can
> cleanly express the procedural model, whereas the opposite is not true.)
>
>
> Perhaps there's a way to get this kind of functionality from the existing
> APIs, but I've searched all over and can't see how to do it.
>
> I realize that this API extension would involve adding lots of "return
> null"s to existing tags and scripts, but it'll be MUCH easier to do this now
> while Jelly's still in Beta.  And I believe the added power and
> expressiveness are well worth the effort.  Of course I volunteer to help
> make the transition if its implemented.
>
>
> I'd love to hear feedback from James and the other users.
>
> Cheers,
> -Todd
>
> --
> I look for what needs to be done.... After all, that's how the universe
> designs itself. -R. Buckminster Fuller, engineer, designer, and architect
> (1895-1983)