Forum: Ruby What we have here is a retard pretending to be a computer sc

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B7cef3e53482e9ef168a4fc49fd5d96d?d=identicon&s=25 unknown (Guest)
on 2006-12-29 01:06
(Received via mailing list)
http://www.iam.unibe.ch/~scg/Archive/Papers/Scha04...
. 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
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-12-29 01:46
(Received via mailing list)
On Dec 28, 2006, at 16:05, atbusbook@aol.com 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 Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2006-12-29 02:16
(Received via mailing list)
atbusbook@aol.com wrote:
> http://www.iam.unibe.ch/~scg/Archive/Papers/Scha04...
> . 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 Britt

"I was born not knowing and have had only a little
  time to change that here and there."
  - Richard P. Feynman
8217faf2bfdfa7daf10135d41ddd421e?d=identicon&s=25 Jeff Cohen (jeff)
on 2006-12-29 02:56
(Received via mailing list)
Eric Hodel 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
6329e9ce6b0c23f8bcf64a6c46a2bb81?d=identicon&s=25 matt (Guest)
on 2006-12-29 03:34
(Received via mailing list)
> 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 :)
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2006-12-29 03:54
(Received via mailing list)
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.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-12-29 10:25
(Received via mailing list)
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

;-)
A84d51d60791f8e0fb6d27a8a8b2a96e?d=identicon&s=25 Neil Wilson (neilw)
on 2006-12-29 10:41
(Received via mailing list)
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
E3c79c779c0b390049289cdfe7cb9705?d=identicon&s=25 Bob Hutchison (Guest)
on 2006-12-29 12:41
(Received via mailing list)
On 29-Dec-06, at 4:40 AM, Neil Wilson 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 Hutchison                  -- 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/>
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-12-29 16:20
(Received via mailing list)
On 29.12.2006 10:36, Neil Wilson 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
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (Guest)
on 2006-12-29 20:21
(Received via mailing list)
Jeff wrote:

<snip>

> 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
A84d51d60791f8e0fb6d27a8a8b2a96e?d=identicon&s=25 Neil Wilson (neilw)
on 2006-12-30 10:51
(Received via mailing list)
Robert Klemme 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
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-12-30 18:24
(Received via mailing list)
On 12/29/06, Robert Klemme <shortcutter@googlemail.com> wrote:
> On 29.12.2006 10:36, Neil Wilson wrote:
> > If you want encapsulation use delegatation, not inheritance.
>
> Yuck.

Why do you say yuck?
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-12-31 14:30
(Received via mailing list)
On 30.12.2006 18:23, Pat Maddox wrote:
> On 12/29/06, Robert Klemme <shortcutter@googlemail.com> wrote:
>> On 29.12.2006 10:36, Neil Wilson 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
This topic is locked and can not be replied to.