[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Let's go Ape! Monkey typing]

John Carter

1/19/2005 9:26:00 PM

7 Answers

tsawyer

1/19/2005 11:33:00 PM

0

Very interesting article thank you!

Slithers are not the only ones who can monkey around ;-)

<pre>

class Duck
def walk
puts "walk, walk"
end
def to_duck
self
end
end

class Mallard
def waddle
puts "waddle, waddle"
end
def to_duck
class << self
def walk
waddle
end
end
self
end
end

def duckmoto(d,k=d.to_duck)
k.walk
end

d = Duck.new
m = Mallard.new

duckmoto(d)
duckmoto(m)

</pre>

This seems very close to what is being described as "monkey typing".
Obviously there are few missing features and a couple caveats to the
interface here, but they should be easy enough to tackle if this was
thought a good idea.

But I don't know if I'm prepared for "monkey" terminology. Bars,
Barrells, and Wrenches suddenly come to mind. And after all, we just
got a real duck of our own (Mr. Type) a few weeks ago! Hmm... I suppose
they can be friends. Friends are nice. But I worry how his shoulder
horse might feel about these new arrangements ;-)

T.

Claus Spitzer

1/20/2005 3:32:00 AM

0

The first thing that came to my mind is Self (
http://research.sun.com/self/lan... ) with its dynamic
inheritance. Discuss :) .


On Thu, 20 Jan 2005 06:26:28 +0900, John Carter <john.carter@tait.co.nz> wrote:
> No, I'm not trying to make a monkey out of you, there really is a
> genuine proposal to extend duck typing with monkey typing.
> http://peak.telecommunity.com/DevCenter/Mo...
>
> Abstract
>
> Python has always had "duck typing": a way of implicitly defining
> types by the methods an object provides. The name comes from the
> saying, "if it walks like a duck and quacks like a duck, it must be
> a duck". Duck typing has enormous practical benefits for small and
> prototype systems. For very large frameworks, however, or
> applications that comprise multiple frameworks, some limitations of
> duck typing can begin to show.
>
> This PEP proposes an extension to "duck typing" called "monkey
> typing", that preserves most of the benefits of duck typing, while
> adding new features to enhance inter-library and inter-framework
> compatibility. The name comes from the saying, "Monkey see, monkey
> do", because monkey typing works by stating how one object type may
> mimic specific behaviors of another object type.
>
> In particular, I like this quote...
>
> As Guido acknowledged in his optional static typing proposals,
> having type declarations check argument types based purely on
> concrete type or conformance to interfaces would stifle much of
> Python's agility and flexibility. However, if type declarations are
> used instead to adapt objects to an interface expected by the
> receiver, Python's flexibility could in fact be improved by type
> declarations.
>
> Also important are the notions of composition of adaptors and that
> there are two types of adaption...
>
> Over a long period of time, it became clear that there are really
> two fundamentally different types of adaptation that are in common
> use. One type is the "extender", whose purpose is to extend the
> capability of an object or allow it to masquerade as another type of
> object. An "extender" is not truly an object unto itself, merely a
> kind of "alternate personality" for the object it adapts. For
> example, a power transformer might be considered an "extender" for a
> power outlet, because it allows the power to be used with different
> devices than it would otherwise be usable for.
>
> By contrast, an "independent adapter" is an object that provides
> entirely different capabilities from the object it adapts, and
> therefore is truly an object in its own right. While it only makes
> sense to have one extender of a given type for a given base object,
> you may have as many instances of an independent adapter as you like
> for the same base object. For example, Python iterators are
> independent adapters, as are views in a model-view-controller
> framework, since each iterable may have many iterators in existence,
> each with its own independent state. Resuming the previous analogy
> of a power outlet, you may consider independent adapters to be like
> appliances: you can plug more than one lamp into the same outlet,
> and different lamps may be on or off at a given point in time. Many
> appliances may come and go over the lifetime of the power outlet --
> there is no inherent connection between them because the appliances
> are independent objects rather than mere extensions of the power
> outlet.
>
> A key distinction between extenders and independent adapters is the
> "as a" relationship versus the "has a" relationship. An iterable
> "has" iterators and a model "has" views. But an extender represents
> an "as a" relationship, like treating a Person "as an" Employee, or
> treating a string "as a" filename.
>
> John Carter Phone : (64)(3) 358 6639
> Tait Electronics Fax : (64)(3) 359 4632
> PO Box 1645 Christchurch Email : john.carter@tait.co.nz
> New Zealand
>
> "The notes I handle no better than many pianists. But the pauses
> between the notes -
> ah, that is where the art resides!' - Artur Schnabel
>
>


James Britt

1/20/2005 3:40:00 AM

0

Claus Spitzer wrote:
> The first thing that came to my mind is Self (
> http://research.sun.com/self/lan... ) with its dynamic
> inheritance. Discuss :) .

Is it like ECAMScript?


James


James Britt

1/20/2005 3:40:00 AM

0

James Britt wrote:
> Claus Spitzer wrote:
>
>> The first thing that came to my mind is Self (
>> http://research.sun.com/self/lan... ) with its dynamic
>> inheritance. Discuss :) .
>
>
> Is it like ECAMScript?

Um, ECMAScript.


Claus Spitzer

1/20/2005 4:59:00 AM

0

Err, I don't think that there is much relation between ECMAScript and
Self, even though I'll be the first to admit that I only just glanced
at the ECMAScript docs. It seems to me that in ECMAScript allowing for
dynamic modification of objects is optional. If memory serves me
right, in Self the _only_ way to alter an object is by changing its
inheritance.
Craig Chambers, purveyor of other fancy language implementations like
Cecil, made a great deal of contributions to Self, mainly in terms of
optimizations. More in it can be read here
http://plg.uwaterloo.ca/~stevem/cs842/material/papers/optimizingJava/Chamber...

Cheers...


On Thu, 20 Jan 2005 12:40:29 +0900, James Britt
<jamesUNDERBARb@neurogami.com> wrote:
> James Britt wrote:
> > Claus Spitzer wrote:
> >
> >> The first thing that came to my mind is Self (
> >> http://research.sun.com/self/lan... ) with its dynamic
> >> inheritance. Discuss :) .
> >
> >
> > Is it like ECAMScript?
>
> Um, ECMAScript.
>
>


tsawyer

1/20/2005 5:57:00 AM

0

On the surface Self is very interesting, but like everything that seesm
to come out of Sun, undeneath it is astronomically complex. I tries
reading the "grit" on Self one night (100+ pages) and found myself
swimmin in utter confusion.

So while I understand bits and pieces I never quite got so far as to
understand this dynamic inheritence. I take it you can change traits on
the fly?

And yes, I like prototype OOP.

T.

gabriele renzi

1/20/2005 7:52:00 AM

0

Claus Spitzer ha scritto:
> Err, I don't think that there is much relation between ECMAScript and
> Self, even though I'll be the first to admit that I only just glanced
> at the ECMAScript docs. It seems to me that in ECMAScript allowing for
> dynamic modification of objects is optional. If memory serves me
> right, in Self the _only_ way to alter an object is by changing its
> inheritance.
> Craig Chambers, purveyor of other fancy language implementations like
> Cecil, made a great deal of contributions to Self, mainly in terms of
> optimizations. More in it can be read here
> http://plg.uwaterloo.ca/~stevem/cs842/material/papers/optimizingJava/Chamber...
>
> Cheers...
>

well, ECMASCript does resemble Self in being prototype based