<div>Daniel,</div><div> </div><div>I think I understand the issue better now.</div><div> </div><div>Not that your idea - how base class provides implementation for reuse</div><div>by subclasses and using packages to specify this protocol - was impossible</div><div>to understand from your first mail.</div><div> </div><div>I see that my doubts and the form of my previous email are caused by the fact that I still</div><div>don't completely understand OOP and classes, despite I use it for years and spent</div><div>some efforts on understanding it.</div><div> </div><div>I understand how the program will be behave when I use this or that language feature;</div><div>I have partially understanding and partially "feeling" about what is right, know common</div><div>patterns how OOP is applied in different situations. But still I don't have a mental model</div><div>which clearly defines all the concepts and fits them together: classes, protocols,</div><div>modularity... how these concepts overlap? what does it mean to "implement a class"?.. <br />what belongs to a class and what does not, and so on.</div><div> </div><div>BTW, I've been constantly thinking for maybe 3 days and made several steps further</div><div>in clarifying my mental model (although open questions remain).</div><div> </div><div>I am taking back my words that public and protected are single protocol - </div><div>I understand the nature of this separation better now.</div><div> </div><div>Minor clarification of the previous mail:</div><div> </div><div>> Taking you literally, we do not need a new CL feature.<br />> But translating what you're saying into the terms<br />> I am using, you're saying that we need only one<br />> protocol, whereas I am saying that it's better<br />> to have two.</div><div> </div><div>Actually I meant that even for Java it could be better to have only package <br />public and package private, as Common Lisp has; without public/private/protected <br />for classes. In your example with the Point class, getX, getY would be <br />package public, and the data members x and y would be package private <br />(and at any time may be changed to an angle and a distance from the origin,<br />without breaking the clients). Maybe in Java it will cause some inconvenience:</div><div>e.g. with single inheritance in some situations reusing implementation</div><div>may require lot of typing if we want to delegate method implementations to an</div><div>"implementation utility" class from other package: void m() {implForReuse.m();}.</div><div>But Java is not the subject here, so we may leave it aside.</div><div> </div><div>The "print" and "to_string" example is illustrative; although the people who relied</div><div>on the fact that the "print" uses "to_string" were relying on an undocumented feature;</div><div>it's their own bug, not the library vendor's. Therefore IMHO the Ada 95 solution is not</div><div>obligatory, I agree that people should expect only documented behaviour to be preserved</div><div>in future versions. But of course, reducing the number of such undocumented entry points into</div><div>the implementation may help them to avoid such bugs.</div><div> </div><div>The ParaSail link is really interesting. BTW, I suppose the idea to plug-in programmer defined</div><div>static checks into compiler is not intrinsically contradicting with the Common Lisp - maybe</div><div>it's possible to implement something in this fashion for Lisp too (with certain limitations, but</div><div>useful in practice). I've been thinking a little about that before (if we can introduce new language</div><div>constructs expanded at compile time, why can't we implement compile time checks); and it's</div><div>interesting to see somebody actually implements it for a language.</div><div> </div><div>To not loose the point of this thread, as I said the idea to use packages to specify protocol</div><div>for subclasses seems right. It's necessary to try it in practice.</div><div> </div><div>Best regards,</div><div>- Anton</div>