<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Takuro,</div><div><br></div><div>I'm not sure myself why public and private were dropped; maybe someone else on the list can help out. Jecel seems to be the resident Self historian?</div><div><br></div><div>Self, at least at the moment, doesn't care much about security. For example, mirrors can easily be obtained on almost any object. If you can get a mirror, there is little you can't do with an object.</div><div><br></div><div>I'm not sure, however, that Self style delegation is of itself a security problem. I can see how it *would* be if there were still private and public slots - inheriting from an object would be a way to access its private slots.</div><div><br></div><div>But since Self doesn't have private slots, there wouldn't seem to be much that an inheriting object could do that a normal object couldn't.</div><div><br></div><div>Take a BankAccount object for example:</div><div><br></div><div>(| total <- 0. </div><div> deposit: x = (total: total + x). </div><div> withdraw: x = (x < total ifTrue: [total: total - x]) </div><div>|)</div><div><br></div><div>Sure I could inherit from it and send messages to myself that would affect it; but I could also just send it the message "total: 1000000" for instant wealth :)</div><div><br></div><div>Some security could be obtained by renaming the 'total' slot something unguessable; but the feature of Self that breaks that isn't inheritance but getting a mirror on the object to see what the slots are named.</div><div><br></div><div>Maybe if private slots were reintroduced then restrictions on who can inherit from an object would need to be introduced as well. </div><div><br></div><div>- Russell</div><div><br></div><br><div><div>On 16/12/2009, at 4:28 PM, takuro ikejiri wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: #fff;">
<span style="display:none"> </span>
<div id="ygrp-text"><p>Hi all,<br>
<br>
I am a university student and interested in prototype-base language.<br>
I have a question:<br>
<br>
<a href="http://research.sun.com/self/release_4.0/Self-4.0/Tutorial/Language/FinishingTouches/FinishingTouches.html">http://research.<wbr>sun.com/self/<wbr>release_4.<wbr>0/Self-4.<wbr>0/Tutorial/<wbr>Language/<wbr>FinishingTouches<wbr>/FinishingTouche<wbr>s.html</a><br>
<br>
according to this page,<br>
"The distinction between public and private is purely for documentation.<br>
Earlier versions of Self enforced privacy (allowing only sends to self<br>
to locate private slots) but this scheme was found to be unworkable."<br>
<br>
My question is "what is unworkable about Self encapsulation ?".<br>
<br>
I also read a paper ( parents are shared parts of objects:<br>
Inheritance and encapsulation in SELF,1991),<br>
and learned about inheritance-<wbr>based encapsulation.<br>
I think this approach is not good because an encapsulated module<br>
cannot prohibit access from outside<br>
(because an object gain access to the module by becoming a child of<br>
the module).<br>
<br>
I'd appreciate it if you could answer this question.<br>
Thanks in advance.<br>
</p>
</div>
</div>
<!-- end group email -->
</blockquote></div><br></body></html>