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
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
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
···
On Mon, Jul 21, 2008 at 11:39 AM, aidy <aidy.lewis@googlemail.com> wrote:
--
Fran Lebowitz - "Food is an important part of a balanced diet."
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
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.
Positive reinforcement always works better - just ask a (non-Behaviorist) shrink.
···
--
Dr. Phlip
as rubyists, we never protect our members.
···
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
--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama
Hi --
Short answer:
Because Ruby is not JavaLong 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
···
On Mon, 21 Jul 2008, Robert Dober wrote:
--
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!
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
···
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
--
http://ruby-smalltalk.blogspot.com/
There's no one thing that's true. It's all true.
--
Ernest Hemingway
Hi --
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
···
On Mon, 21 Jul 2008, Robert Dober wrote:
On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <dblack@rubypal.com> wrote:
--
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!
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
···
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....
--
Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org
HI --
Hi --
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
···
On Tue, 22 Jul 2008, Dean Wampler wrote:
On Mon, Jul 21, 2008 at 5:09 PM, David A. Black <dblack@rubypal.com> wrote:
On Mon, 21 Jul 2008, Robert Dober wrote:
On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <dblack@rubypal.com> >>> wrote:
--
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!
I prefer the ruby way;
That's a bit of a conversation-stopper
Oh no problem, I'll teach him Ruby ;).
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!
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
···
On Tue, 22 Jul 2008, Dean Wampler wrote: