Smalltalk › Cincom › VisualWorks

VM Support for private/protected methods

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

thomas.hawker

VM Support for private/protected methods

Has anyone ever looked at what it would take to implement and enforce private/protected methods at the VM level? Yes, I can see that there would be a performance impact, which I imagine can be minimized for public methods (no restrictions). It would seem that you’re going to need some kind of native method caching support because the legal callers of a protected method would be the subclasses of a receiver’s class, regardless of the mclass of the method doing the send, and you wouldn’t want to compute that every time around. Lastly, the VM would need to introduce a new error message sends (like “doesNotUnderstand:”) in order to deal with the access irregularity.

(Of course, specifying that methods are private or protected is a bit more complicated, and then there are the extensions for reflection and such. Let’s skip that for now.)

Cheers!

Tom Hawker
Senior Framework Developer
Home	+1 (408) 274-4128	The Environment: *We take it personally*
Office	+1 (408) 576-6591
Mobile	+1 (408) 835-3643

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andres Valloud-6

Re: VM Support for private/protected methods

I assume you mean that private / protected methods can only have self / super receivers. If that is the case, then it seems to me one could possibly change how lookup is performed so that, in addition to finding the method, the receiver must be isKindOf: the mclass of the method found. The need for this additional check could be specified somehow in the compiled method, perhaps a bytecode prefix or something like that. If the test fails, the receiver would receive something like "shouldNotReceive: aMessage" (although it seems to me the fault is the context's rather than the receiver... maybe thisContext should receive "shouldNotSend: aMessage", I don't know). In any case, as soon as the lookup is performed and the method is found and it is deemed suitable for execution in the context of the current send site, then the method lookup can be cached like any other message send. Thus, I'd expect the runtime performance penalty to be close to negligible modulo some operations along the lines of become: which may require additional care to void cached lookups. I don't know if this would work, but it's basically what I'd look at first.

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, February 23, 2010 4:22 PM
To: [hidden email]
Subject: [vwnc] VM Support for private/protected methods

(Of course, specifying that methods are private or protected is a bit more complicated, and then there are the extensions for reflection and such. Let’s skip that for now.)

Cheers!

Tom Hawker
Senior Framework Developer
Home	+1 (408) 274-4128	The Environment: *We take it personally*
Office	+1 (408) 576-6591
Mobile	+1 (408) 835-3643

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Eliot Miranda-2

Re: VM Support for private/protected methods

In reply to this post by thomas.hawker

On Tue, Feb 23, 2010 at 4:22 PM, <[hidden email]> wrote:

Has anyone ever looked at what it would take to implement and enforce private/protected methods at the VM level? Yes, I can see that there would be a performance impact, which I imagine can be minimized for public methods (no restrictions). It would seem that you’re going to need some kind of native method caching support because the legal callers of a protected method would be the subclasses of a receiver’s class, regardless of the mclass of the method doing the send, and you wouldn’t want to compute that every time around. Lastly, the VM would need to introduce a new error message sends (like “doesNotUnderstand:”) in order to deal with the access irregularity.

(Of course, specifying that methods are private or protected is a bit more complicated, and then there are the extensions for reflection and such. Let’s skip that for now.)

What you need is a semantics. What is a private send, a send to "self", a send to "here" or a send to an object that just happens to be == self? What is a protected send? Gild Bracha has written a few papers on privacy, e.g. in Newspeak. I did a hacky proposal for an OOPSLA workshop a while ago.

In any case starting off with an implementation and working towards a semantics is doomed to a C++-like incomprehensibility. So go google for papers on privacy in dynamic OO languages and then come back with a proposed semantics. After that, implementation is the easy part. e.g. inline caches and lookup policies can be married so that checks are only made the first time a given object sends to another.

Cheers!

Tom Hawker
Senior Framework Developer
Home	+1 (408) 274-4128	The Environment: *We take it personally*
Office	+1 (408) 576-6591
Mobile	+1 (408) 835-3643

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

stephane ducasse-2

Re: VM Support for private/protected methods

+10

in ruby private are virtual and can be overridden. in Java they are statically bound.
Is a self send different from an object send?
....
Read our OOPSLA 2004 Encapsulation paper to see that making self send a different expression than an object send is the best solution to hook something in a dynamically typed language.

> What you need is a semantics. What is a private send, a send to "self", a send to "here" or a send to an object that just happens to be == self? What is a protected send? Gild Bracha has written a few papers on privacy, e.g. in Newspeak. I did a hacky proposal for an OOPSLA workshop a while ago.
>
> In any case starting off with an implementation and working towards a semantics is doomed to a C++-like incomprehensibility. So go google for papers on privacy in dynamic OO languages and then come back with a proposed semantics. After that, implementation is the easy part. e.g. inline caches and lookup policies can be married so that checks are only made the first time a given object sends to another.
>
> Cheers!

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Konstantin Haase

Re: VM Support for private/protected methods

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 24, 2010, at 07:58 , stephane ducasse wrote:

> +10
>
> in ruby private are virtual and can be overridden. in Java they are statically bound.
> Is a self send different from an object send?
>

Also, in ruby private can be circumvented by send (ruby's equivalent to perform:). It should probably be possible to implement ruby-like private methods above VM level. However, those would not offer as much "protection" as java's private methods.

Konstantin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iQEcBAEBAgAGBQJLhNvlAAoJEChfnI36xlqRu80IAIwhmJ29eDAteUEk6HOHGu05
3bLeonAsIBzIdfUcVLIrw1N2XAsvKvidnAEUl0tlPzEjTUGkEq63Iv+7QUCmMDgV
hWQa+MW1i05IZy9558eTaUvMq/uOpmJmNcle7Bey/kp1KeOFPqsAC917d8CVpLWD
dTyIQMa6G4qCX6ym/LaKvEMf6UNG0WlNMk5k0Kjjk6qQghs+ls2DMmA5IBAqXYYh
lWl4ZMEq+S+zcEQBYuteWIwBQsppx9RNyu5fCDxiYRfcqS9oAik/KLcY4KkaXmoL
ixHAb0qHI6FgQaWCNT8i5gOozINlVxhpDPEXqWFyyopyFw0CYKpDS4RZNtOjCJY=
=jH1x
-----END PGP SIGNATURE-----

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

stephane ducasse-2

Re: VM Support for private/protected methods

BTW I do not think that you want private methods but protected
because else you do not need inheritance either :)

Stef
On Feb 24, 2010, at 8:57 AM, Konstantin Haase wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Feb 24, 2010, at 07:58 , stephane ducasse wrote:
>
>> +10
>>
>> in ruby private are virtual and can be overridden. in Java they are statically bound.
>> Is a self send different from an object send?
>>
>
> Also, in ruby private can be circumvented by send (ruby's equivalent to perform:). It should probably be possible to implement ruby-like private methods above VM level. However, those would not offer as much "protection" as java's private methods.
>
> Konstantin
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
>
> iQEcBAEBAgAGBQJLhNvlAAoJEChfnI36xlqRu80IAIwhmJ29eDAteUEk6HOHGu05
> 3bLeonAsIBzIdfUcVLIrw1N2XAsvKvidnAEUl0tlPzEjTUGkEq63Iv+7QUCmMDgV
> hWQa+MW1i05IZy9558eTaUvMq/uOpmJmNcle7Bey/kp1KeOFPqsAC917d8CVpLWD
> dTyIQMa6G4qCX6ym/LaKvEMf6UNG0WlNMk5k0Kjjk6qQghs+ls2DMmA5IBAqXYYh
> lWl4ZMEq+S+zcEQBYuteWIwBQsppx9RNyu5fCDxiYRfcqS9oAik/KLcY4KkaXmoL
> ixHAb0qHI6FgQaWCNT8i5gOozINlVxhpDPEXqWFyyopyFw0CYKpDS4RZNtOjCJY=
> =jH1x
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Michel Tilman

Re: VM Support for private/protected methods

In reply to this post by Konstantin Haase

Actually, in java you can also access private methods through reflection, so it does not offer that much "protection" either if you really want to. On the other hand, over-"enthousiastic" use of private, final and all that stuff have forced me too many times to resort to what is essentially copy-paste. It seems to me that several java developers I worked with had never read papers about e.g. software evolving from white-box reuse to black-box reuse.

michel

Also, in ruby private can be circumvented by send (ruby's equivalent to perform:). It should probably be possible to implement ruby-like private methods above VM level. However, those would not offer as much "protection" as java's private methods.

Konstantin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

davidbuck

Re: VM Support for private/protected methods

For reasons like this, I question the use of enforced private methods. What are you trying to accomplish?

If you're trying to prevent someone from maliciously mis-using your object, then you'll never succeed. They can always do things like dynamically adding new methods to your method dictionary, calling instAt:put: and so forth to mess with your object or simply adding an extension method to your class. If it's security you're after, you're facing a spy-vs-spy losing battle so long as you are in the same memory space.

Most likely, you are trying to convey your intent to other developers. In that case, what benefit would it be to mark the method as private rather than adding a method comment saying "PRIVATE - you should use this other technique instead..."? The private marking puts the original developer in a position of dictating the design constraints on all later developers. Put yourself into the position of a developer who feels that he needs to call a private method. What do you do? If you can see a hint that it's private, you'll likely try to find a better way to accomplish what you want. If there's no other way, then your options are to change the private method to a public method or try to circumvent the private in some way like copying the code. In the end, you've accomplished nothing by enforcing the private calls.

If you still feel that you must have private methods, put a call to "self private" at the start of the private method. The "private" method would just return self (minimal impact on performance) but later allows you to change the implementation of private to check the slow way whether the rules are being followed. This code could be run occasionally to check the rules in a development environment to see who's breaking the rules.

David Buck

Michel Tilman wrote:

Actually, in java you can also access private methods through reflection, so it does not offer that much "protection" either if you really want to. On the other hand, over-"enthousiastic" use of private, final and all that stuff have forced me too many times to resort to what is essentially copy-paste. It seems to me that several java developers I worked with had never read papers about e.g. software evolving from white-box reuse to black-box reuse.

michel

Also, in ruby private can be circumvented by send (ruby's equivalent to perform:). It should probably be possible to implement ruby-like private methods above VM level. However, those would not offer as much "protection" as java's private methods.

Konstantin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.733 / Virus Database: 271.1.1/2705 - Release Date: 02/23/10 02:34:00

  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight-2

Re: VM Support for private/protected methods

In reply to this post by Michel Tilman

And in C++ and Java, private means private to the class, not private to the object. So
someObject privateMessage
can be sent as long as the senders is an instance of the same class as someObject, it doesn't have to be someObject itself. This is often confusing to people coming from dynamic languages.

At 03:51 AM 2010-02-24, Michel Tilman wrote:

Actually, in java you can also access private methods through reflection, so it does not offer that much "protection" either if you really want to. On the other hand, over-"enthousiastic" use of private, final and all that stuff have forced me too many times to resort to what is essentially copy-paste. It seems to me that several java developers I worked with had never read papers about e.g. software evolving from white-box reuse to black-box reuse.

michel

Also, in ruby private can be circumvented by send (ruby's equivalent to perform:). It should probably be possible to implement ruby-like private methods above VM level. However, those would not offer as much "protection" as java's private methods.

Konstantin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc