Prev: [ANN] Kwalify 0.7.2 - parser, schema validator, and data binding for YAML and JSON
Next: Search Array
From: David Masover on 20 Jul 2010 00:47
On Sunday, July 18, 2010 08:46:13 am Rick DeNatale wrote:
> 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

Definitely a resonance.

If I understand what you're saying, something like Java interfaces were known
and implemented in C++ and Smalltalk, though more by convention. I wonder if
client-side interfaces were ever implemented as anything quite so explicit...

I wish I'd known about this earlier. In a Java-based freshman data structures
course, a TA asked an interesting question: "What is the purpose of
inheritance?" I answered, "Code re-use." He disagreed, and I'm not entirely
sure, but I think he said, "Types." In Java! Ah, well...

From: Robert Klemme on 20 Jul 2010 01:16
On 20.07.2010 06:47, David Masover wrote:
> On Sunday, July 18, 2010 08:46:13 am Rick DeNatale wrote:
>> 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
>
> Definitely a resonance.
>
> If I understand what you're saying, something like Java interfaces were known
> and implemented in C++ and Smalltalk, though more by convention. I wonder if
> client-side interfaces were ever implemented as anything quite so explicit...

There once was the concept of "signature" in g++. Basically you could
retrofit any "interface" as a signature to any class (or even type, I
don't exactly remember). The concept was pretty cool but at some point
they kicked it out. I guess it was too infrequently used and / or
caused too much hassle for the compiler implementation.

> I wish I'd known about this earlier. In a Java-based freshman data structures
> course, a TA asked an interesting question: "What is the purpose of
> inheritance?" I answered, "Code re-use." He disagreed, and I'm not entirely
> sure, but I think he said, "Types." In Java! Ah, well...

OOSC lists several purposes and Betrand Meyer would heavily agree to you
that code reuse is a major reason for inheritance ("implementation
inheritance"). So he made Eiffel one of the few OO (the only?)
languages in which not every inheritance relationship is a "is a"
relationship. Quite interesting stuff. I really should read it again -
if only time permitted...

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: Robert Klemme on 20 Jul 2010 01:23
On 20.07.2010 06:03, David Masover wrote:
> 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.

Still, that would not be the Java for me that we have today. Without
interface a major feature for structuring code would be gone.
Expressiveness of the language would be significantly changed. But you
are right the language would resemble today's Java pretty much.

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

State. I guess they were afraid of the way C++ makes inheritance
complicated because of virtual and non virtual inheritance and the
consequences for the visibility of state ("diamond problem"). I would
also add that "interface" is a cleaner concept because it stresses the
fact that not behavior or state is shared but only the interface.
Granted, you can achieve similar goals with abstract classes that
contain only abstract methods but I think it was wise do have interfaces
in Java.

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

LOL

Cheers

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
From: Clifford Heath on 21 Jul 2010 19:11
Robert Klemme wrote:
> 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

Because every object which implements an expected interface may have
a different set of other interfaces, it requires a dynamic lookup
to find the right one. Typically there are many fewer interfaces
than methods of course, so the search is cheaper that way.

Of course, there are many ways to optimise it, as Rick pointed out.
Excellent paper, Rick, I enjoyed it.

Clifford Heath.
From: Robert Klemme on 21 Jul 2010 13:56
On 22.07.2010 01:11, Clifford Heath wrote:
> Robert Klemme wrote:
>> 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
>
> Because every object which implements an expected interface may have
> a different set of other interfaces, it requires a dynamic lookup
> to find the right one. Typically there are many fewer interfaces
> than methods of course, so the search is cheaper that way.

Wouldn't that mean duplicate entries for a method which is part of
several interfaces? And what happens in case of interface inheritance?

> Of course, there are many ways to optimise it, as Rick pointed out.
> Excellent paper, Rick, I enjoyed it.

Same here. :-)

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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