http://www.iam.unibe.ch/~scg/Archive/Papers/Scha04bOOEncapsulation.pdf
. this retard thinks Smalltalk and Ruby don’t have private public and
what not. what a joke. This is almost as bad as James McGovern without
the pictures
On Dec 28, 2006, at 16:05, [email protected] wrote:
http://www.iam.unibe.ch/~scg/Archive/Papers/
Scha04bOOEncapsulation.pdf.Ruby [does] not allow a programmer to hide the internal
implementation features (i.e. methods and instance variables) of a
superclass from its subclasses.
I shouldn’t have to demonstrate how ivars are shared between
superclasses and subclasses. For private method sharing with
subclasses:
class X; def y() puts “X#y” end; private :y; end
class Y < X; def z() y() end end
X.new.y # raises NoMethodError: private method `y’ called for #<X:
0x3b766c>
Y.new.z # prints “X#y”
Yup.
In […] Ruby, all instance variables are protected from direct
access from outside the object that contains them.
Yup.
this retard thinks Smalltalk and Ruby don’t have private public and
what not. what a joke. This is almost as bad as James McGovern without
the pictures
After skimming for the Ruby keyword this paper has nothing wrong. I
can’t evaluate the Smalltalk or Python claims, but they look accurate
from my understanding of the two.
This paper seems to be about how dynamic languages’ protections are
not strong enough, and how to make them stronger.
I think the real joke here is you.
–
Eric H. - [email protected] - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
[email protected] wrote:
http://www.iam.unibe.ch/~scg/Archive/Papers/Scha04bOOEncapsulation.pdf
. this retard
There are more civil ways to criticize people than calling them
‘retards.’
One advantage to opting for civility is that more people are more likely
to consider you an informed adult.
–
James B.
“I was born not knowing and have had only a little
time to change that here and there.”
- Richard P. Feynman
Eric H. wrote:
After skimming for the Ruby keyword this paper has nothing wrong. I
can’t evaluate the Smalltalk or Python claims, but they look accurate
from my understanding of the two.
I agree. And I also agree with James, that the OP’s choice of
vocabulary was, shall we say, unfortunate. 
However, if I could change the discussion a little bit, I wonder why
encapsulation from subclasses is so important. Ruby provides decent
protection from client code - usually a prudent use of attr_reader
helps protect instance variables, for example, and I think I read
recently in a future version of Ruby (2.0?) the use of :send to get at
private methods/attributes won’t be possible anymore either.
But, the paper focuses (I admit after just a quick scan) only on the
lack of encapsulation an object can exert against subclasses. That’s
always been a part of my belief system, too, as I grew up on C++ and
later C#… but now I dare wonder aloud, has that really been all that
important?
For example, I used to think static typing was the only way to go,
until I discovered unit tests as a way to stop worrying about my
program’s correctness. So now I wonder if this worry about protection
from subclasses is even worth worrying about.
Maybe the paper’s authors are correct, Python and Ruby don’t do this
kind of encapsulation - but maybe the answer is evident by the
increasing populariy of dynamic languages like Python and Ruby that you
can write great software without needing it such protection anyway?
As I write this, I’m thinking that as soon as I send this message, I’m
going to think of a couple of great examples that will go against this
idea, and then I’ll slap my forehead silly but none of you will hear
it…
Jeff
On Dec 29, 2006, at 2:55 AM, Jeff wrote:
helps protect instance variables, for example, and I think I read
recently in a future version of Ruby (2.0?) the use of :send to get at
private methods/attributes won’t be possible anymore either.
That’s right, though according to the Ruby Cookbook (footnote on page
273) you’ll ve able to accomplish the same with Object#funcall.
– fxn
PS: Indeed, I see that mentioned here as well http://eigenclass.org/
hiki.rb?Changes+in+Ruby+1.9#l22.
As I write this, I’m thinking that as soon as I send this message, I’m
going to think of a couple of great examples that will go against this
idea, and then I’ll slap my forehead silly but none of you will hear
it…
Historians will feverishly refer to this as “The slap heard 'round the
world”. So look out, this might be the beginning of a new revolution
On 29.12.2006 03:33, matt wrote:
As I write this, I’m thinking that as soon as I send this message, I’m
going to think of a couple of great examples that will go against this
idea, and then I’ll slap my forehead silly but none of you will hear
it…Historians will feverishly refer to this as “The slap heard 'round the
world”. So look out, this might be the beginning of a new revolution
What is the sound of one hand slapping? Oh well…
robert
It’s a throwback to the C line of languages.
In Eiffel, for example, there is no real way of hiding methods from
your descendants.
All you can do is ‘freeze’ a particular feature. And that is
deliberate. Inheritance is after all about the ‘is a’ relationship.
There is no real need to hide methods from classes that are essentially
genetically identical to you.
If you want encapsulation use delegatation, not inheritance.
IMHO one of the problems with static languages is that they elevated
the notion of inheritance to a level it was never originally intended
for - system correctness - rather than just a nifty shorthand that
eliminates a bundle of duplication.
NeilW
On 29-Dec-06, at 4:40 AM, Neil W. wrote:
In Eiffel, for example, there is no real way of hiding methods from
your descendants.
Perfect example, you beat me to it 
There is a book, “Object Oriented Software Construction, 2nd Edition”
by Bertrand Meyer, that lays out in convincing detail, why hiding
stuff from descendants is The Wrong Thing To Do. The whole book is a
very convincing argument of how (class based) OO should be
implemented, and at the very least, the issue that all OO programming
languages must address. The closest thing to the language described
in the book is Eiffel, but even that language isn’t a complete
implementation of what is described in the book.
BTW, the argument starts on the first page of chapter two and ends
about 800 pages later. There are no sound-bites – Meyer is making a
strong intellectual effort in this book and it takes some effort on
the part of the reader to understand it. Not that it is hard to read,
it isn’t and it kind of plays out like a mystery book (the first
chapter is a spoiler), but because a belief system is built up step
by step. And, by the way, the book will help you to see other reasons
why Ruby, Smalltalk, and lisp/CLOS are so clever – these languages
don’t solve all of the issues Meyer believes are important or even
crucial, but you can see that they address the issues by deliberately
ignoring them
I have not read the article in question yet, but so far I have not
seen an argument, other than by assertion or the still lamer “C++
does it and so it is right”, that super classes should be protected
from its subclasses.
Wow. There it is… my annual rant, with two days to spare
I’ll read the paper now.
Cheers,
Bob
Bob H. – blogs at <http://www.recursive.ca/
hutch/>
Recursive Design Inc. – http://www.recursive.ca/
Raconteur – http://www.raconteur.info/
xampl for Ruby – http://rubyforge.org/projects/xampl/
On 29.12.2006 10:36, Neil W. wrote:
It’s a throwback to the C line of languages.
In Eiffel, for example, there is no real way of hiding methods from
your descendants.
As a side note: in Java, by marking something “private” you effectively
make it invisible for subclasses; you cannot access private members from
there and consequently they cannot be overridden.
All you can do is ‘freeze’ a particular feature. And that is
deliberate. Inheritance is after all about the ‘is a’ relationship.
There is no real need to hide methods from classes that are essentially
genetically identical to you.
Funny that you should mention Eiffel. Betrand Meyer is one of the guys
who actively advocate implementation inheritance - and that’s why you
can create subclasses of superclasses which do not follow the general
“is a” contract (i.e. are no supertypes of the super class’s type). You
can make methods private (by changing their export status) for example
and thusly change the public interface (and the type).
But - as you said - the choice is always the subclass creator’s. He
explicitly states “Inheritance is the embodiment of the Open-Closed
principle: a mechanism that enables you to pick an existing class,
written yesterday or twenty years ago by you or by someone else, and
discover that you can do something useful with it, far beyond what had
been foreseen by the original design. Letting a class author define what
eventual descendants may or may not use would eliminate this basic
property of inheritance.” [1]
If you want encapsulation use delegatation, not inheritance.
Yuck.
IMHO one of the problems with static languages is that they elevated
the notion of inheritance to a level it was never originally intended
for - system correctness - rather than just a nifty shorthand that
eliminates a bundle of duplication.
I’m not sure I agree 100% here. The “nifty shorthand” is certainly one
part of it (Bertrand Meyer calls it “implementation inheritance”). But
“interface inheritance” (and thus inheritance of the contract)
definitively plays more in the correctness area as it establishes a
relationship between types (namely the subclass or descendant is a
supertype of the ancestor).
Another side note: for everyone interested in concepts of object
orientation OOSC is a very valuable read. Bertrand Meyer covered all
the concepts involved and he is very good at analyzing and separating
out concepts. I always enjoy reading and rereading his book.
Kind regards
robert
[1] section 16.8., OOSC by Betrand Meyer, 2nd ed
Robert K. wrote:
Funny that you should mention Eiffel.
Not if you know my history. I had the very great pleasure of working
with Bertrand about ten years ago on modifications to the Eiffel
language.
Betrand Meyer is one of the guys
who actively advocate implementation inheritance - and that’s why you
can create subclasses of superclasses which do not follow the general
“is a” contract (i.e. are no supertypes of the super class’s type). You
can make methods private (by changing their export status) for example
and thusly change the public interface (and the type).
Only within the rules of the language, which are implemented by the
compiler.
It was effectively ‘system conformance’ that brought the language to
its knees. It was too complex a problem to solve. That and excessive
rigidity.
The idea though was correct. You need flexible shorthand, but within a
set of rules. Eiffel tried to implement that in the compiler. Other
static languages tried to duck the issue, pushing the flexibility out
into XML files.
The solution however is straightforward. You don’t have a static
compiler implementing the rules within the language. You use test and
behaviour driven development and implement a '‘domain specific
compiler’ that implements the rules for your system with a dynamic
language. Some of those tests should be good computer science (don’t
break encapsulation, inherited classes should have contracts that
conform to one another), and others should be the business rules
(moving money between accounts should be atomic).
One you have the idea of a ‘domain specific compiler’, then interface
inheritance is no longer
needed for correct behaviour. That becomes the job of the tests.
Inheritance then becomes a nifty shorthand that helps implement the
Don’t Repeat Yourself principle amongst closely related classes.
Another side note: for everyone interested in concepts of object
orientation OOSC is a very valuable read. Bertrand Meyer covered all
the concepts involved and he is very good at analyzing and separating
out concepts. I always enjoy reading and rereading his book.
Bertrand is an excellent writer, and an even better speaker. OOSC is
well worth reading, and Eiffel is worth studying for its elegance and
its wonderous flaws.
NeilW
On 12/29/06, Robert K. [email protected] wrote:
On 29.12.2006 10:36, Neil W. wrote:
If you want encapsulation use delegatation, not inheritance.
Yuck.
Why do you say yuck?
Jeff wrote:
For example, I used to think static typing was the only way to go,
until I discovered unit tests as a way to stop worrying about my
program’s correctness. So now I wonder if this worry about protection
from subclasses is even worth worrying about.
I would say “no”.
Maybe the paper’s authors are correct, Python and Ruby don’t do this
kind of encapsulation - but maybe the answer is evident by the
increasing populariy of dynamic languages like Python and Ruby that you
can write great software without needing it such protection anyway?
You can. The fact that there’s no call for it among the dynamic
language community, and the fact that it was actively rejected by at
least one (Self) ought to be a Big Clue that this is a solution in
search of a problem.
BTW, Scharli and Black are part of the team who came up with Traits
(aka Roles).
Regards,
Dan
On 30.12.2006 18:23, Pat M. wrote:
On 12/29/06, Robert K. [email protected] wrote:
On 29.12.2006 10:36, Neil W. wrote:
If you want encapsulation use delegatation, not inheritance.
Yuck.
Why do you say yuck?
Because I had the meaning of “yuck” wrong. I probably should have
stuck with the non colloquial “yes”. Sorry for the confusion - this
seems to happen to me once in a while…
Happy new Year!
robert