Re: bean names and get/set

Hi again,

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

Eg:

PyPreservePropertyCaseTag                 - getShape() generates readable property "Shape" instead of "shape"
PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called "orCreateWidget"
PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

Thanks again

-Roger.


From: Sommers, Roger
Sent: 07 March 2017 11:47
To: [email protected]
Subject: [Jython-dev] bean names and get/set

Hi Jython developers,

First off, thanks for your hard work developing Jython! I'm particularly impressed with how easy it is to get working with an existing jar.

I was wondering if you would consider a feature request or two:


1.     to optionally preserve the case of bean names (eg getShape() -> property/bean "Shape" instead of "shape"). Something like python.options.preserveBeanNames = true (default false of course).

2.     To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won't run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can't stop them using the get/set methods without enhancement #2.

Many thanks for your time
-Roger.

(C++, Java, C# and python developer)

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev