Menu
▾
▴
Re: [Jython-dev] bean names and get/set
|
From: Sommers, R. <Rog...@co...> - 2017-03-09 09:53:24
|
Hi Jeff, thanks for the reply. Some comments are inline. From: Jeff Allen [mailto:ja...@fa...] Sent: 09 March 2017 08:26 To: Sommers, Roger Cc: jyt...@li... Subject: Re: [Jython-dev] bean names and get/set 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. Sure. I used the word preserving because I wanted to distinguish between "use the name as-is without the get/set" and "force uppercase letter". I appreciate the reasons why it is done the way it is, and following the bean convention is a perfectly sensible choice. I am merely suggesting an option to allow Java developers more control over what the Jython interface to their library looks like. For example, they might decide to use lower-case properties for read-only values, who knows. The use case for me happens to be closer alignment with C# conventions. 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. Understood. I used "length" as an example, but in my particular instance I do in fact generate the jar and assembly (it is our own code), and I know the properties mean the same thing in both. In theory I could just add the lower case version to the C# (ie, have both upper and lower), in fact this would be easy because it's generated code. But I would rather not have two setters and getters for each property. 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. That is precisely it. Perhaps my case is a little unusual in that I am using both IronPython and Jython to (conceptually) wrap the same library. You might ask why; the answer is that there is some demand for Excel integration, which IronPython is good at, but we also want to provide python support for linux and unix-based users. We are at the early stages of python adoption, and not much python code has been written yet. Before people go off and write loads of scripts using one implementation, I am trying to take steps to ensure that what they write can (largely) be used in the other. Where the language semantics differ (eg Streams vs Readers), I have provided a utils module that hides such differences, but the object library, which forms the vast bulk of the interface, can be brought into close alignment with these enhancements. 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. I'm not sure I understand this point. I am not suggesting we change the default behaviour, the only thing I am looking to bake in is more flexibility :-). 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? Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need. The tagged exception idea in Jython works well and is a clever idea, but there is only one example of its use at the moment - to completely ignore a method. I am suggesting more uses of it to give those deploying Jython to users more flexibility over the Jython interface to their libraries. Thanks again for your time and for your considered reply, much appreciated! -Roger. 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...<mailto: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...<mailto:Jyt...@li...> https://lists.sourceforge.net/lists/listinfo/jython-dev |
