Ruby rite (Ruby 2.0) vaporware or real?

R

Richard Cole

Stephen said:
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.
 
S

Saynatkari

Richard said:
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
 
L

Luke Graham

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


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.
 
L

Luke Graham

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
 
L

Luke Graham

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.
 
G

Glenn Parker

Luke said:
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.
 
F

Florian Groß

Richard said:
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/
 
D

Daniel Berger

Richard Cole wrote:

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.

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
 
L

Lothar Scholz

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top