Ruby rite (Ruby 2.0) vaporware or real?

ruby-talk
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

2

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:

  YARV: Yet Another Ruby VM

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.

3

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

not vaporware

_why reports on his blog:

http://rubyurl.com/7gNfF

4

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:

YARV: Yet Another Ruby VM

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

5

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/

6

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

7

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? :wink:

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

···

On Apr 4, 2005 2:32 PM, Saynatkari <ruby-ml@magical-cat.org> 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
> (Captcha) there doesn't seem to be much
> about on Google. I found the following project really interesting:
>
> YARV: Yet Another Ruby VM
>
> 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'.

--
spooq

8

Hello Daniel,

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.

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

9

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

···

On Apr 4, 2005 3:10 PM, Luke Graham <spoooq@gmail.com> wrote:

On Apr 4, 2005 2:32 PM, Saynatkari <ruby-ml@magical-cat.org> 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:
> >
> > YARV: Yet Another Ruby VM
> >
> > 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!"
}

--
spooq

10

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

···

On Apr 4, 2005 3:10 PM, Luke Graham <spoooq@gmail.com> wrote:

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

--
spooq

11

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/&gt;

12

Luke Graham ha scritto:

···

On Apr 4, 2005 3:10 PM, Luke Graham <spoooq@gmail.com> 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.

take a look at the various Interface libraries on RAA (raa.ruby-lang.org). They check somewhat at "compile time".

13

I took a quick look at ruby-contract's API, and it seems quite comprehensive.
Maybe one day I'll meet a problem that needs this solution, so its good to
know whats out there.

I had a toy distributed app once to investigate the ideas of changing
behaviour at run-time, and some different architectures suggested themselves.
One was to allow multiple copies of the basic app, which people could write
objects in (the heart of the app was really just an interpreter), and then those
objects could be shared with others, either being called directly or
having copies
sent. Error-checking always seemed like it would be one of the biggest problems
and this sort of thing would address at least one aspect of that.

OT: I always wanted the ability to reverse out changes to objects, such as
unmixing modules. That would be the missing piece of the puzzle as
far as my app went.

···

On Apr 5, 2005 7:59 AM, gabriele renzi <surrender_it@remove-yahoo.it> wrote:

Luke Graham ha scritto:
> On Apr 4, 2005 3:10 PM, Luke Graham <spoooq@gmail.com> 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.
>

take a look at the various Interface libraries on RAA
(raa.ruby-lang.org). They check somewhat at "compile time".

--
spooq