Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: Bean / Property Utils
    • Labels:
      None

      Description

      The attached patch allows users to easily define what I'm calling a "fluid" bean (though there might be a better name for it).

      The idea here is to write a bean that doesn't follow the standard JavaBean convention. Specifically, a "fluid" bean's setters return "this," so you can "chain" calls to the setters, and the getters and setters don't start with "get/set" but are just the name of the property. For example:

      public class Employee extends AbstractFluidBean {
        private String firstName, lastName;
        public String firstName() { return firstName; }
        public Employee firstName(String firstName) {
          this.firstName = firstName;
          return this;
        }
        public String lastName() { return lastName; }
        public Employee lastName(String lastName) {
          this.lastName = lastName;
          return this;
        }
      }

      Fluid beans have some limitations: you can't use indexed or mapped properties with a fluid bean (because there's no way to disambiguate an indexed getter from a simple setter). I think that's OK because indexed properties are a bit silly. (Why not just return a List or a Map?)

      But I think they have substantial readability advantages. With a fluid bean, you can write code like this:

      HumanResources.hire(new Employee().firstName("Dan").lastName("Fabulich"));
      

      For an example of fluid chained setters in the wild, see (for example) Effective Java Second Edition by Joshua Bloch. In Item 2 "Consider a builder when faced with many constructor parameters" Bloch defines a fluid bean with chained setters, so you can use it like this:

      NutritionFacts cocoCola = new NutritionFacts.Builder(240, 8)
        .calories(100).sodium(35).carbohydrate(27).build();
      

        Activity

        Hide
        Dan Fabulich added a comment -

        I'd like to say a few points in defense of this code, but then I'll just migrate this discussion over to the commons-dev mailing list.

        It's not entirely clear to me whether Niall is saying that fluid beans are merely inappropriate for inclusion in BeanUtils, or whether he thinks that the very idea of fluid beans is generally without merit.

        For the record, I think fluid beans are at least as useful as DynaBeans. Specifically, I think chained getters/setters are a little better (and more Java-like) than dynamic expressions, because my IDE can autocomplete static method names, because I don't have to cast the return value (it's already automatically type-safe), and because the compiler can catch errors before runtime.

        So, supposing that fluid beans are useful... are they appropriate for inclusion in BeanUtils? I'm not as sure about that, but I do think so.

        Niall argues that BeanUtils has always been based on the JavaBeans standard, but fluid beans aren't. But BeanUtils already provides lots of support for non-standard beans. For example, it supports non-standard "mapped" properties in addition to standard "indexed" properties. And DynaBeans can't even be introspected by the java.beans.Introspector; they don't follow the JavaBeans naming standard at all.

        For comparison, the standard java.beans.Introspector can discover and use fluid methods. AbstractFluidBean extends SimpleBeanInfo, overriding getPropertyDescriptors. If you define a bean that extends AbstractFluidBean, all of the rest of the BeanUtils will work just fine with your new fluid bean. (You can even configure a fluid bean with the NetBeans GUI Builder.)

        Ultimately, if BeanUtils is just a library to dynamically manipulate beans, then, yes, fluid beans are clearly out of scope. But if BeanUtils is meant to be a perfectly general library of convenient utilities for working with beans, then I think we should strongly consider including this code (or something like it) in BeanUtils.

        Show
        Dan Fabulich added a comment - I'd like to say a few points in defense of this code, but then I'll just migrate this discussion over to the commons-dev mailing list. It's not entirely clear to me whether Niall is saying that fluid beans are merely inappropriate for inclusion in BeanUtils, or whether he thinks that the very idea of fluid beans is generally without merit. For the record, I think fluid beans are at least as useful as DynaBeans. Specifically, I think chained getters/setters are a little better (and more Java-like) than dynamic expressions, because my IDE can autocomplete static method names, because I don't have to cast the return value (it's already automatically type-safe), and because the compiler can catch errors before runtime. So, supposing that fluid beans are useful... are they appropriate for inclusion in BeanUtils? I'm not as sure about that, but I do think so. Niall argues that BeanUtils has always been based on the JavaBeans standard, but fluid beans aren't. But BeanUtils already provides lots of support for non-standard beans. For example, it supports non-standard "mapped" properties in addition to standard "indexed" properties. And DynaBeans can't even be introspected by the java.beans.Introspector; they don't follow the JavaBeans naming standard at all. For comparison, the standard java.beans.Introspector can discover and use fluid methods. AbstractFluidBean extends SimpleBeanInfo, overriding getPropertyDescriptors. If you define a bean that extends AbstractFluidBean, all of the rest of the BeanUtils will work just fine with your new fluid bean. (You can even configure a fluid bean with the NetBeans GUI Builder.) Ultimately, if BeanUtils is just a library to dynamically manipulate beans, then, yes, fluid beans are clearly out of scope. But if BeanUtils is meant to be a perfectly general library of convenient utilities for working with beans, then I think we should strongly consider including this code (or something like it) in BeanUtils.
        Hide
        Niall Pemberton added a comment -

        I'm against adding this to BeanUtils - its always been based on "conforming to the JavaBeans naming patterns for property getters and setters". IMO we should retain this principle and reject requests that go against this. Its also unclear to me why something which is designed to make the manual coding of the getting/setting of properties (i.e. method chaining) easier would be of much benefit to a component which is designed to dynamically perform this task through expressions.

        Show
        Niall Pemberton added a comment - I'm against adding this to BeanUtils - its always been based on "conforming to the JavaBeans naming patterns for property getters and setters". IMO we should retain this principle and reject requests that go against this. Its also unclear to me why something which is designed to make the manual coding of the getting/setting of properties (i.e. method chaining) easier would be of much benefit to a component which is designed to dynamically perform this task through expressions.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dan Fabulich
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development