[
https://issues.apache.org/jira/browse/SANDBOX-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13951831#comment-13951831
]
Andre Diermann commented on SANDBOX-464:
----------------------------------------
Hi Benedikt,
if you put it like this we should maybe discuss if it make sense in general to
use expressions along with a fluent API which is in turn designed to express an
expression.
Of course allowing expressions in BU1 makes the use of the API a way more
convenient. But the design of BU2's API already covers that.
So by allowing both it is a mitigation of the fluent API itself and may lead to
very poor code [3]. On the other hand a fluent API call may become very long
[1]. In relation to this providing a dedicated convenient method for
expressions would IMHO add some comfort for an API user [2]. For instance:
[1]
on(addressBook).getMapped("provider").with("Google").getIndexed("contact").at(5).getMapped("address").with("home").get("street")
[2]
on(addressBook).getExpressed("provider(google).contact[5].address(home).street")
[3]
on(addressBook).get("provider(google).contact[5]").getMapped("address").with("home").get("street.yetAnotherNestedProperty")
So, what you can see is that in [1] there is a clean elegant "type safe" call,
which unfortunately could become quite long. [2] somehow mitigates the fluent
API but shortens the call. May be good for API users who know their beans very
good and put convenience over type safety. Allowing [3], which is what you are
thinking of in your comment above, would IMHO permit and encourage the user to
mix everything up.
In conclusion, providing a dedicated method for expressions as convenience
would make it explicit for the user what he is doing. I think that is legal.
But mixing the fluent API with expressions (which means to somehow overload
each method and making it do several things at once depending on what the user
passes as parameter) is poor IMHO. This could be the source of many runtime
errors because it is less strict and the user may not know what he is doing
(because a lot of things happens under the hood which he is not aware of).
Again, I think we should have in mind why expressions where nice to use in BU1
but the API of BU2 is already designed to represent expressions itself.
Cheers,
André
> Add support for interpreting property expressions
> -------------------------------------------------
>
> Key: SANDBOX-464
> URL: https://issues.apache.org/jira/browse/SANDBOX-464
> Project: Commons Sandbox
> Issue Type: Task
> Components: BeanUtils2
> Affects Versions: Nightly Builds
> Reporter: Benedikt Ritter
> Attachments: Commons-Sandbox-464-Get.patch
>
>
> BeanUtils 1 has the functionality to interpret property paths. For example
> the call:
> {code:java}
> BeanUtils.getProperty("adress.street", person);
> {code}
> would first get the address of the given person and then get the street from
> the address and return it. The same is possible for list and mapped
> properties.
> In order to be supplement for BeanUtils1, we need to implement this in
> BeanUtils2.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
