Re: [Jython-dev] bean names and get/set

[Jeff A. <ja...@fa...>]

Roger:

I gave this a pause to see if anyone with longer history in Jython would 
chip in.

Under JavaBeans conventions, property names start with a lower case 
letter (see 
https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), 
and that tends to be the case in Python. Sure, the getter and setters 
are getLength and setLength, but the property is called "length". So 
making it "x.Length" is not a question of *preserving* the case, but of 
using a non-Java convention while exposing them to Python.

I don't know C#, but you've explained that C# names its properties with 
an initial upper case, and the default exposure in IronPython of a C# 
class leaves that as it is. You have code you want to run in both 
interpreters that gives an interpretation to x.Length when x is a C# 
object of class X, and you want the same interpretation to be given 
y.length when y is a JavaBean of type Y (or maybe any Java object of 
class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean 
compatible things?". (He would ask the same about X.a and Y.a if the 
identically named member 'a' were not the attribute of a common base or 
interface.) And the Pythonist would probably reply something about duck 
typing. Duck-typing always poses risks to correctness: it's an 
assumption that length (or write, etc.) means the same thing on several 
unrelated classes. But the motivation for Jython to take the risk with 
the well-established JavaBeans convention is clear.

I think what you're asking is: please provide a way to interpret in 
Jython, the interface offered by Java objects, that makes them 
name-similar to C# objects wrapped by IronPython, assuming similar names 
mean the same thing.

If that's a fair summary, I'm doubtful that's a thing one ought to bake 
into the Jython interpreter. I can see practical difficulties too, since 
exposure gets done once after installation, and the cached exposure is 
used globally, affecting the names seen by code you didn't write. If 
this has to be done by tagging-up (the wrapped version of) those Java 
classes and methods, more or less individually crafted, could the same 
not be achieved by wrappers (probably decorators) at the Python level, 
in a distinct library/utility, used just where needed?

Jeff Allen

On 07/03/2017 12:12, Sommers, Roger wrote:
>
> 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:* jyt...@li...
> *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
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev