Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > protected members or explicit abstract classes?

Reply
Thread Tools

protected members or explicit abstract classes?

 
 
aidy
Guest
Posts: n/a
 
      07-21-2008
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
 
Reply With Quote
 
 
 
 
Sebastian Hungerecker
Guest
Posts: n/a
 
      07-21-2008
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: http://www.velocityreviews.com/forums/(E-Mail Removed)
ICQ: 205544826

 
Reply With Quote
 
 
 
 
Thomas Wieczorek
Guest
Posts: n/a
 
      07-21-2008
On Mon, Jul 21, 2008 at 11:39 AM, aidy <(E-Mail Removed)> 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/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

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

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      07-21-2008
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.blogspot.com/

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

 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      07-21-2008
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.rubypal.com for details and updates!

 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      07-21-2008
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/blo...s_editors.html

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

--
Dr. Phlip
 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      07-21-2008
On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <(E-Mail Removed)> 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?( 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
--
http://ruby-smalltalk.blogspot.com/

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

 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      07-21-2008
Hi --

On Mon, 21 Jul 2008, Robert Dober wrote:

> On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <(E-Mail Removed)> 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?( 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!

 
Reply With Quote
 
Dean Wampler
Guest
Posts: n/a
 
      07-21-2008
[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 <(E-Mail Removed)> wrote:

> Hi --
>
> On Mon, 21 Jul 2008, Robert Dober wrote:
>
> On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <(E-Mail Removed)>
>> 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.objectmentor.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      07-21-2008
HI --

On Tue, 22 Jul 2008, Dean Wampler wrote:

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
comparison of protected members vs abstract classes Sideswipe Java 6 09-20-2007 09:55 PM
Explicit instantiation of STL vector demands explicit instantiation of all the templates it using internally. krunalbauskar@gmail.com C++ 1 12-25-2006 03:51 PM
Protected static members, abstract classes, object composition vs. subclassing Kevin Prichard Javascript 11 11-29-2005 01:33 AM
What's the difference betwwen explicit instantiaion and explicit specialization? Andy C++ 5 01-30-2005 11:46 PM
Is explicit template qualification required for explicit delete? J.T. Conklin C++ 1 08-11-2004 02:06 AM



Advertisments