Re: [DISCUSS] New Expressions Sandbox Project...
So, does anyone have any strong opinions about the name? I am thinking that I should just pick one (not expression) and just go with it. If I change the name, I'll likely change the interface names to match. Anyone? On Sat, Apr 12, 2008 at 7:22 AM, James Carman [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 2:29 PM, James Carman [EMAIL PROTECTED] wrote: Other interesting ideas: MethodPath - you're recording a path through objects via methods calls. MethodWalker - you're walking a series of method calls. Navigator - you're navigating through a graph of objects. Property - the settable/gettable object could just be called a Property PropertyRef - it could be thought of as a property reference - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DISCUSS] New Expressions Sandbox Project...
Rahul Akolkar wrote: On Thu, Apr 10, 2008 at 2:29 PM, James Carman [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 2:12 PM, Matt Benson [EMAIL PROTECTED] wrote: Hmm, what about graphmacro? Have to be careful with graph though: without object it may be interpreted wrongly. beanmacro? Other interesting ideas: MethodPath - you're recording a path through objects via methods calls. MethodWalker - you're walking a series of method calls. Navigator - you're navigating through a graph of objects. snip/ Any of these is better, IMO. Why not simply call it commons-recorder? See a CD player implies that your can play a CD, but a CD recorder implies both. Therefore commons-recorder also implies the play part. You use it to record an own expression/macro or you come with a ready expression/macro to play it :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Fri, Apr 11, 2008 at 2:10 AM, Jörg Schaible [EMAIL PROTECTED] wrote: Why not simply call it commons-recorder? See a CD player implies that your can play a CD, but a CD recorder implies both. Therefore commons-recorder also implies the play part. You use it to record an own expression/macro or you come with a ready expression/macro to play it :) How about commons-macro? You record a macro and it can be played back later. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DISCUSS] New Expressions Sandbox Project...
[EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 2:10 AM, Jörg Schaible [EMAIL PROTECTED] wrote: Why not simply call it commons-recorder? See a CD player implies that your can play a CD, but a CD recorder implies both. Therefore commons-recorder also implies the play part. You use it to record an own expression/macro or you come with a ready expression/macro to play it :) How about commons-macro? You record a macro and it can be played back later. Maybe it's only me, but for me a macro implies something like a (human readable) script ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
I was thinking more like a macro in an editor. On 4/11/08, Jörg Schaible [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 2:10 AM, Jörg Schaible [EMAIL PROTECTED] wrote: Why not simply call it commons-recorder? See a CD player implies that your can play a CD, but a CD recorder implies both. Therefore commons-recorder also implies the play part. You use it to record an own expression/macro or you come with a ready expression/macro to play it :) How about commons-macro? You record a macro and it can be played back later. Maybe it's only me, but for me a macro implies something like a (human readable) script ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 9:38 PM, James Carman [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 8:28 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: The first-class Expression object encapsulates the specifics of the implementation (whether it be a String or some Serializable object or whatever). This way, you just code to the commons-expression API (getValue/setValue) rather than carrying around some string. Also, the implementations are free to compile their expressions so that they perform better (the MVEL implementation does this and it smokes all of the others in my simple benchmarking, because I can't get OGNL to compile its expression without a root object from the beginning). snip/ Makes sense, its worthwhile to have an opportunity to store compiled forms. I was just looking at the OGNL API, I'm not sure about the root object either. I really think being able to encapsulate these ideas is beneficial (and makes this stuff more reusable). Of course, allowing these things to be serialized is important too (for web components that need to be stored in the HTTP session such as in Wicket for example). snip/ Understood :-) I pinged Jesse Kuhnert today to ask him about it (the current API). He confirmed that it's not currently supported, but I asked if it could be. snap/ Cool, let us know if you get an update. I think on most occassions the EL can deduce the root given an expression and the context, so not having to specify it would be nice. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 11:18 PM, James Carman
[EMAIL PROTECTED] wrote:
On Wed, Apr 9, 2008 at 9:47 PM, James Carman [EMAIL PROTECTED] wrote:
So, does anyone object to me putting this code into the sandbox?
snip/
No, I support this and would like to work on it.
I've
got working versions of expressions and builders (with test cases of
course) for:
MVEL
OGNL
BeanUtils
JXPath
If you're interested, I set it up in my own SVN repository while I was
working on it:
http://svn.carmanconsulting.com/public/commons-expression/trunk
snap/
Thanks a lot, this is great. I was lost reading the emails in this
thread but the code has made things much clearer.
I have some immediate comments:
(1) The proposed API feels like [objectgraphnavigation] rather than
[expression], which is an interesting subset of expressions, but
limiting nevertheless. I'm interested in the latter, and also think it
makes the former redundant.
(2) I'd like to claim that [expression] is a solved problem ;-)
[scxml] requires pluggable expression languages and already has an
abstraction over ELs:
http://commons.apache.org/scxml/guide/contexts-evaluators.html
The core of [expression] should consist of two interfaces (I'm happy
to do this by cleaning up the corresponding bits in [scxml]):
public interface Context {
Object get(String name);
void set(String name, Object value);
}
public interface Evaluator {
Object evaluate(String expression, Context context)
throws EvaluationException;
Context newContext(Context parent);
}
Names TBD etc.
SAMPLE USAGE (untested, ofcourse):
Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example
Context context = evaluator.newContext(null);
context.put(...);
try {
/*Some type*/ result = evaluator.evaluate(..., context);
} catch (EvaluationExpression ee) {
// ...
}
We have proven implementations of this in [scxml] land for:
* EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well)
* Commons JEXL
* JavaScript (by way of Rhino)
* Various (by way of javax.script)
* Pnuts
Other comments:
* I've done adapters for two proprietary ELs
* MVEL would be trivial
* I'm not familiar with its OGNL APIs, will take a look later
To summarize, generally the above abstraction has worked well.
(3) Generics don't buy us much in terms of type safety / correctness
guarantees for [expression]. Lets not use them (easier to support 1.4
that way, for example).
(4) I don't think of BeanUtils as an expression language, or JXPath
for that matter (relates to point 1 above a bit). That doesn't mean
there can't be corresponding Evaluator implementations, just means
users of those implementations will need to understand the limitations
(and we will need to document them). For example, don't ask the
BeanUtils evaluator to evaluate 22 / 7.
(5) The [proxy] APIs have bled into your proposal. While thats
completely understandable in a PoC since you have the [proxy] usecase
in mind, we will have to clean that up. Perhaps [proxy] or [scxml]
might need a subinterface or equivalent of the cleaner [expression]
APIs, we'll have to see. If [expression] makes progress, I'd want
[scxml] to depend on it.
I suggest we use the interfaces above, I can bootstrap [expression] in
the sandbox per those.
-Rahul
Enjoy!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar [EMAIL PROTECTED] wrote:
No, I support this and would like to work on it.
That's great! I would love to have some help/input on this.
Thanks a lot, this is great. I was lost reading the emails in this
thread but the code has made things much clearer.
I have some immediate comments:
(1) The proposed API feels like [objectgraphnavigation] rather than
[expression], which is an interesting subset of expressions, but
limiting nevertheless. I'm interested in the latter, and also think it
makes the former redundant.
Yes, primarily it deals with object graph navigation, but the
Expression implementations can support more complex scenarios via the
underlying technology.
(2) I'd like to claim that [expression] is a solved problem ;-)
[scxml] requires pluggable expression languages and already has an
abstraction over ELs:
http://commons.apache.org/scxml/guide/contexts-evaluators.html
The core of [expression] should consist of two interfaces (I'm happy
to do this by cleaning up the corresponding bits in [scxml]):
public interface Context {
Object get(String name);
void set(String name, Object value);
}
public interface Evaluator {
Object evaluate(String expression, Context context)
throws EvaluationException;
Context newContext(Context parent);
}
I don't know about this API. The idea behind [expression] is that
it's not necessarily string-based (a lot of the impls are, but the
Javassist one wouldn't be; it'll probably only be available via
builder). The [expression] project strives to treat the expression as
a first-class object which encapsulates the underlying technology.
Names TBD etc.
SAMPLE USAGE (untested, ofcourse):
Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example
Context context = evaluator.newContext(null);
context.put(...);
try {
/*Some type*/ result = evaluator.evaluate(..., context);
} catch (EvaluationExpression ee) {
// ...
}
We have proven implementations of this in [scxml] land for:
* EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well)
* Commons JEXL
* JavaScript (by way of Rhino)
* Various (by way of javax.script)
* Pnuts
Other comments:
* I've done adapters for two proprietary ELs
* MVEL would be trivial
* I'm not familiar with its OGNL APIs, will take a look later
To summarize, generally the above abstraction has worked well.
I didn't consider JavaScript, but that's an interesting idea.
(3) Generics don't buy us much in terms of type safety / correctness
guarantees for [expression]. Lets not use them (easier to support 1.4
that way, for example).
I would have to disagree with this. The API I'm using makes the code
easier to read, IMHO. I would want it to use generics. No, it
doesn't necessarily *guarantee* type safety (as evidenced by the
@SuppressWarnings(unchecked) in the code), but it doesn't hurt by
having it there and makes it easier to use the code in other libraries
(like Wicket; I can imagine a Wicket ExpressionModelT which extends
IModelT).
(4) I don't think of BeanUtils as an expression language, or JXPath
for that matter (relates to point 1 above a bit). That doesn't mean
there can't be corresponding Evaluator implementations, just means
users of those implementations will need to understand the limitations
(and we will need to document them). For example, don't ask the
BeanUtils evaluator to evaluate 22 / 7.
BeanUtils does support expressions in that they have their own
expression syntax for referring to bean properties. That's why I
chose to support it. The same goes for JXPath.
(5) The [proxy] APIs have bled into your proposal. While thats
completely understandable in a PoC since you have the [proxy] usecase
in mind, we will have to clean that up. Perhaps [proxy] or [scxml]
might need a subinterface or equivalent of the cleaner [expression]
APIs, we'll have to see. If [expression] makes progress, I'd want
[scxml] to depend on it.
Well, the builder idea does require proxies to get it to work. I'm
using the InvocationRecorder support from Proxy to achieve this. I
could pull that stuff out of proxy and into [expression] if others see
that as necessary. I think the builder idea is a very nice addition,
though. It's like being able to create an anonymous inner class in
Java without having to create the class. It's almost like having a
closure (albeit a limited one)! :)
I suggest we use the interfaces above, I can bootstrap [expression] in
the sandbox per those.
I can put my existing code into the sandbox to bootstrap it. I have
access to the sandbox. I just wanted to make sure nobody completely
objected to the idea behind [expression] with respect to the commons
in general.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 8:21 AM, James Carman
[EMAIL PROTECTED] wrote:
On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar [EMAIL PROTECTED] wrote:
snip/
(1) The proposed API feels like [objectgraphnavigation] rather than
[expression], which is an interesting subset of expressions, but
limiting nevertheless. I'm interested in the latter, and also think it
makes the former redundant.
Yes, primarily it deals with object graph navigation, but the
Expression implementations can support more complex scenarios via the
underlying technology.
snap/
With a bit of a disconnect.
(2) I'd like to claim that [expression] is a solved problem ;-)
[scxml] requires pluggable expression languages and already has an
abstraction over ELs:
http://commons.apache.org/scxml/guide/contexts-evaluators.html
The core of [expression] should consist of two interfaces (I'm happy
to do this by cleaning up the corresponding bits in [scxml]):
public interface Context {
Object get(String name);
void set(String name, Object value);
}
public interface Evaluator {
Object evaluate(String expression, Context context)
throws EvaluationException;
Context newContext(Context parent);
}
I don't know about this API. The idea behind [expression] is that
it's not necessarily string-based (a lot of the impls are, but the
Javassist one wouldn't be; it'll probably only be available via
builder). The [expression] project strives to treat the expression as
a first-class object which encapsulates the underlying technology.
snip/
Since most impls are (they generate their own parse trees etc.) and
any intermediate first-class object simply gets in the way IMO.
To summarize, generally the above abstraction has worked well.
I didn't consider JavaScript, but that's an interesting idea.
snap/
Its one of the popular requests.
(3) Generics don't buy us much in terms of type safety / correctness
guarantees for [expression]. Lets not use them (easier to support 1.4
that way, for example).
I would have to disagree with this. The API I'm using makes the code
easier to read, IMHO. I would want it to use generics. No, it
doesn't necessarily *guarantee* type safety (as evidenced by the
@SuppressWarnings(unchecked) in the code), but it doesn't hurt by
having it there and makes it easier to use the code in other libraries
(like Wicket; I can imagine a Wicket ExpressionModelT which extends
IModelT).
snip/
Unconvinced, but moving on.
(4) I don't think of BeanUtils as an expression language, or JXPath
for that matter (relates to point 1 above a bit). That doesn't mean
there can't be corresponding Evaluator implementations, just means
users of those implementations will need to understand the limitations
(and we will need to document them). For example, don't ask the
BeanUtils evaluator to evaluate 22 / 7.
BeanUtils does support expressions in that they have their own
expression syntax for referring to bean properties. That's why I
chose to support it. The same goes for JXPath.
snap/
I agree, as I said its limited as-is (to bean property / object graph
navigation) and not a first class expression language. Nothing against
having those adapters.
(5) The [proxy] APIs have bled into your proposal. While thats
completely understandable in a PoC since you have the [proxy] usecase
in mind, we will have to clean that up. Perhaps [proxy] or [scxml]
might need a subinterface or equivalent of the cleaner [expression]
APIs, we'll have to see. If [expression] makes progress, I'd want
[scxml] to depend on it.
Well, the builder idea does require proxies to get it to work. I'm
using the InvocationRecorder support from Proxy to achieve this. I
could pull that stuff out of proxy and into [expression] if others see
that as necessary. I think the builder idea is a very nice addition,
though. It's like being able to create an anonymous inner class in
Java without having to create the class. It's almost like having a
closure (albeit a limited one)! :)
snip/
I'd like [expression] to have no dependencies (other than the ELs
themselves, for the various adapters).
I suggest we use the interfaces above, I can bootstrap [expression] in
the sandbox per those.
I can put my existing code into the sandbox to bootstrap it. I have
access to the sandbox. I just wanted to make sure nobody completely
objected to the idea behind [expression] with respect to the commons
in general.
snap/
I think we may have sufficiently different ideas on what we need to
begin playing in different sandboxes.
That also means we need two component names. I do think the name
[expression] would be misleading for the idea you've proposed. In
fact, thats what got me thinking we wanted similar things :-) Any
alternatives I could think of suggesting were a bit long for my taste,
I'll keep trying. I'd like to use the
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: I don't know about this API. The idea behind [expression] is that it's not necessarily string-based (a lot of the impls are, but the Javassist one wouldn't be; it'll probably only be available via builder). The [expression] project strives to treat the expression as a first-class object which encapsulates the underlying technology. snip/ Since most impls are (they generate their own parse trees etc.) and any intermediate first-class object simply gets in the way IMO. The first-class Expression object encapsulates the specifics of the implementation (whether it be a String or some Serializable object or whatever). This way, you just code to the commons-expression API (getValue/setValue) rather than carrying around some string. Also, the implementations are free to compile their expressions so that they perform better (the MVEL implementation does this and it smokes all of the others in my simple benchmarking, because I can't get OGNL to compile its expression without a root object from the beginning). (5) The [proxy] APIs have bled into your proposal. While thats completely understandable in a PoC since you have the [proxy] usecase in mind, we will have to clean that up. Perhaps [proxy] or [scxml] might need a subinterface or equivalent of the cleaner [expression] APIs, we'll have to see. If [expression] makes progress, I'd want [scxml] to depend on it. Well, the builder idea does require proxies to get it to work. I'm using the InvocationRecorder support from Proxy to achieve this. I could pull that stuff out of proxy and into [expression] if others see that as necessary. I think the builder idea is a very nice addition, though. It's like being able to create an anonymous inner class in Java without having to create the class. It's almost like having a closure (albeit a limited one)! :) snip/ I'd like [expression] to have no dependencies (other than the ELs themselves, for the various adapters). Well, the builder idea can't be done without using proxies. And, you can't do the type of proxies necessary for the majority of cases (ones that extend classes rather than implement interfaces) using the JDK proxy support only. So, you're going to have to have a dependency there somewhere (assuming you like the Builder idea). I'd rather use Proxy for this since that's its job. It knows how to make proxies using various technologies and I don't want to have to think about that in this library. Proxy doesn't have any required dependencies out of the box. It would, of course, require dependencies based on which proxying technology you choose to use in your builders. I can put my existing code into the sandbox to bootstrap it. I have access to the sandbox. I just wanted to make sure nobody completely objected to the idea behind [expression] with respect to the commons in general. snap/ I think we may have sufficiently different ideas on what we need to begin playing in different sandboxes. That also means we need two component names. I do think the name [expression] would be misleading for the idea you've proposed. In fact, thats what got me thinking we wanted similar things :-) Any alternatives I could think of suggesting were a bit long for my taste, I'll keep trying. I'd like to use the [expression] for the Context+Evaluator API, which is quite a common theme in many first class expression language impls. If people feel that [expression] isn't the right name for what I've come up with, I don't really care (as I said, what's in a name). But, the idea of an expression just fit in my mind. I'll try to come up with something else if you're really that opposed to me using the name expression. The term macro came to mind when I was thinking about a name for this thing, since the builders are essentially recording something from the user (on a proxy) that will later be played back (on some other object). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 1:46 PM, James Carman [EMAIL PROTECTED] wrote: If people feel that [expression] isn't the right name for what I've come up with, I don't really care (as I said, what's in a name). But, the idea of an expression just fit in my mind. I'll try to come up with something else if you're really that opposed to me using the name expression. The term macro came to mind when I was thinking about a name for this thing, since the builders are essentially recording something from the user (on a proxy) that will later be played back (on some other object). Other words that convey a similar idea: variable - the expression is really a variable (a value that can be modified or retrieved). value - the expression represents a settable/gettable value shortcut - the expression is a shortcut for calling a (potentially) chained series of method calls flatten - the expression flattens the chained series of method calls - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 1:59 PM, James Carman
[EMAIL PROTECTED] wrote:
On Thu, Apr 10, 2008 at 1:46 PM, James Carman
[EMAIL PROTECTED] wrote:
If people feel that [expression] isn't the right name for what I've
come up with, I don't really care (as I said, what's in a name). But,
the idea of an expression just fit in my mind. I'll try to come up
with something else if you're really that opposed to me using the name
expression. The term macro came to mind when I was thinking about
a name for this thing, since the builders are essentially recording
something from the user (on a proxy) that will later be played back
(on some other object).
Other words that convey a similar idea:
variable - the expression is really a variable (a value that can be
modified or retrieved).
value - the expression represents a settable/gettable value
shortcut - the expression is a shortcut for calling a (potentially)
chained series of method calls
flatten - the expression flattens the chained series of method calls
To spell out the macro API, it would be:
public interface MacroR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
public interface RecorderR
{
public R template();
public V MacroR,V record(V value);
}
A usage would look like:
RecorderPerson recorder = ...;
MacroPerson,String addressCityMacro =
recorder.record(recorder.template().getAddress().getCity());
Person p = ...;
String city = addressCityMacro.getValue(p);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
--- James Carman [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: I don't know about this API. The idea behind [expression] is that it's not necessarily string-based (a lot of the impls are, but the Javassist one wouldn't be; it'll probably only be available via builder). The [expression] project strives to treat the expression as a first-class object which encapsulates the underlying technology. snip/ Since most impls are (they generate their own parse trees etc.) and any intermediate first-class object simply gets in the way IMO. The first-class Expression object encapsulates the specifics of the implementation (whether it be a String or some Serializable object or whatever). This way, you just code to the commons-expression API (getValue/setValue) rather than carrying around some string. Also, the implementations are free to compile their expressions so that they perform better (the MVEL implementation does this and it smokes all of the others in my simple benchmarking, because I can't get OGNL to compile its expression without a root object from the beginning). (5) The [proxy] APIs have bled into your proposal. While thats completely understandable in a PoC since you have the [proxy] usecase in mind, we will have to clean that up. Perhaps [proxy] or [scxml] might need a subinterface or equivalent of the cleaner [expression] APIs, we'll have to see. If [expression] makes progress, I'd want [scxml] to depend on it. Well, the builder idea does require proxies to get it to work. I'm using the InvocationRecorder support from Proxy to achieve this. I could pull that stuff out of proxy and into [expression] if others see that as necessary. I think the builder idea is a very nice addition, though. It's like being able to create an anonymous inner class in Java without having to create the class. It's almost like having a closure (albeit a limited one)! :) snip/ I'd like [expression] to have no dependencies (other than the ELs themselves, for the various adapters). Well, the builder idea can't be done without using proxies. And, you can't do the type of proxies necessary for the majority of cases (ones that extend classes rather than implement interfaces) using the JDK proxy support only. So, you're going to have to have a dependency there somewhere (assuming you like the Builder idea). I'd rather use Proxy for this since that's its job. It knows how to make proxies using various technologies and I don't want to have to think about that in this library. Proxy doesn't have any required dependencies out of the box. It would, of course, require dependencies based on which proxying technology you choose to use in your builders. Without having looked at the code, I'm not understanding why [proxy] would be a first-class dependency. Seems like it would be optional depending on whether a client of [expression?] wanted to use the recording implementation. I still agree with Rahul that object graph navigation is the commonality here. But once you remove the concept of an integral String representation it seems like generic functor stuff to me. JXPath has Pointers that behave somewhat like what you're suggesting, James, but ultimately they are still tied to the original syntactic representation. Of course, object graph navigation is 3/4 of OGNL's name, isn't it? I MIGHT be able to accept the recording implementation as an expression if you at least made the toString() of the recording present something expressionlike: e.g. record getFoo() getBar() getBaz() toString(): getFoo().getBar().getBaz() -Matt I can put my existing code into the sandbox to bootstrap it. I have access to the sandbox. I just wanted to make sure nobody completely objected to the idea behind [expression] with respect to the commons in general. snap/ I think we may have sufficiently different ideas on what we need to begin playing in different sandboxes. That also means we need two component names. I do think the name [expression] would be misleading for the idea you've proposed. In fact, thats what got me thinking we wanted similar things :-) Any alternatives I could think of suggesting were a bit long for my taste, I'll keep trying. I'd like to use the [expression] for the Context+Evaluator API, which is quite a common theme in many first class expression language impls. If people feel that [expression] isn't the right name for what I've come up with, I don't really care (as I said, what's in a name). But, the idea of an expression just fit in my mind. I'll try to come up with something else if you're really that opposed to me using the name expression. The term macro came to mind when I was
Re: [DISCUSS] New Expressions Sandbox Project...
Hmm, what about graphmacro? Have to be careful with
graph though: without object it may be
interpreted wrongly. beanmacro?
-Matt
--- James Carman [EMAIL PROTECTED] wrote:
On Thu, Apr 10, 2008 at 1:59 PM, James Carman
[EMAIL PROTECTED] wrote:
On Thu, Apr 10, 2008 at 1:46 PM, James Carman
[EMAIL PROTECTED] wrote:
If people feel that [expression] isn't the
right name for what I've
come up with, I don't really care (as I said,
what's in a name). But,
the idea of an expression just fit in my mind.
I'll try to come up
with something else if you're really that
opposed to me using the name
expression. The term macro came to mind
when I was thinking about
a name for this thing, since the builders are
essentially recording
something from the user (on a proxy) that will
later be played back
(on some other object).
Other words that convey a similar idea:
variable - the expression is really a variable
(a value that can be
modified or retrieved).
value - the expression represents a
settable/gettable value
shortcut - the expression is a shortcut for
calling a (potentially)
chained series of method calls
flatten - the expression flattens the chained
series of method calls
To spell out the macro API, it would be:
public interface MacroR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
public interface RecorderR
{
public R template();
public V MacroR,V record(V value);
}
A usage would look like:
RecorderPerson recorder = ...;
MacroPerson,String addressCityMacro =
recorder.record(recorder.template().getAddress().getCity());
Person p = ...;
String city = addressCityMacro.getValue(p);
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 2:10 PM, Matt Benson [EMAIL PROTECTED] wrote: Without having looked at the code, I'm not understanding why [proxy] would be a first-class dependency. Seems like it would be optional depending on whether a client of [expression?] wanted to use the recording implementation. Proxy isn't a required dependency. You could use the existing Expression implementations without having to record them. However, the recording feature is what makes this library so cool, IMHO. Recording gives you the following benefits: - You're using Java syntax to record what you want. - If you change method names, you'll either get a compiler error on your recording code or the refactoring utility will change it for you. - Less error-prone. If you can traverse the object graph in Java, the builder can make an expression that can do it (aside from indexing into arrays or using fields of course). I still agree with Rahul that object graph navigation is the commonality here. Oooh, what about commons-navigator? But once you remove the concept of an integral String representation it seems like generic functor stuff to me. JXPath has Pointers that behave somewhat like what you're suggesting, James, but ultimately they are still tied to the original syntactic representation. Of course, object graph navigation is 3/4 of OGNL's name, isn't it? Once you turn the originating syntactic representation into an Expression object, you're free to do with it what you want. The syntax is hidden behind the Expression. So, other libraries that take Expression objects (like the one I'm going to help write for Wicket) don't have to have any idea that you're using a String behind the scenes (or possibly nothing but a hard-wired class that does exactly what you did in the first place). I MIGHT be able to accept the recording implementation as an expression if you at least made the toString() of the recording present something expressionlike: e.g. record getFoo() getBar() getBaz() toString(): getFoo().getBar().getBaz() That would be easy to do, really. All of the recorders currently use Proxy's idea of an InvocationRecorder which gives you a list of RecordedInvocations. It'd be trivial to write a toString() method somewhere that took the method names and made a string like that out of them (along with the parameters used along the way too). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 2:12 PM, Matt Benson [EMAIL PROTECTED] wrote: Hmm, what about graphmacro? Have to be careful with graph though: without object it may be interpreted wrongly. beanmacro? Other interesting ideas: MethodPath - you're recording a path through objects via methods calls. MethodWalker - you're walking a series of method calls. Navigator - you're navigating through a graph of objects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 2:29 PM, James Carman [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 2:12 PM, Matt Benson [EMAIL PROTECTED] wrote: Hmm, what about graphmacro? Have to be careful with graph though: without object it may be interpreted wrongly. beanmacro? Other interesting ideas: MethodPath - you're recording a path through objects via methods calls. MethodWalker - you're walking a series of method calls. Navigator - you're navigating through a graph of objects. snip/ Any of these is better, IMO. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Thu, Apr 10, 2008 at 8:28 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: The first-class Expression object encapsulates the specifics of the implementation (whether it be a String or some Serializable object or whatever). This way, you just code to the commons-expression API (getValue/setValue) rather than carrying around some string. Also, the implementations are free to compile their expressions so that they perform better (the MVEL implementation does this and it smokes all of the others in my simple benchmarking, because I can't get OGNL to compile its expression without a root object from the beginning). snip/ Makes sense, its worthwhile to have an opportunity to store compiled forms. I was just looking at the OGNL API, I'm not sure about the root object either. I really think being able to encapsulate these ideas is beneficial (and makes this stuff more reusable). Of course, allowing these things to be serialized is important too (for web components that need to be stored in the HTTP session such as in Wicket for example). I pinged Jesse Kuhnert today to ask him about it (the current API). He confirmed that it's not currently supported, but I asked if it could be. If people feel that [expression] isn't the right name for what I've come up with, I don't really care (as I said, what's in a name). But, the idea of an expression just fit in my mind. I'll try to come up with something else if you're really that opposed to me using the name expression. The term macro came to mind when I was thinking about a name for this thing, since the builders are essentially recording something from the user (on a proxy) that will later be played back (on some other object). snap/ Yup, and [expression] doesn't convey that IMO. Thanks for being open to finding an alternative name. No problem at all! As I've said before, I'm not all about the name and I agree with you that I don't necessarily want to tie up a name like expression since it could be used for a library which provides a more complete abstraction of expression languages. This is somewhat like picking a keyword for a programming language. We have to be careful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DISCUSS] New Expressions Sandbox Project...
I wanted to start up a discussion about maybe starting a new sandbox
project for expression abstraction. It could be named
commons-expresso. I realize that there's a J2EE framework out there
called Expresso, but its site hasn't been updated since 2005, so I
don't know how active it is or if this would even be a conflict
anyway. I don't really care what it's called. I just care about the
content.
For those who have not been reading the other threads, I would like to
create a project which allows us to abstract the idea of an
expression in Java. Here's the main interface:
public interface Expression
{
public Object getValue(Object root);
public void setValue(Object root, Object value);
}
This could be generified to perhaps:
public interface ExpressionR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
Anyway, the guts of the project would be the implementations of this
interface. I have plans to implement it using the following
technologies for now (please add suggestions if you have them):
Javassist
MVEL
OGNL
JSTL-EL
JXPath
That's just a preliminary list, but you get the idea of the sort of
thing I'm looking for. Matt Benson has suggested that this sort of
thing might be best suited to go into his Morph project currently
located at Sourceforge. Currently, it doesn't have anything like
this. The project would also contain expression builder
implementations which would allow you to use Java to build up the
expression:
public interface ExpressionBuilderR
{
public R recorder();
public V ExpresionR,V buildExpression(V value);
}
Example usage:
ExpressionBuilder builder = new JavassistExpressionBuilderPerson();
ExpressionPerson,String expr =
builder.buildExpression(builder.recorder().getAddress().getCity());
Person p = ...;
String city = expr.getValue(p);
The cool thing about this is that you can switch the expression
implementation without changing how you build up the expression!
Thoughts anyone?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
2008/4/9, James Carman [EMAIL PROTECTED]: I realize that there's a J2EE framework out there called Expresso, but its site hasn't been updated since 2005, so I don't know how active it is or if this would even be a conflict anyway. There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Antonio
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
--- James Carman [EMAIL PROTECTED] wrote:
I wanted to start up a discussion about maybe
starting a new sandbox
project for expression abstraction. It could be
named
commons-expresso. I realize that there's a J2EE
framework out there
called Expresso, but its site hasn't been updated
since 2005, so I
don't know how active it is or if this would even be
a conflict
anyway. I don't really care what it's called. I
just care about the
content.
For those who have not been reading the other
threads, I would like to
create a project which allows us to abstract the
idea of an
expression in Java. Here's the main interface:
public interface Expression
{
public Object getValue(Object root);
public void setValue(Object root, Object value);
}
This could be generified to perhaps:
public interface ExpressionR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
Anyway, the guts of the project would be the
implementations of this
interface. I have plans to implement it using the
following
technologies for now (please add suggestions if you
have them):
Javassist
MVEL
OGNL
JSTL-EL
JXPath
That's just a preliminary list, but you get the idea
of the sort of
thing I'm looking for. Matt Benson has suggested
that this sort of
thing might be best suited to go into his Morph
project currently
located at Sourceforge.
Actually, to clarify, Morph isn't mine. Matt
Sgarlata is the primary developer; I just came in
midway and started helping out (at least I like to
think my input has been helpful)... then, I wasn't
necessarily suggesting that new work on the expression
concept should go into Morph, either. Actually I see
Morph being broken down into smaller pieces once we
get it into Commons. It sounds like you're suggesting
a package similar to [proxy]/[logging]/[openpgp] whose
basic purpose is to provide a common interface over
various similar underlying technologies. I honestly
think Morph @ Commons would ultimately have its
Language facilities removed or moved elsewhere, so
maybe there's not much overlap here beyond the idea
that your proposed project might conceivably contain
one or more built-in implementations, and one of these
might be derived from Morph's basic Language
implementation, SimpleLanguage.
Currently, it doesn't have
anything like
this. The project would also contain expression
builder
implementations which would allow you to use Java to
build up the
expression:
public interface ExpressionBuilderR
{
public R recorder();
public V ExpresionR,V buildExpression(V
value);
}
Example usage:
ExpressionBuilder builder = new
JavassistExpressionBuilderPerson();
ExpressionPerson,String expr =
builder.buildExpression(builder.recorder().getAddress().getCity());
Person p = ...;
String city = expr.getValue(p);
The cool thing about this is that you can switch the
expression
implementation without changing how you build up the
expression!
Thoughts anyone?
This would qualify as one of the built-in expression
engines I mentioned before, really. So... you're
suggesting that _most_ of the expression factory
implementations supported by this proposition would be
built from Strings, but that it wouldn't necessarily
be so all the time? How are you intending your
recordable implementation to be able to handle set vs.
get operations, though? I don't get that from your
example.
-Matt
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On 09/04/2008, James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. Anyway, the name would be [Apache] Commons Expresso, not just Expresso. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
--- James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. I'm not convinced that, once you remove the constraint of a String representation, that what you are talking about is necessarily an expression. Also given the concern I brought up about recording, explicitly calling getters doesn't AFAICT obviously yield a result that knows how to accomplish a setValue. -Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:24 AM, Matt Benson [EMAIL PROTECTED] wrote: Actually, to clarify, Morph isn't mine. Matt Sgarlata is the primary developer; I just came in midway and started helping out (at least I like to think my input has been helpful)... then, I wasn't necessarily suggesting that new work on the expression concept should go into Morph, either. I apologize. I thought the project was yours. My mistake. This would qualify as one of the built-in expression engines I mentioned before, really. So... you're suggesting that _most_ of the expression factory implementations supported by this proposition would be built from Strings, but that it wouldn't necessarily be so all the time? How are you intending your recordable implementation to be able to handle set vs. get operations, though? I don't get that from your example. Yes, most of them would be based on Strings (we'd probably have a superclass for string-based expressions). But, Javassist would actually generate a class at runtime to evaluate the expression. As for how we provide set operations, the recorder basically records what you have done, what methods you called and their parameters. Then, the builder looks at that information and figures out how to build up the expression so that it's settable. Ognl provides this sort of thing out of the box (see the Ognl.setValue method I think it's called); the string basically points to a value and you can use that string to set/get either way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
2008/4/9, sebb [EMAIL PROTECTED]: On 09/04/2008, James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. Anyway, the name would be [Apache] Commons Expresso, not just Expresso. It doesn't matter, at Tiles we were refused the name of Dimensions for Apache Tiles Dimensions because Dimensions is already a piece of software. We needed to rename it (FYI it is Kaolin). Antonio
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:28 AM, Matt Benson [EMAIL PROTECTED] wrote: I'm not convinced that, once you remove the constraint of a String representation, that what you are talking about is necessarily an expression. Also given the concern I brought up about recording, explicitly calling getters doesn't AFAICT obviously yield a result that knows how to accomplish a setValue. Yes, the builder would be somewhat limited. It wouldn't allow you to build expressions for stuff like indexing into arrays or other more complex situations, but it would cover the simple property traversal situations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 7:18 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: There is already a regular-expression tool called Expresso: http://www.ultrapico.com/Expresso.htm Come on, James, express yourself better :-D Thanks, Antonio. :) Ok, I googled only shortly to look for something (I think I typed expresso java and looked at the first couple of hits). Again, I don't care about the name, but I do like it. I'd go for commons-expression (or commons-express) just as easily, though. I'm mainly concerned with the content. The Commons rule is (or at least was) that Commons components should have boring functional names, so Commons Expression would fit, but Commons Expresso would not. (Yes, there are some components that do not conform, but they existed prior to the instigation of the rule.) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:34 AM, Martin Cooper [EMAIL PROTECTED] wrote: The Commons rule is (or at least was) that Commons components should have boring functional names, so Commons Expression would fit, but Commons Expresso would not. (Yes, there are some components that do not conform, but they existed prior to the instigation of the rule.) No big deal. What's in a name? That which we call a rose by any other name would smell as sweet! Ooooh! I've got it! How about comons-rose? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 10:28 AM, Matt Benson [EMAIL PROTECTED] wrote: I'm not convinced that, once you remove the constraint of a String representation, that what you are talking about is necessarily an expression. Also given the concern I brought up about recording, explicitly calling getters doesn't AFAICT obviously yield a result that knows how to accomplish a setValue. Also, what I'm proposing would be in the sandbox, so maybe I can get some code in there so that we can look at it. If we don't like it, we can remove it or make it dormant. I just wanted to make sure that the idea of the project doesn't go against the charter. I guess in the strictest sense, it does, since it's somewhat of a framework. Then again, so is proxy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
Excuse the top post, but there isn't much context to
what I want to say.
Beyond what I've already said wrt Morph, its Language
concept does allow for setting and getting from
expressions, as do those various libraries to which
James plans to interface. But Morph also contains a
Reflector abstraction, which I have suggested is
suited to be a discrete Commons component. Morph
implements a Language with a Reflector. The only
difference between the two is that a Reflector is
intended to set/get a property exactly one level
removed from the source object. Perhaps that is an
unnecessary distinction and the [expression] idea is
really another way of expressing the need for generic
reflectors that can get/set a -possibly nested-
property given a root object (BeanUtils and Spring
have also implemented this basic requirement as well).
I don't think this POV invalidates Morph's existing
single-level Reflectors, nor do I see any real
conflict with complex Reflectors being dependent on
simple Reflectors.
To address the other part of your proposal, James, the
record/playback mechanism: wouldn't the resulting
object be a functor a la [functor]? A get would be a
function, a set a procedure.
-Matt
--- James Carman [EMAIL PROTECTED] wrote:
I wanted to start up a discussion about maybe
starting a new sandbox
project for expression abstraction. It could be
named
commons-expresso. I realize that there's a J2EE
framework out there
called Expresso, but its site hasn't been updated
since 2005, so I
don't know how active it is or if this would even be
a conflict
anyway. I don't really care what it's called. I
just care about the
content.
For those who have not been reading the other
threads, I would like to
create a project which allows us to abstract the
idea of an
expression in Java. Here's the main interface:
public interface Expression
{
public Object getValue(Object root);
public void setValue(Object root, Object value);
}
This could be generified to perhaps:
public interface ExpressionR,V
{
public V getValue(R root);
public void setValue(R root, V value);
}
Anyway, the guts of the project would be the
implementations of this
interface. I have plans to implement it using the
following
technologies for now (please add suggestions if you
have them):
Javassist
MVEL
OGNL
JSTL-EL
JXPath
That's just a preliminary list, but you get the idea
of the sort of
thing I'm looking for. Matt Benson has suggested
that this sort of
thing might be best suited to go into his Morph
project currently
located at Sourceforge. Currently, it doesn't have
anything like
this. The project would also contain expression
builder
implementations which would allow you to use Java to
build up the
expression:
public interface ExpressionBuilderR
{
public R recorder();
public V ExpresionR,V buildExpression(V
value);
}
Example usage:
ExpressionBuilder builder = new
JavassistExpressionBuilderPerson();
ExpressionPerson,String expr =
builder.buildExpression(builder.recorder().getAddress().getCity());
Person p = ...;
String city = expr.getValue(p);
The cool thing about this is that you can switch the
expression
implementation without changing how you build up the
expression!
Thoughts anyone?
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 3:01 PM, Matt Benson [EMAIL PROTECTED] wrote: To address the other part of your proposal, James, the record/playback mechanism: wouldn't the resulting object be a functor a la [functor]? A get would be a function, a set a procedure. Yes, they would, and I was planning on providing adapters to that effect. I wouldn't necessarily code to the functor API, but you could use the Expression object as a function by wrapping it with the adapter class. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 3:01 PM, Matt Benson [EMAIL PROTECTED] wrote: Excuse the top post, but there isn't much context to what I want to say. Beyond what I've already said wrt Morph, its Language concept does allow for setting and getting from expressions, as do those various libraries to which James plans to interface. But Morph also contains a Reflector abstraction, which I have suggested is suited to be a discrete Commons component. Morph implements a Language with a Reflector. The only difference between the two is that a Reflector is intended to set/get a property exactly one level removed from the source object. Perhaps that is an unnecessary distinction and the [expression] idea is really another way of expressing the need for generic reflectors that can get/set a -possibly nested- property given a root object (BeanUtils and Spring have also implemented this basic requirement as well). I don't think this POV invalidates Morph's existing single-level Reflectors, nor do I see any real conflict with complex Reflectors being dependent on simple Reflectors. To address the other part of your proposal, James, the record/playback mechanism: wouldn't the resulting object be a functor a la [functor]? A get would be a function, a set a procedure. So, does anyone object to me putting this code into the sandbox? I've got working versions of expressions and builders (with test cases of course) for: MVEL OGNL BeanUtils JXPath - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] New Expressions Sandbox Project...
On Wed, Apr 9, 2008 at 9:47 PM, James Carman [EMAIL PROTECTED] wrote: So, does anyone object to me putting this code into the sandbox? I've got working versions of expressions and builders (with test cases of course) for: MVEL OGNL BeanUtils JXPath If you're interested, I set it up in my own SVN repository while I was working on it: http://svn.carmanconsulting.com/public/commons-expression/trunk Enjoy! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
