From: Claus Spitzer <docboobenstein@...>
Date: 2005-01-20T12:31:32+09:00
Subject: Re: Let's go Ape! Monkey typing]

The first thing that came to my mind is Self (
http://research.sun.com/self/language.html ) 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/MonkeyTyping
> 
>    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
> 
>