[Python-3000] multi-dispatch again

[Guido van Rossum]

Please move this to python-ideas; it is insufficiently thought through
to be relevant to py3k development.

On 1/14/07, tomer filiba <tomerfiliba at gmail.com> wrote:
> i just thought of a so-to-speak counter-example for ABCs... it's not really
> a counter-example, but i believe it shows a deficiency in the concept.
>
> theoretically speaking, objects are a made of type and state. ABCs,
> isinstance()
> and interfaces at general only check the type part. for example:
>
> @dispatch
> def log_to_file(text: str, device: file):
>     file.write(text)
>
> this will constrain the *type* of the device, but not its *state*.
> practically speaking, i can pass a closed file, or a file open for
> reading-only,
> and it would pass silently.
>
> basing multi-dispatch on types is of course a leap forward, but if we
> already plan to take this leap, why not make it general enough to support
> more complex use-cases?
>
> this way we could rewrite the snippet above as
>
> @dispatch
>  def log_to_file(text: str, device: open_file):
>      file.write(text)
>
> where open_file isn't a type, but rather a "checker" that may also examine
> the
> state. by default, type objects would check for inheritance (via a special
> method),
> but checkers could extend this behavior.
>
> for efficiency purposes, we can have two decorators:
> @type_dispatch - dispatches based on type only
> @full_dispatch - dispatches based on type and state
>
> bottom line -- we can't just look at the type of the object for dispatching,
> overlooking its state. the state is meaningful, and we'd want the function
> not to be called at all if the state of the object is wrong.
>
>
> -tomer
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)