Ean,
A major part of the reason why Simple Methods can be difficult to read is this: you can't write
reentrant functions in Minilang. Maybe repeated chunks of Minilang codes cannot be abstracted into
neat reentrant functions.
Once you introduce reentrant functions, you'll find Minilang just as simple as any other
script/language, like PHP, C, Javascript.
Plus Minilang is specifically made for backend data operations.
As for any syntactic sugars that may be absent from Minilang, it really won't be difficult to
enhance it. All we need (or all I need) is feedback! :) Chris Howe is a good source for opinions
and experience on Minilang, I think. Maybe we can ask him.
I added the ability to do reentrant Simple Methods inside of an hour.
Jonathon
Ean Schuessler wrote:
On Wednesday 06 June 2007 10:51:28 pm David E Jones wrote:
Alternatively Ean, and maybe even better: in an ideal world what would you
use in place of the MiniLang/simple-method code (regardless of whether or
not it exists already)?
As we've done in the past, if there is anything that represents a
sufficient efficiency gain for development and maintenance it may very well
be worth the transition to it.
Wellll....
I don't like the XML approach because the code is difficult to read and it
makes me type a lot of characters that have no syntactic meaning when I
presume Minilang is intended to reduce typing. I also assume (or have heard)
that using XML simplifies parsing and generation so that a GUI based tool
could be built on top of it. I accept that idea but note that pretty much any
major language built on the Java VM generates some sort of the AST and
outputting that tree to an XML format would be pretty trivial. I also note
that we do not have such a case tool and wonder if we really want to duel
with something like BPEL (I vote no).
I think that most of the scripting conveniences afforded by MiniLang can be
achieved more thoroughly by one of the many scripting languages available for
the JVM. My personal choice would be Groovy because it offers the same
conveniences touted by other dynamic languages and its Map syntactic sugar
directly supports native Java Maps. This feature should not be underestimated
because it is suprsingly absent from both Jython and JRuby and is very, very
useful:
delegator.findByPrimaryKey("UserLogin", ["userLoginId": "admin"])
person.firstName = "Ean"
address.putAll([address1: "1000 Smith St.", stateProvinceGeoId: "TX",
postalCode: "75226"]);
...etc...
More than once I've thought about XSLT that produces Groovy from Minilang.
Regex sugar, closures, dynamic typing and tree builders all are tremendous
conveniences. Operator overloading also implies certain guilty pleasures that
are best not discussed on this public list. Plus Groovy compiles to native
bytecode and is already supported by a JSR.
Plus we'd get lots of marketing cheese out of a move like that.
I also wonder if we shouldn't wrap the dispatcher in a proxy and do things
like:
me = [:]
me.firstName = "Ean"
me.lastName = "Schuessler"
dispatcher.createPerson(me)
That's my .02 anyway.
