[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

protected members or explicit abstract classes?

aidy

7/21/2008 9:42:00 AM

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
11 Answers

Sebastian Hungerecker

7/21/2008 9:53:00 AM

0

aidy wrote:
> 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
--
Jabber: sepp2k@jabber.org
ICQ: 205544826

Thomas Wieczorek

7/21/2008 10:17:00 AM

0

On Mon, Jul 21, 2008 at 11:39 AM, aidy <aidy.lewis@googlemail.com> wrote:
> 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/978...).

> 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

--
Fran Lebowitz - "Food is an important part of a balanced diet."

Robert Dober

7/21/2008 12:08:00 PM

0

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

--
http://ruby-smalltalk.blo...

There's no one thing that's true. It's all true.
--
Ernest Hemingway

David A. Black

7/21/2008 12:38:00 PM

0

Hi --

On Mon, 21 Jul 2008, Robert Dober wrote:

> 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.r... for details and updates!

Phlip

7/21/2008 2:01:00 PM

0

aidy wrote:

> 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_ed...

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

--
Dr. Phlip

Robert Dober

7/21/2008 2:23:00 PM

0

On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <dblack@rubypal.com> wrote:
> 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?( :puts ) && 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
--
http://ruby-smalltalk.blo...

There's no one thing that's true. It's all true.
--
Ernest Hemingway

David A. Black

7/21/2008 10:10:00 PM

0

Hi --

On Mon, 21 Jul 2008, Robert Dober wrote:

> On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <dblack@rubypal.com> wrote:
>> 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?( :puts ) && 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.r... for details and updates!

Dean Wampler

7/21/2008 10:29:00 PM

0

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

On Mon, Jul 21, 2008 at 5:09 PM, David A. Black <dblack@rubypal.com> wrote:

> Hi --
>
> On Mon, 21 Jul 2008, Robert Dober wrote:
>
> On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <dblack@rubypal.com>
>> wrote:
>>
>>> 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?
>> ...
>>
> 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....
>

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.object...
http://www.aspectprogr...
http://aquarium.rub...
http://www.cont...

David A. Black

7/21/2008 11:18:00 PM

0

HI --

On Tue, 22 Jul 2008, Dean Wampler wrote:

> On Mon, Jul 21, 2008 at 5:09 PM, David A. Black <dblack@rubypal.com> wrote:
>
>> Hi --
>>
>> On Mon, 21 Jul 2008, Robert Dober wrote:
>>
>> On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <dblack@rubypal.com>
>>> wrote:
>>>
>>>> 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?
>>> ...
>>>
>> 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....
>>
>
> 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.r... for details and updates!

ara.t.howard

7/21/2008 11:40:00 PM

0


On Jul 21, 2008, at 3:39 AM, aidy wrote:

> 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://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama