From: Bill Barnhill <xmlarchitect@...>
Date: 2006-03-14T22:59:27+09:00
Subject: Re: [RCR] abstract method in Ruby

------=_Part_2660_15048088.1142344750320
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hmm, just some thoughts.
I think the abstract method idea nice in concept, but implementation perhap=
s
too Java-ish.

If I get a chance later this week I'll code this, but for now here's how I'=
d
envision something like this within Ruby code:

class A
    should_respond_to_behavior  #..options hash describing what to do if ms=
g
not
                                               # responded to properly goes
here,
                                               # nice to support YAML as
well..
    should_respond_to :foo, :bar =3D> {}, :baz =3D> {:param_count =3D> 3}
end

class B < A
    def initialize
       @a =3D "foo"
end

B.new
=3Dbegin
At this point the class a checks responses:
.. it expects a response to messages :foo and :bar with any or no params
.. it expects a response to baz with three params
.. raises exception if either check fails, or logs, depending on
configuraiton

You could extend the above by having behavior contrained to
normative language...
.. should_respond_to  just logs warning if msg not responded to properly
.. must_respond_to  raises exception if msg not responded to properly

Even the following, though HTBD (Here there be dragons..i.e. I'm a little
quesy about this last one)
.. may_respond_to
Same syntax as above, but means that any instances can only respond to the
defined messages. I can see several uses for this, but also see several
misuses and implementing so you could be reasonably sure about constraint
would be a pain, and might have to be in Ruby internals. This behavior also
doesn't match normative language use, perhaps a
.. must_only_respond_to


--Bill

Bill Barnhill
i-name: xri://=3DBill.Barnhill (For more info:
http://2idi.com/grs/index.php?referral_code=3Dcommunitivity )


On 3/13/06, nobu@ruby-lang.org <nobu@ruby-lang.org> wrote:
>
> Hi,
>
> At Tue, 14 Mar 2006 01:01:31 +0900,
> ara.t.howard@noaa.gov wrote in [ruby-talk:183918]:
> > hmmm - but that (both actually) fails here:
> >
> >      harp:~ > cat a.rb
> >      class Module
> >        def abstract_method m
> >          define_method(m) do |*a|
> >            defined?(super) ? super : raise(NotImplementedError, m)
> >          end
> >        end
> >      end
> >
> >      class A
> >        def foo; 42; end
> >      end
> >      class B < A
> >        abstract_method "foo"
> >      end
> >
> >      p B::new.foo
> >
> >
> >      harp:~ > ruby a.rb
> >      42
>
> Simply separate Module#abstract_method and Class#abstract_method.
>
>      class Class
>        def abstract_method m
>          define_method(m) do |*a|
>            raise(NotImplementedError, m)
>          end
>        end
>      end
>
> --
> Nobu Nakada
>
>

------=_Part_2660_15048088.1142344750320--