Hi,

2010/6/3 Meikel Brandmeyer <m...@kotka.de>

> Hi,
>
> On Thu, Jun 03, 2010 at 01:56:36PM +0200, Laurent PETIT wrote:
>
> > Now to clojure. I can see the same problem occur, while the article's
> author
> > claims that in clojure there's (almost) no problem anymore.
> > If several libraries, including my program, redefine blindlessly a
> protocol
> > implementation for the same type, then the "last to speak" wins.
> > So isn't the problem basically the same ?
>
> No. A protocol lives in a namespace. So its methods have to be
> unique only in the same namespace. Types and reify implement
> protocols (and their Java interface) at definition time. Later
> on only the extend version via a map works. So the object itself
> is not modified. Only the protocol functions know about these
> extensions. And due to they belonging to a namespace it is clear
> what has to be called by the protocol method you call.
>

The above point has been answered to Christophe. I was not talking about the
way that namespacing will reduce the problem by allowing different function
names (with probably different semantics) to live in different namespaces.
This is no different than distinguishing 2 ordinary functions with the same
name, living in different namespaces, from the caller's point of vue.


>
> And redefining things in foreign namespaces is rather not a
> technique we should support...
>
> Eh? Does that make sense?
>

No, I don't understand your last point.

How can the expression problem be claimed to be (almost) solved, if only the
owner of a protocol and of a namespace can extend the protocol on types ?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to