Hello stuart,

On 19 Nov., 13:45, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> I am working on the multimethod chapter this week. This has required a  
> lot of exploration, as the multimethod feature set goes well beyond  
> what most people are using yet. I have hit one rough spot: derive. I  
> have working code (below), but I don't like the way I have to call it  
> with fully qualified keywords, e.g.
I feel not very familiar with multimethods up to now. I don't know
whether I'm using them correctly or not. (So a good thing, that you
investigate this for your book. :))

So take my interpretation with a good deal of salt.

Multimethods define an interface. Suppose for example the harness
question for test-is.

(defmulti report-result ....)

Now the librarian provides a function make-fancy-harness. John Doe
just calls this function and gets something. In fact he shouldn't even
bother, what it looks like. The only thing he has to know is, that
report-result does the right thing, when it is fed with that
something.
If John Doe looks inside and starts using internal information, I hope
he ends up in rework hell.

Now suppose John wants to extend the library. Now that's a different
story. Now he has to use the fully qualified keyword. Exactly once.
In derive. Compare this to class Foo extends
fully.quallified.ClassName.
After this point, :: is sufficient. For Jim, user of John's library,
the
same argument as above applies.

So in an ideal world fully qualified keywords should never ever show
up in user code. Only the defining namespace should use them.

The problem between : and :: is something I don't quite understand.
Either it is local to your namespace. Then it doesn't matter. Or you
leak it outside. Then :: should be used to avoid clashes. It can be
even used as an indicator for a part of the API. ("Change this and
user code will break.")

Accessing a field directly was already a bad idea back when we all
used C. And it brings inflexibility. For example, a deriver(?) wants
to replace a field, with a dynamically computed value? With direct
access you are off, with an interface function it easily possible.

Sincerely
Meikel


--~--~---------~--~----~------------~-------~--~----~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to