Ruby rite (Ruby 2.0) vaporware or real?

Discussion in 'Ruby' started by Stephen Birch, Apr 4, 2005.

  1. Matz's keynote topic at Rubyconf in which Ruby 2.0 was introduced was
    in 2003.

    Does anyone know if any progress has been made on Ruby Rite or is it
    vaporware (http://en.wikipedia.org/wiki/Vaporware)?

    Steve
    Stephen Birch, Apr 4, 2005
    #1
    1. Advertising

  2. Stephen Birch

    Richard Cole Guest

    Stephen Birch wrote:

    >Matz's keynote topic at Rubyconf in which Ruby 2.0 was introduced was
    >in 2003.
    >
    >Does anyone know if any progress has been made on Ruby Rite or is it
    >vaporware (http://en.wikipedia.org/wiki/Vaporware)?
    >
    >

    Apart from the entry on Ruby-Garden
    (http://www.rubygarden.org/ruby?Rite) there doesn't seem to be much
    about on Google. I found the following project really interesting:

    http://www.atdot.net/yarv/#i-5-1

    I dowloaded it and built it a couple of weeks ago, I got a small number
    of build errors that were fairly easy to fix. When I tried it with
    QtRuby though I think it fell over.

    Yarv generates byte code and hints at being Rite complient because you
    have to run "ruby -rite" to activate it, but I couldn't find anything
    explicit on the web page about support for Rite.

    Anyone else had success with Yarv yet?

    My major gripe with Ruby is that there's no static typing. I'd really
    like to be able to do something like:

    interface ISubject
    def notifyAll -- unit
    def addObserver(a -- IObserver) -- unit
    end

    interface IObserver
    def subjectUpdate(subject -- ISubject)
    end
    end

    class Subject
    def initialize
    @observerList -- ISubject IEnum = Array.new()
    end
    ...
    end

    Why? because interfaces gives you a place define and explain protocols
    of interaction. It also helps out the IDE, when you type @observerList
    the IDE knows the type and can do name completion on it, hyperlink your
    code etc.

    Also interfaces inheritance is very different to reuse inheritance. It
    is so much clearer intentwise for a framework if the interfaces are
    explicit, rather than being implicit.

    The major problem with interfaces is that you can't say later, oh, this
    class implements that interface, but in Ruby, if there were interfaces,
    the you could.

    regards,

    Richard.
    Richard Cole, Apr 4, 2005
    #2
    1. Advertising

  3. Stephen Birch

    Saynatkari Guest

    Richard Cole wrote:
    > Stephen Birch wrote:
    >
    >> Matz's keynote topic at Rubyconf in which Ruby 2.0 was introduced was
    >> in 2003.
    >>
    >> Does anyone know if any progress has been made on Ruby Rite or is it
    >> vaporware (http://en.wikipedia.org/wiki/Vaporware)?
    >>
    >>

    > Apart from the entry on Ruby-Garden
    > (http://www.rubygarden.org/ruby?Rite) there doesn't seem to be much
    > about on Google. I found the following project really interesting:
    >
    > http://www.atdot.net/yarv/#i-5-1
    >
    > I dowloaded it and built it a couple of weeks ago, I got a small number
    > of build errors that were fairly easy to fix. When I tried it with
    > QtRuby though I think it fell over.
    >
    > Yarv generates byte code and hints at being Rite complient because you
    > have to run "ruby -rite" to activate it, but I couldn't find anything
    > explicit on the web page about support for Rite.
    >
    > Anyone else had success with Yarv yet?
    >
    > My major gripe with Ruby is that there's no static typing. I'd really
    > like to be able to do something like:
    >
    > interface ISubject
    > def notifyAll -- unit
    > def addObserver(a -- IObserver) -- unit
    > end
    >
    > interface IObserver
    > def subjectUpdate(subject -- ISubject)
    > end
    > end
    >
    > class Subject
    > def initialize
    > @observerList -- ISubject IEnum = Array.new()
    > end
    > ...
    > end


    You _can_ do that. You just do not have to specify the types
    of the Subject and Observer.

    > Why? because interfaces gives you a place define and explain protocols
    > of interaction. It also helps out the IDE, when you type @observerList
    > the IDE knows the type and can do name completion on it, hyperlink your
    > code etc.
    >
    > Also interfaces inheritance is very different to reuse inheritance. It
    > is so much clearer intentwise for a framework if the interfaces are
    > explicit, rather than being implicit.
    >
    > The major problem with interfaces is that you can't say later, oh, this
    > class implements that interface, but in Ruby, if there were interfaces,
    > the you could.


    Interface conformity is generally ensured by running unit tests
    on any classes that 'implement' the given 'interface'.

    > regards,
    >
    > Richard.


    E
    Saynatkari, Apr 4, 2005
    #3
  4. Stephen Birch

    Luke Graham Guest

    On Apr 4, 2005 2:32 PM, Saynatkari <> wrote:
    > Richard Cole wrote:
    > > Stephen Birch wrote:
    > >
    > >> Matz's keynote topic at Rubyconf in which Ruby 2.0 was introduced was
    > >> in 2003.
    > >>
    > >> Does anyone know if any progress has been made on Ruby Rite or is it
    > >> vaporware (http://en.wikipedia.org/wiki/Vaporware)?
    > >>
    > >>

    > > Apart from the entry on Ruby-Garden
    > > (http://www.rubygarden.org/ruby?Rite) there doesn't seem to be much
    > > about on Google. I found the following project really interesting:
    > >
    > > http://www.atdot.net/yarv/#i-5-1
    > >
    > > I dowloaded it and built it a couple of weeks ago, I got a small number
    > > of build errors that were fairly easy to fix. When I tried it with
    > > QtRuby though I think it fell over.
    > >
    > > Yarv generates byte code and hints at being Rite complient because you
    > > have to run "ruby -rite" to activate it, but I couldn't find anything
    > > explicit on the web page about support for Rite.
    > >
    > > Anyone else had success with Yarv yet?
    > >
    > > My major gripe with Ruby is that there's no static typing. I'd really
    > > like to be able to do something like:
    > >
    > > interface ISubject
    > > def notifyAll -- unit
    > > def addObserver(a -- IObserver) -- unit
    > > end
    > >
    > > interface IObserver
    > > def subjectUpdate(subject -- ISubject)
    > > end
    > > end
    > >
    > > class Subject
    > > def initialize
    > > @observerList -- ISubject IEnum = Array.new()
    > > end
    > > ...
    > > end

    >
    > You _can_ do that. You just do not have to specify the types
    > of the Subject and Observer.
    >
    > > Why? because interfaces gives you a place define and explain protocols
    > > of interaction. It also helps out the IDE, when you type @observerList
    > > the IDE knows the type and can do name completion on it, hyperlink your
    > > code etc.
    > >
    > > Also interfaces inheritance is very different to reuse inheritance. It
    > > is so much clearer intentwise for a framework if the interfaces are
    > > explicit, rather than being implicit.
    > >
    > > The major problem with interfaces is that you can't say later, oh, this
    > > class implements that interface, but in Ruby, if there were interfaces,
    > > the you could.

    >
    > Interface conformity is generally ensured by running unit tests
    > on any classes that 'implement' the given 'interface'.


    I dont use interfaces as such in my own work, but thinking out loud on this...


    module AnInterface
    def amethod
    "default"
    end
    end

    The app could test any object that claims to implement the interface
    by ...

    AnInterface.instance_methods.each { |pm|
    object.respond_to? pm ? raise "Bad object!"
    }

    Interface inheritance can be done by just including the base module
    and any extra child modules in the list to be checked.

    The added bonus is that "interfaces" can even contain their own
    default functions. Hows that for self-documenting? ;)

    Is there anything an interface can do that a module cant? For mine,
    modules are a superset of interfaces.

    --
    spooq
    Luke Graham, Apr 4, 2005
    #4
  5. Stephen Birch

    Luke Graham Guest

    On Apr 4, 2005 3:10 PM, Luke Graham <> wrote:
    > On Apr 4, 2005 2:32 PM, Saynatkari <> wrote:
    > > Richard Cole wrote:
    > > > Stephen Birch wrote:
    > > >
    > > >> Matz's keynote topic at Rubyconf in which Ruby 2.0 was introduced was
    > > >> in 2003.
    > > >>
    > > >> Does anyone know if any progress has been made on Ruby Rite or is it
    > > >> vaporware (http://en.wikipedia.org/wiki/Vaporware)?
    > > >>
    > > >>
    > > > Apart from the entry on Ruby-Garden
    > > > (http://www.rubygarden.org/ruby?Rite) there doesn't seem to be much
    > > > about on Google. I found the following project really interesting:
    > > >
    > > > http://www.atdot.net/yarv/#i-5-1
    > > >
    > > > I dowloaded it and built it a couple of weeks ago, I got a small number
    > > > of build errors that were fairly easy to fix. When I tried it with
    > > > QtRuby though I think it fell over.
    > > >
    > > > Yarv generates byte code and hints at being Rite complient because you
    > > > have to run "ruby -rite" to activate it, but I couldn't find anything
    > > > explicit on the web page about support for Rite.
    > > >
    > > > Anyone else had success with Yarv yet?
    > > >
    > > > My major gripe with Ruby is that there's no static typing. I'd really
    > > > like to be able to do something like:
    > > >
    > > > interface ISubject
    > > > def notifyAll -- unit
    > > > def addObserver(a -- IObserver) -- unit
    > > > end
    > > >
    > > > interface IObserver
    > > > def subjectUpdate(subject -- ISubject)
    > > > end
    > > > end
    > > >
    > > > class Subject
    > > > def initialize
    > > > @observerList -- ISubject IEnum = Array.new()
    > > > end
    > > > ...
    > > > end

    > >
    > > You _can_ do that. You just do not have to specify the types
    > > of the Subject and Observer.
    > >
    > > > Why? because interfaces gives you a place define and explain protocols
    > > > of interaction. It also helps out the IDE, when you type @observerList
    > > > the IDE knows the type and can do name completion on it, hyperlink your
    > > > code etc.
    > > >
    > > > Also interfaces inheritance is very different to reuse inheritance. It
    > > > is so much clearer intentwise for a framework if the interfaces are
    > > > explicit, rather than being implicit.
    > > >
    > > > The major problem with interfaces is that you can't say later, oh, this
    > > > class implements that interface, but in Ruby, if there were interfaces,
    > > > the you could.

    > >
    > > Interface conformity is generally ensured by running unit tests
    > > on any classes that 'implement' the given 'interface'.

    >
    > I dont use interfaces as such in my own work, but thinking out loud on this...
    >
    > module AnInterface
    > def amethod
    > "default"
    > end
    > end
    >
    > The app could test any object that claims to implement the interface
    > by ...
    >
    > AnInterface.instance_methods.each { |pm|
    > object.respond_to? pm ? raise "Bad object!"
    > }


    I think its pretty obvious there should be a bang in there somewhere :p

    --
    spooq
    Luke Graham, Apr 4, 2005
    #5
  6. Stephen Birch

    Luke Graham Guest

    On Apr 4, 2005 3:10 PM, Luke Graham <> wrote:

    > Interface inheritance can be done by just including the base module
    > and any extra child modules in the list to be checked.


    I guess this list could be in the child interface or somewhere else.

    --
    spooq
    Luke Graham, Apr 4, 2005
    #6
  7. Stephen Birch

    vruz Guest

    vruz, Apr 4, 2005
    #7
  8. Stephen Birch

    Glenn Parker Guest

    Luke Graham wrote:
    >
    > The app could test any object that claims to implement the interface
    > by ...
    >
    > AnInterface.instance_methods.each { |pm|
    > object.respond_to? pm ? raise "Bad object!"
    > }


    Duck typing does not require that every class implement every possible
    method in a given interface, so this test would be too broad.

    But this thread gets me thinking that those who want some "compile-time"
    style type-checking could implement a DSL to assist themselves in Ruby.

    --
    Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
    Glenn Parker, Apr 4, 2005
    #8
  9. Richard Cole wrote:

    > My major gripe with Ruby is that there's no static typing. I'd really
    > like to be able to do something like:
    >
    > interface ISubject
    > def notifyAll -- unit
    > def addObserver(a -- IObserver) -- unit
    > end
    >
    > interface IObserver
    > def subjectUpdate(subject -- ISubject)
    > end
    > end
    >
    > class Subject
    > def initialize
    > @observerList -- ISubject IEnum = Array.new()
    > end
    > ...
    > end
    >
    > Why? because interfaces gives you a place define and explain protocols
    > of interaction. It also helps out the IDE, when you type @observerList
    > the IDE knows the type and can do name completion on it, hyperlink your
    > code etc.
    >
    > Also interfaces inheritance is very different to reuse inheritance. It
    > is so much clearer intentwise for a framework if the interfaces are
    > explicit, rather than being implicit.
    >
    > The major problem with interfaces is that you can't say later, oh, this
    > class implements that interface, but in Ruby, if there were interfaces,
    > the you could.


    Please have a look at my ruby-contract library which offers this and
    more: http://ruby-contract.rubyforge.org/
    Florian Groß, Apr 4, 2005
    #9
  10. Richard Cole wrote:

    <snip>

    > My major gripe with Ruby is that there's no static typing.


    Ruby is a dynamic language. You're still thinking in Java.

    > I'd really
    > like to be able to do something like:
    >
    > interface ISubject
    > def notifyAll -- unit
    > def addObserver(a -- IObserver) -- unit
    > end
    >
    > interface IObserver
    > def subjectUpdate(subject -- ISubject)
    > end
    > end
    >
    > class Subject
    > def initialize
    > @observerList -- ISubject IEnum = Array.new()
    > end
    > ...
    > end
    >
    > Why? because interfaces gives you a place define and explain

    protocols
    > of interaction.


    There's nothing you can do with an interface that I can't do better
    with a mixin. You can also get the equivalent effect with
    documentation and a test suite, e.g. "your package must implement
    methods X, Y, and Z and pass the provided test suite". I believe Rails
    uses the latter approach for verifying DB adapters, for example.

    <snip>

    > The major problem with interfaces is that you can't say later, oh,

    this
    > class implements that interface, but in Ruby, if there were

    interfaces,
    > the you could.


    No, instead you use mixins and say, "this class mixes in that module".
    And, instead of just stubs, you get an actual *implementation*.

    All that being said, I wrote (with much help) an "interface" package,
    mostly as a proof of concept. You can find it on the RAA.

    Regards,

    Dan
    Daniel Berger, Apr 4, 2005
    #10
  11. Hello Daniel,


    DB> There's nothing you can do with an interface that I can't do better
    DB> with a mixin. You can also get the equivalent effect with
    DB> documentation and a test suite, e.g. "your package must implement
    DB> methods X, Y, and Z and pass the provided test suite". I believe Rails
    DB> uses the latter approach for verifying DB adapters, for example.

    The bad thing with this from a software engineering point of view is
    that you split important information about a class to multiple files.
    I don't think that test cases should be considered part of the
    documentation. OO has the huge advantage that you bundle information
    (data, methods, documentation) in one place.

    We don't need java static typing and we don't need to hide this
    information into unstructured test cases.
    Look at the smaltalk guys, they did it right, they have protocols aka
    interfaces and they are usefull. They are simplymeta definitions
    for documentation purpose only.
    An IDE can then provide tools to verify constraints and easyier
    working with protocols.

    Interfaces have a huge advantage for documentation so why shouldn't we
    use them ? Documentation and learning other persons libraries is
    already very hard in languages like ruby.


    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Apr 4, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    514
  2. Austin Ziegler

    Ruby => Rite, AST => Bytecode?

    Austin Ziegler, Jul 30, 2003, in forum: Ruby
    Replies:
    2
    Views:
    112
    Phil Tomson
    Jul 30, 2003
  3. Guest
    Replies:
    34
    Views:
    375
    Jim Freeze
    Aug 28, 2003
  4. David Heinemeier Hansson

    [ANN] Rails 0.5.0: The end of vaporware!

    David Heinemeier Hansson, Jul 24, 2004, in forum: Ruby
    Replies:
    20
    Views:
    253
    David Heinemeier Hansson
    Jul 26, 2004
  5. Peter Fitzgibbons
    Replies:
    3
    Views:
    86
    Eric Hodel
    Mar 23, 2009
Loading...

Share This Page