+1 for Gary's second option as well. On Sun, Sep 1, 2024 at 3:47 AM Niall Pemberton <niall.pember...@gmail.com> wrote:
> On Sat, 31 Aug 2024 at 20:45, Dávid Szigecsán <sige...@gmail.com> wrote: > > > Hi, > > > > While I'm still getting familiar with things here, I'd like to share my > > thoughts on this issue. In my view, version 2.0 typically signifies a > break > > in backward compatibility, which makes the second solution—changing the > > supertype's behavior—acceptable. Given the existence of BeanUtilsBean2 > and > > ConvertUtilsBean2, it seems the plan was to modify the behavior in the > next > > major release (2.0). > > > > The only reason the 2nd beans were added was to preserve compatibility at > the time > https://issues.apache.org/jira/browse/BEANUTILS-285 > > Original JIRA: > https://issues.apache.org/jira/browse/BEANUTILS-258 > > > > My question is whether we intend to support the "old" behavior in any > > capacity. If so, I believe an alternative solution is necessary, rather > > than relying on the first solution, which involves overriding methods in > a > > subclass. This approach might violate the SOLID principles, specifically > > the Liskov Substitution Principle, by altering behavior in a subclass. > > > > No, we should IMO remove it - there were only downsides in the old > behaviour that limited users. The new behaviour allowed the users to > configure whatever they want. A user could register converters which > reproduce the old behaviour if they wanted. > > IMO we should definitely go with Gary's second option: > "pull up the "2" classes's method into their respective supertype and > adjust the tests to make the "2" behavior the _only_ behavior" > > Niall > > > > > > Regards, > > David > > > > Gary Gregory <garydgreg...@gmail.com> ezt írta (időpont: 2024. aug. 31., > > Szo, 20:09): > > > > > Hi All, > > > > > > I want us to decide what we want for 2.0 with the classes > > > BeanUtilsBean2 vs BeanUtilsBean, and ConvertUtilsBean2 vs > > > ConvertUtilsBean. > > > > > > For your convenience: > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean2.java > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean.java > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean2.java > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean.java > > > > > > I plan on doing a 2.0.0-M1 release in mid-September if we can resolve > > > this and put the new package out in the wild. > > > > > > Possible solutions: > > > > > > 1) Do nothing, keep both classes and explain when to use one vs. the > > other > > > 2) The "simplest" change is to pull up the "2" classes's method into > > > their respective supertype and adjust the tests to make the "2" > > > behavior the _only_ behavior > > > > > > What needs addressing no matter what IMO is to remove the global > > > variable BeanUtilsBean.BEANS_BY_CLASSLOADER. Even with class loader > > > independence, you can still have multiple libraries and your app > > > competing for setting and using the default. > > > > > > Thoughts? > > > > > > Gary > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- ============================== Melloware melloware...@gmail.com http://melloware.com ==============================
