T
Tim Kuehn
Guest
I'm with Mike on this.... if you let people play with the innards, they will, and then it'll be "your fault" when you change things and their code doesn't work any more... +1 on "package" access too. On Thu, May 28, 2015 at 3:39 PM, Mike Fechner bounce-mikefechner@community.progress.com wrote: AW: Rules for Reflection Invocation Reply by Mike Fechner Hi Laura, I hate to say, but in this case I am more on the Java side than on the .NET side… As a framework vendor, I want to know, that what is defined PRIVATE or PROTECTED cannot be made de facto PUBLIC by using reflection. I do not make code PRIVATE or PROTECTED because I want to hide the functionality from our customers (they get full source code anyway). But especially PRIVATE methods are implementation details that I want to be able to change at a later stage without being worried that my customers get p…. o.. about this. And the experience I have made, that if customers can call something in any way (using reflection) they will use it. Potentially making my life harder when they complain about me changing or removing the method later. For the same reason I need a package level protection option! You can add thousands of comments to a PUBLIC method like: /* This method is public, because another class in the same package needs to call into it for internal reasons that may change at any time without warning, so please don’t use it yourself. */ Regards, Mike Von: Laura Stern [mailto: bounce-stern@community.progress.com ] Gesendet: Donnerstag, 28. Mai 2015 21:14 An: TU.OE.Development@community.progress.com Betreff: [Technical Users - OE Development] Rules for Reflection Invocation Rules for Reflection Invocation Thread created by Laura Stern In the Reflection specification that was posted for the 11.6 ESAP, it states that once you get an instance of one of the reflection objects, such as Progress.Reflect.Method, or Progress.Reflect.Property, you can invoke that method, or get/set the property value from any piece of code. This is different from the methods on Progress.Lang.Class (P.L.C), such as Invoke or SetPropertyValue. For those methods, normal OO rules apply. Only Public class members can be invoked/set/etc from anywhere. You can use these methods on Private class members only from within the class that owns the element and similarly protected class members can only be invoked/set/etc from a class within the hierarchy. The rationale for allowing the functionality from anywhere is to allow tooling to work or to do things like writing your own serialization facility from outside the class that is being serialized. However, we are considering changing the rules for the new Progress.Reflect objects for 11.6. The default would be that you can only do Invoke/New/Get/Set/Subscribe operations on Public data members, period. So this would actually be a little more restrictive than the current rules. In a later release we can add a way to mark elements (details specifically left out) so that Invoke/New/Get/Set/Subscribe will work on them from anywhere. Alternatively, we can keep the rules the way they are spec'd, i.e., everything is allowed from anywhere, and later add a way to restrict access for particular elements. The option to follow the same rules as the current P.L.C methods is not under consideration. Note that .NET takes the latter approach (accessible, unless work is done to make an element secure). Whereas Java follows the approach of being more restrictive by default. We'd appreciate any feedback on this, specifically use-cases that would call for following one approach vs the other. Stop receiving emails on this subject. Flag this post as spam/abuse. Stop receiving emails on this subject. Flag this post as spam/abuse. -- Tim Kuehn: Senior Consultant - TDK Consulting Services President - Ontario PUG Program Committee Chair - PUG Challenge Americas, Course Instructor: Intro to OO Concepts for Procedural Programmers Skype: timothy.kuehn Ph: 519-576-8100 Cell: 519-781-0081
Continue reading...
Continue reading...