Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > abstract superclasses

Reply
Thread Tools

abstract superclasses

 
 
Giles Bowkett
Guest
Posts: n/a
 
      10-17-2007
I sometimes use the Java thing of an abstract superclass in Ruby. I
usually just set up the abstract parent so that it'll break if used
directly. Is it better to just use Modules? Have other people run into
this?

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/

 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      10-17-2007
On 17.10.2007 21:22, Giles Bowkett wrote:
> I sometimes use the Java thing of an abstract superclass in Ruby. I
> usually just set up the abstract parent so that it'll break if used
> directly. Is it better to just use Modules? Have other people run into
> this?


Why bother? If your "abstract" class requires a method to be present
then just not defining it works pretty well - in modules as well as in
classes:

irb(main):001:0> o=Object.new.extend Enumerable
=> #<Object:0x1001a92c>
irb(main):002:0> o.map {|y| y.to_i}
NoMethodError: undefined method `each' for #<Object:0x1001a92c>
from (irb):3:in `map'
from (irb):3
from :0
irb(main):003:0>

Of course you need some documentation about the missing method - that
would probably be the only reason why I'd add a dysfunctional definition
of that method...

Kind regards

robert
 
Reply With Quote
 
 
 
 
Thomas Adam
Guest
Posts: n/a
 
      10-17-2007
On 17/10/2007, Giles Bowkett <(E-Mail Removed)> wrote:
> I sometimes use the Java thing of an abstract superclass in Ruby. I
> usually just set up the abstract parent so that it'll break if used
> directly. Is it better to just use Modules? Have other people run into
> this?


I'd use a Module, yes. Or a class:

class SomeClassMimickingAbstract
private_class_method :new
end

But you don't need to think this way in Ruby -- unlike Java, Ruby is
weakly typed.

-- Thomas Adam

 
Reply With Quote
 
Yossef Mendelssohn
Guest
Posts: n/a
 
      10-18-2007
]On Oct 17, 2:41 pm, "Thomas Adam" <(E-Mail Removed)> wrote:
> On 17/10/2007, Giles Bowkett <(E-Mail Removed)> wrote:
>
> > I sometimes use the Java thing of an abstract superclass in Ruby. I
> > usually just set up the abstract parent so that it'll break if used
> > directly. Is it better to just use Modules? Have other people run into
> > this?

>
> I'd use a Module, yes. Or a class:
>
> class SomeClassMimickingAbstract
> private_class_method :new
> end
>
> But you don't need to think this way in Ruby -- unlike Java, Ruby is
> weakly typed.
>
> -- Thomas Adam


How do you suggest to use that class? I understanding keeping the
"abstract" class from being instantiated, but what about the concrete
classes, the ones you're going to use?

class RealThing < SomeClassMimickingAbstract
# now make .new public again
end

Ugly, isn't it? Of course, that's just more fuel for the "don't do
this in Ruby" fire.

--
-yossef


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      10-18-2007
Hi --

On Thu, 18 Oct 2007, Yossef Mendelssohn wrote:

> ]On Oct 17, 2:41 pm, "Thomas Adam" <(E-Mail Removed)> wrote:
>> On 17/10/2007, Giles Bowkett <(E-Mail Removed)> wrote:
>>
>>> I sometimes use the Java thing of an abstract superclass in Ruby. I
>>> usually just set up the abstract parent so that it'll break if used
>>> directly. Is it better to just use Modules? Have other people run into
>>> this?

>>
>> I'd use a Module, yes. Or a class:
>>
>> class SomeClassMimickingAbstract
>> private_class_method :new
>> end
>>
>> But you don't need to think this way in Ruby -- unlike Java, Ruby is
>> weakly typed.
>>
>> -- Thomas Adam

>
> How do you suggest to use that class? I understanding keeping the
> "abstract" class from being instantiated, but what about the concrete
> classes, the ones you're going to use?
>
> class RealThing < SomeClassMimickingAbstract
> # now make .new public again
> end
>
> Ugly, isn't it? Of course, that's just more fuel for the "don't do
> this in Ruby" fire.


You could do:

class C
private_class_method :new
def self.inherited(c)
class << c; public :new; end
end
end

I've actually never felt the need for abstract classes in Ruby
programs. I'm not a Java programmer, so it never would have occurred
to me in that context, and I haven't found myself inventing it for
Ruby.


David

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!

 
Reply With Quote
 
Rick DeNatale
Guest
Posts: n/a
 
      10-18-2007
On 10/17/07, David A. Black <(E-Mail Removed)> wrote:

>
> I've actually never felt the need for abstract classes in Ruby
> programs. I'm not a Java programmer, so it never would have occurred
> to me in that context, and I haven't found myself inventing it for
> Ruby.


Note that ActiveRecord has a slightly different spin on the notion of
abstract class.

ActiveRecord::Base has a rw attribute called abstract_class and an
abstract_class? predicate method.

ActiveRecord::Base subclasses can be 'set' as abstract the meaning is
that such classes don't have a corresponding database table. They are
used as intermediate superclasses, typically to let a set of AR
classes to inherit a common database connection different from other
AR classes in the same application.


--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

 
Reply With Quote
 
Giles Bowkett
Guest
Posts: n/a
 
      10-18-2007
It is a Java thing; it comes from "Refactoring," I think, the Martin
Fowler book. The idea is you handle excessive if/else/etc. statements
by creating classes and putting the different code branches in
subclasses. Since you'll have pieces which don't need to be different
in the subclasses, you keep those pieces in the superclass so you have
them in one place.

In practice I usually do the unimplemented method thing, so that
misusing the code just makes things blow up. The method hiding and
revealing is probably overkill, although if you extract it into a
module, you can have an AbstractSuperclass module pretty easily, which
is a gajillion times better than comments which say "abstract
superclass!! do not instantiate!!!".

As a refactoring it's generally pretty useful. The code becomes easier
to test and easier to read. But it's really not idiomatic at all, and
it's very inelegant.

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      10-18-2007
On 10/18/07, Giles Bowkett <(E-Mail Removed)> wrote:
I'd go for modules but Robert is right too, if a class just is
abstract by the way it is defined or refactored that's it, no way
checking it's instantiation, no please. If you really feel that an
entity shall not be instantiated than a Module seems to be the correct
Ruby device.

Cheers
Robert

--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/

 
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
Abstract Methods & Abstract Class Iyer, Prasad C Python 0 10-20-2005 06:35 AM
About abstract class and abstract method Sameer Java 4 08-31-2005 12:59 AM
Deriving abstract class from non-abstract class Matthias Kaeppler Java 1 05-22-2005 01:28 PM
Abstract class with no abstract functions Uzytkownik C++ 3 04-03-2005 05:45 PM
Abstract Classes w/o abstract methods DaKoadMunky Java 4 04-20-2004 04:53 AM



Advertisments