So at the end, I did this (quoting the commit message): Renamed some ZeroArgumentNonVoidMethodPolicy-es to reflect the meaning more precisely (on the expense of having really long enum names): - BOTH_PROPERTY_AND_METHOD to BOTH_METHOD_AND_PROPERTY_UNLESS_BEAN_PROPERTY_READ_METHOD - PROPERTY_ONLY to PROPERTY_ONLY_UNLESS_BEAN_PROPERTY_READ_METHOD This way it's now also true that the ZeroArgumentNonVoidMethodPolicy just specifies "How to show 0 argument non-void public methods to templates", as now all the exceptions related to Java Beans are described for the enum values.
On Sun, Apr 21, 2024 at 4:51 AM Simon Hartley <scrhart...@yahoo.co.uk.invalid> wrote: > I don't know if it makes sense given the method fine tuning stuff, but > here are two approaches: > 1. First choose which methods are exposed and then choose how they can be > accessed in the template, > i.e. which ones are "properties" (i.e. hash items) > 2. First determine what methods we are going to treat as properties and > then do exposure afterwards (methods and/or properties) > > Would it be clearer to rename in ZeroArgumentNonVoidMethodPolicy > so BOTH_PROPERTY_AND_METHOD becomes BOTH_HASH_ITEM_AND_METHOD ? > > For exposureLevel, we could choose to split it by adding > recordExposureLevel (defaulting to USE_DEFAULT or UNSET, with a value of > e.g. -1), > rather than adding a million variations to the existing exposureLevel > flags. > > Cheers, > Simon > > > > > On Sunday, 14 April 2024 at 12:43:50 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > There's no "EXPOSE" variant for that, at the moment. We had to add > something like EXPOSE_PROPERTIES_ONLY_EXCEPT_FOR_RECORDS_AND_VALUE_TYPES, > though with a less comical and more future-proof name. > > On Sun, Apr 14, 2024 at 12:29 PM Simon Hartley > <scrhart...@yahoo.co.uk.invalid> wrote: > > > > I experimented with setting: > > exposureLevel=freemarker.ext.beans.BeansWrapper.EXPOSE_PROPERTIES_ONLY > > > > This seems to prevent records from using anything but the bean > properties, > > so the components in the record don't get exposed as hash items. > > Is there some equivalent so that I could have beans act just as beans > > and records act just (more or less) as records (at least as a plan for > the future)? > > Or to filter out methods which don't conform to > ZeroArgumentNonVoidMethodPolicy (plus indexed methods)? > > > > Cheers, > > Simon > > > > > > > > > > On Thursday, 11 April 2024 at 09:42:02 BST, Daniel Dekany < > daniel.dek...@gmail.com> wrote: > > > > > > > > > > > > > So what I plant to do is renaming things to something like these > > > (suggestion for better names are welcome): > > > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_METHOD > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY > > > > ZeroArgumentNonVoidMethodPolicy.BEAN_AWARE_THEN_EXPOSE_AS_PROPERTY_AND_METHOD > > > > > > And then maybe I would also add policies where we don't care about > > > bean stuff, as it should be in theory with records. I don't think many > > > user will want such a purist approach, but it can be useful in > > > ensuring that our implementation is sound (because then it should be > > > possible to implement such a policy). > > > > -- > Best regards, > > Daniel Dekany > -- Best regards, Daniel Dekany
