protected members or explicit abstract classes?

[aidy]

Hi,

I am reading a book on Java OO.

Could anyone tell me why Ruby does not include protected members nor
explicit abstract classes?

Thank You

Aidy

 

[Sebastian Hungerecker]

Could anyone tell me why Ruby does not include protected members

In ruby all instance variables are protected in the java sense (well, actually
not quite since you can't access them from within another object of the same
class).

nor explicit abstract classes?

Well, I'd say modules qualify as explicitly abstract.

HTH,
Sebastian

 

[Thomas Wieczorek]

Hi,

Heya!

I am reading a book on Java OO.

If you want to read about OO design patterns in Ruby take a look at
"Design Patterns in Ruby" by Russ Olsen
(http://safari.oreilly.com/9780321490452).

explicit abstract classes?

Ruby is an interpreted language. There is no compile time check. AFAIK
if you want to implement something like abstract classes, you can use
the NotImplementedError exception:

class Foo
def bar
throw NotImplementedError.new("Implement me!")
end
end

 

[Robert Dober]

Short answer:
Because Ruby is not Java

Long answer:
Ruby just has a different way approaching object oriented
programming. I believe that it is a more agile
approach, and that abstract classes do not fit into Ruby's paradigm at all.

Very long answer:
As a matter of fact I believe that Ruby should not even have
classes, class and type rhyme too strongly.
I have developed different ways of doing object oriented
development in Ruby (traits, prototypes, pushable behavior) all of
them very slow, unfortunately. I really do not remember when I wanted
an abstract class or a
protected member last when developing in Ruby. I am still guilty of
some code like "if String === s" but I
hopefully one day will replace this with "if s.behaves_like? StringBehavior".
Therefore the quintessence of my reply is, do Ruby, do ducktyping
and ask yourself the question in some
months time from now again!

Cheers
Robert

 

[David A. Black]

Hi --

Short answer:
Because Ruby is not Java

Long answer:
Ruby just has a different way approaching object oriented
programming. I believe that it is a more agile
approach, and that abstract classes do not fit into Ruby's paradigm at all.

Very long answer:
As a matter of fact I believe that Ruby should not even have
classes, class and type rhyme too strongly.
I have developed different ways of doing object oriented
development in Ruby (traits, prototypes, pushable behavior) all of
them very slow, unfortunately. I really do not remember when I wanted
an abstract class or a
protected member last when developing in Ruby. I am still guilty of
some code like "if String === s" but I
hopefully one day will replace this with "if s.behaves_like? StringBehavior".

You could do that with const_missing (I know there's more to it
than that.)

Therefore the quintessence of my reply is, do Ruby, do ducktyping
and ask yourself the question in some
months time from now again!

For true duck typing you would just do:

s.the_method

and live with the consequences


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails July 21-24 Edison, NJ
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!

 

[Phlip]

Could anyone tell me why Ruby does not include protected members nor
explicit abstract classes?

Because Ruby makes unit testing easier than Java does. Tests provide positive
reinforcement that your objects work correctly together. Static type checking
(thru abstract base classes and protected members) only provides negative
reinforcement that your objects might not work correctly together. Then, static
checking impedes unit testing.

http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html

Positive reinforcement always works better - just ask a (non-Behaviorist) shrink.

 

[Robert Dober]

Hi --
For true duck typing you would just do:

s.the_method

In the general case thats seems clumsy to me, I'd rather check if a
protocol is implemented. A very simple example is an IOArray I use to
capture output, it mocks two file methods #puts and #<<.
What would you prefer?

raise Whatever unless o.replies_to?( uts ) && o.replies_to?( :<< )

raise Whatever unless o.implements_behavior? IOArray # but the name is bad

Now imagine the protocol has five or even 10 methods?

Maybe it might also be helpful to recall the definition of duck
typing: "If it walks like a duck and talks like a talk...", this is
about behavior and not about methods.
My journey - that was long and would not have been so productive were
it not for this list - has brought me to search out for new
expressiveness of behavior and I pretty much like traits most right
now. But I am still open to
walk on .


Cheers
Robert

 

[David A. Black]

Hi --

In the general case thats seems clumsy to me, I'd rather check if a
protocol is implemented. A very simple example is an IOArray I use to
capture output, it mocks two file methods #puts and #<<.
What would you prefer?

raise Whatever unless o.replies_to?( uts ) && o.replies_to?( :<< )

raise Whatever unless o.implements_behavior? IOArray # but the name is bad

In general, I'd prefer:

obj.<< # Rescue at this point, not before.

It depends, though. I could imagine a situation where you really don't
want to proceed until you've got at least some assurance that an
object will respond as you want, because you're going to change some
state in another object. I wouldn't like to see everything wrapped up
in response checks.

Now imagine the protocol has five or even 10 methods?

Maybe it might also be helpful to recall the definition of duck
typing: "If it walks like a duck and talks like a talk...", this is
about behavior and not about methods.

Here's the thing, though. It is possible to do this:

obj.some_method

or this:

if obj.respond_to?some_method)
obj.some_method
end

