[ANN] interface 0.1.0

[Daniel Berger]

Hi all,

It is with some trepidation that I announce the first release of the
interface module.

What is it?
===========
Java style interfaces for Ruby. For example:

require "interface"

MyInterface = interface{
required_methods :foo, :bar
}

# raises an Interface::MethodMissing error
class A
include MyInterface
end

# Also raises an error
class B; end
b = B.new
b.extend(MyInterface)

# No error raised
class C
def foo; end
def bar; end
include MyInterface
end

See the docs for more details, including a way to implement a partial
interface.

Where is it?
============
You can find it on the RAA or the project home page at
http://ruby-miscutils.sf.net.

Why did I do it?
================
Mainly to silence the Java weenies and to show that it was possible.
See the README for the long version. I, personally, do not find
interfaces to be especially useful, but here you go.

Enjoy! (or not)

Dan

 

[James Britt]

Hi all,

It is with some trepidation that I announce the first release of the
interface module.

This looks quite neat.

Why did I do it?
================
Mainly to silence the Java weenies and to show that it was possible.
See the README for the long version. I, personally, do not find
interfaces to be especially useful, but here you go.

Designer/developer theory question:

Do interfaces have a place in dynamically-typed/duck-typing languages?

Does the use of interfaces in Ruby encourage a poor (or, say, less
robust) design?

They seem like a handy way to embed assertions into code to ensure that
something blows up sooner than later, though perhaps the usual TDD
arguments apply here.


James

 

[Gavin Sinclair]

Designer/developer theory question:

Do interfaces have a place in dynamically-typed/duck-typing languages?

Yes, if the developer thinks they have a place

Does the use of interfaces in Ruby encourage a poor (or, say, less
robust) design?

I don't understand this question :/

They seem like a handy way to embed assertions into code to ensure that
something blows up sooner than later, though perhaps the usual TDD
arguments apply here.

They do apply, but it's not the end of the story. Being able to
selectively apply this interface approach (and/or the StrongTyping
module) is a good thing. If I were forced to use it with every class
I create, it would be frustrating, to say the least.

Cheers,
Gavin

 

[James Britt]

I don't understand this question :/

For example, some developers think Ruby needs static typing. They find
a way to add this in, and make it a habit. This is arguably a Bad Thing
to the extent that one loses a good deal of the power and flexibility of
the language. It's like when Pascal or FORTRAN developers first try
their hand at OOP; objects and classes (typically) become mere
namespaces for collections of procedures, and the benefits of OOD are
lost, because the developer is coding with a foreign mindset.

So I'm wondering if the use of interface classes leads one to design
Ruby code with a Java mentality.

They do apply, but it's not the end of the story. Being able to
selectively apply this interface approach (and/or the StrongTyping
module) is a good thing. If I were forced to use it with every class
I create, it would be frustrating, to say the least.

Quite true. But how often, I wonder, do people start out using
something like the StrongTyping module, and later on go back and rip it
out because it ends up getting in the way?

James

 

[Gavin Sinclair]

Quite true. But how often, I wonder, do people start out using
something like the StrongTyping module, and later on go back and rip it
out because it ends up getting in the way?

Possibly quite often, but that doesn't invalidate the usage in the
first place. It served a developmental purpose for a while; as you
wrote, to ensure that something blows up sooner rather than later.
It's the same as removing any other debugging code.

I like the feeling of removing scaffolding from my code

Gavin

 

[David Alan Black]

Hi --

For example, some developers think Ruby needs static typing. They find
a way to add this in, and make it a habit. This is arguably a Bad Thing
to the extent that one loses a good deal of the power and flexibility of
the language.

[and later...]

Quite true. But how often, I wonder, do people start out using
something like the StrongTyping module, and later on go back and rip it
out because it ends up getting in the way?

I'd like to think so, but I doubt it. I've always felt that the real
loss with such things is, as you suggest, that they divert people from
understanding and exploring what Ruby offers that isn't the same as
the language(s) they "came from". Ruby discussions have always (i.e.,
in my 3.5 Ruby years, in the English-language forums) been full of
chameleon-like proposals and rationales, like "adding LISP macros to
Ruby" or "making C++ programmers feel more at home [with ++ or
whatever]" or "adding static/strong/whatever typing" (generally
meaning classname checking combined with suppression of the fact that
Ruby objects are not manacled to their classes of origin) and so on.
I'm actually strangely fascinated by the fact that Ruby attracts so
much of this kind of discourse (since everyone you ask says they
program Ruby because they specifically love Ruby), though in spite of
the fascination my preference would be for the tendency to subside and
for Ruby to be viewed as Ruby.

Dan's announcement was actually very amusing for its ironic and
somewhat jaded tone in this regard -- sort of like, "Oh, all right, if
you want to morph Ruby into Java, here!"


David