Prev: [ANN] Kwalify 0.7.2 - parser, schema validator, and data binding for YAML and JSON
Next: Search Array
From: Rick DeNatale on 18 Jul 2010 09:46
On Sun, Jul 18, 2010 at 6:46 AM, James O'Brien <jeob32(a)gmail.com> wrote:
> David,
>
> many thanks! i found your explanation very useful.. and an article on duck
> typing is well worth reading e.g http://en.wikipedia.org/wiki/Duck_typing for
> any other ruby newbies out there!

FWIW, I wrote a paper about role-based 'types' nearly 20 years ago,
when I was at IBM. I've shared it with a few experienced Rubyists who
seemed to find a certain resonance with the ideas. Recently Alexander
Cockburn (of Crystal fame) with whom I have a shared hertitage at IBM
back then, tells me he still uses the paper when talking to clients
about dynamic typing.

http://talklikeaduck.denhaven2.com/files/TypesFromTheClientsViewpoint.PDF

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

From: Clifford Heath on 19 Jul 2010 12:50
James O'Brien wrote:
> I have found the concept of an interface invaluable in my Java programming
> and wondered if there were an equivalent concept in Ruby?
> I'm open to the idea that interfaces might not be needed in Ruby

Interfaces provide Java with dynamic method dispatch, without the
cost(*) of having every individual method in the dispatch table as
is the case with Ruby and other dynamic languages. In other words,
Ruby has interfaces; every method is its own interface. If you want
to group those methods logically, you are free to (as long as you
don't use the same method name in two groups!).

Unlike Java, Ruby also allows new methods to be added at runtime.
That requires every method lookup to traverse the inheritance chain
in a linear fashion, instead of one dynamic lookup per dispatch.
Caching method lookups helps a bit, but the linear search is still
the main reason that Ruby's method dispatch is slower than Java's.

(*) It turns out that to search a method table is little to no more
costly than to search an interface table, so Java gains nothing there.

Clifford Heath.
From: Robert Klemme on 19 Jul 2010 03:24
2010/7/19 Clifford Heath <no(a)spam.please.net>:

> Interfaces provide Java with dynamic method dispatch, without the
> cost(*) of having every individual method in the dispatch table as
> is the case with Ruby and other dynamic languages.

That sounds interesting. Can you please elaborate a bit more or
reference some documentation about this? Thanks!

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

From: Rick DeNatale on 19 Jul 2010 13:32
On Mon, Jul 19, 2010 at 2:55 AM, Clifford Heath <no(a)spam.please.net> wrote:
> James O'Brien wrote:
>>
>> I have found the concept of an interface invaluable in my Java programming
>> and wondered if there were an equivalent concept in Ruby?
>> I'm open to the idea that interfaces might not be needed in Ruby
>
> Interfaces provide Java with dynamic method dispatch, without the
> cost(*) of having every individual method in the dispatch table as
> is the case with Ruby and other dynamic languages. In other words,
> Ruby has interfaces; every method is its own interface. If you want
> to group those methods logically, you are free to (as long as you
> don't use the same method name in two groups!).
>
> Unlike Java, Ruby also allows new methods to be added at runtime.
> That requires every method lookup to traverse the inheritance chain
> in a linear fashion, instead of one dynamic lookup per dispatch.
> Caching method lookups helps a bit, but the linear search is still
> the main reason that Ruby's method dispatch is slower than Java's.
>
> (*) It turns out that to search a method table is little to no more
> costly than to search an interface table, so Java gains nothing there.

Is the * the equivalent of Emily Litella's "Never Mind!"
http://en.wikipedia.org/wiki/Emily_Litella

There's thirty or more years of experience in getting dynamic method
dispatch to run efficiently. Techniques such as polymorphic inline
caching, dynamic (re)compilation and others. One of the pioneers of
this work was David Ungar who analyzed Smalltalk performance as his
PhD dissertation, then spearheaded Self which was a language which
turned the dynamic lookup knob up to 11 (it did away with the
distinction between methods and instance variables) which exacerbates
the problems of having to do continuous dynamic lookups and found
techniques to make the language performant. Such techniques formed
the basis of the HotSpot JIT technology in Java.

There is a wealth of literature on efficient implementation of dynamic
languages, particularly in the proceedings of OOPSLA in the mid 1980s
forwards.

To date, the MRI implementations have used rather naive techniques.
JRuby does take advantage of JVM implementation techniques, albeit a
bit less directly than say MagLev which is built on a similarly
sophisticated VM which was engineered for Smalltalk rather than Ruby a
language whose underlying object model more closely maps to Ruby than
does Java.

Now, I'm far from an expert on JVM implementation, but the last time I
looked, it seemed that interfaces were really only used in method
dispatch as a way to provide the equivalent of what Ruby uses symbols
for. In ruby the method invocations

a.foo
a.foo(1)
a.foo("abc")

All resolve to the same method, where in Java these would be different
overloaded methods based on different types and numbers of parameters
(different signatures). So the combination of method name and
parameter type list needs to be mapped to a 'selector' of a method
defined in a particular (super)class or interface. The java bytecodes
to call a method typically involve fetching a 'token' from a class or
interface (which is known because of the type of the variable
'receiving' the call, and then calling a dispatch function with the
receiver, the token, and the argument values. This is very similar to
what happens in Ruby except that instead of a token based on the name
and parameter types, Ruby just uses the symbol form of the method
name.

What happens on the other side of the dispatch function is hidden, but
the effect is for the VM to find the right method implementation and
invoke it.

The traditional C++ implementation of virtual functions uses the
compiler's knowledge of the called object type and the class hierarchy
of that type to find a virtual function table and index that to find a
pointer to the method. This turns out to be very fragile, and is why
large C++ programs have LOTS more make dependencies than does a
typical C program, meaning that small source code changes can require
MANY files to be recompiled to make sure everyone has the right
locations of VFTs and virtual function indexes.

If you're interested in this try googling for "fragile base class
problem." This issue be-deviled those who tried to use C++ to build
"framework-based" OS APIs during the days of C++ fever.

http://talklikeaduck.denhaven2.com/2007/06/15/a-meeting-with-gill-bates *
http://talklikeaduck.denhaven2.com/2009/10/10/oh-the-irony

Another related bit of history is the war between different
semi-static/semi-dynamic "object models" like IBM's SOM vs.
Microsoft's COM *. Although I was playing for the "IBM team" I never
thought much of either to be honest.

http://en.wikipedia.org/wiki/IBM_System_Object_Model
http://en.wikipedia.org/wiki/Component_Object_Model


This approach falls down completely when the type hierarchy can change
at run-time and I'm pretty sure that most JVMs do the actual method
lookup more dynamically and use caching to achieve performance.

* BTW, Tony Williams who is considered as the co-inventor of COM was
IIRC the guy presenting in this meeting, and if he wasn't the
presenter he was in the room.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

From: David Masover on 20 Jul 2010 00:03
On Sunday, July 18, 2010 02:35:03 am Robert Klemme wrote:
> On 07/18/2010 06:53 AM, David Masover wrote:
> > On Saturday, July 17, 2010 08:21:10 pm James O'Brien wrote:
> >> as a thought-experiment I
> >> propose Java without interfaces would be worse
> >
> > Probably.
>
> You could not have Java without interfaces. You would at least have to
> drop static typing and this would be a major change to the language. I
> don't think you would still call the result of this operation "Java".

I don't think so. It would be much like Java without Generics -- frustrating
to work with, but possible. Basically, it kills any sort of polymorphism
between things which don't share a common ancestor -- so you make more use of
inheritance in some situations (take Collections, it wouldn't be so bad if we
had to inherit from AbstractCollection, AbstractList, etc), and aggressively
abuse modular decomposition (anywhere you have one object that needs to
pretend to be two types, make two related objects!), and you could make it
work.

In fact, IIRC, this is how C++ does it -- it's just made much easier due to
multiple inheritance. I never quite understood why Java allows multiple
interfaces to be applied to the same object, and even to the same interface,
but not multiple inheritance.

I'm not suggesting this would be a good idea, mind you -- but then, I'm also
not entirely sure either Java or C++ is a good idea.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [ANN] Kwalify 0.7.2 - parser, schema validator, and data binding for YAML and JSON
Next: Search Array