or this:

if obj.is_a?(Thing)
obj.some_method
end

or this:

if obj.implements_behavior?(Stuff)
obj.some_method
end

etc. I've always understood duck typing to mean the first. I've also
described the first as "hard" duck typing and the second as "soft"
duck typing. Rick DeNatale makes a similar distinction between duck
typing and "chicken typing".

But in the end, it's got to be about what each of us likes to write in
our programs. It's not like the one that gets called "duck typing" by
the most people will suddenly be better than all the others in all
circumstances


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails July 21-24 Edison, NJ
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!

 

[Dean Wampler]

[Note: parts of this message were removed to make it a legal post.]

Hi --

On Mon, 21 Jul 2008, Robert Dober wrote:


In the general case thats seems clumsy to me, I'd rather check if a
protocol is implemented. A very simple example is an IOArray I use to
capture output, it mocks two file methods #puts and #<<.
What would you prefer?
...

It depends, though. I could imagine a situation where you really don't
want to proceed until you've got at least some assurance that an
object will respond as you want, because you're going to change some
state in another object. I wouldn't like to see everything wrapped up
in response checks....
[/QUOTE]

I prefer the ruby way; let my automated tests confirm that the required
methods are present when I include a module in another module, where the
included module expects the including module to respond to a set of methods.
Also, the tests document the behavior for the users!

However, here's an idiom you could use to ensure that the methods "exist",
at least at the time one module is included in other. Assume you have:

module A
include B
...
end

and assume that B expects A to respond to "doit". You can override
Module#append_features:

module B
def append_features(including_module)
unless including_module.respond_to?doit)
raise ProtocolViolation.new("#{including_module} must respond to
#doit")
end
super
end
...
end

dean

--
Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

 

[David A. Black]

HI --

I prefer the ruby way;

That's a bit of a conversation-stopper

let my automated tests confirm that the required methods are present
when I include a module in another module, where the included module
expects the including module to respond to a set of methods. Also,
the tests document the behavior for the users!

Sure, no reason not to test everything. I think you may be
misunderstanding my point, though (which certainly wasn't that one
shouldn't write tests I'm very skeptical about the usefulness of
respond_to? in cases where calling the method is going to raise an
error anyway. I guess if it's a matter of this:

raise unless obj.respond_to?meth)
do_something_irreversible
obj.meth # Disaster if we blow up here.

then it makes sense at some level because you can't roll back. But I'm
having trouble thinking of a real example.


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails July 21-24 Edison, NJ
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!

 

[ara.t.howard]

Hi,

I am reading a book on Java OO.

Could anyone tell me why Ruby does not include protected members nor
explicit abstract classes?

Thank You

Aidy

as rubyists, we never protect our members.

a @ http://codeforpeople.com/

 

[Robert Dober]

On Tue, 22 Jul 2008, Dean Wampler wrote:


That's a bit of a conversation-stopper

Oh no problem, I'll teach him Ruby .
That's exactly what I do in my *applications.
However, I really try to be defensive when developing libraries or frameworks.
David put it quite nicely, there are cases where I offer a service to
a user. If it fails with a method missing deep inside the call stack
the user just has to debug my framework or library to understand what
happened (well of course it should be in the docs LOL).
The least I want to tell him is:
Pally, look this thingy of yours you passed into foo does not look
like a bar, sure U know what UR doing?
Now of course she knows exactly what to do .

Again in general I agree, I will not check for protocols or methods in
my standard application, that is what tests (or microtests ) are for.


Cheers
Robert