Hi,
I think it is fair to consider that everything the client of your (public)
function can find in the printed value from a call to (doc some-public-fun)
is part of the contract of the fun. And the arglist(s) are printed as part
of the call to 'doc.
But sometimes, one may want to leverage the possibility to do destructuring
in the arglist, while still not exposing this implementation facility in the
public contract of the function.
And, as you will see in the following example from clojure-contrib, one
could also want the docstring to be sometimes more explicit and precise than
what can be automatically collected by defn/defmacro.
The behaviour of defn/defmacro is to verify whether there is a user provided
:arglists entry in the metadata for the macro/fn var. If not, one is
automatically created from the info available in the definitions of the fn
(or fns if different definitions for different arglist arities) that compose
the fn/macro.
The user has to explicitly provide an :arglists entry in the metadata to
take full control over the public contract for the function/macro's
signature.
Here is an example from clojure-contrib where Chouser uses explicit use of
:arglists to fine-tune the public API signature of macro deferror:
;; in file error_kit.clj
(defmacro deferror
"Define a new error type"
{:arglists '([name [parent-error?] doc-string? [args*] & body]
[name [parent-error?] doc-string? args-destruct-map & body])}
[err-name pvec & decl]
....)
HTH,
--
Laurent
2009/7/23 pcda...@gmail.com <pcda...@gmail.com>
>
> Hi.
>
> I'm learning Clojure, and I like a lot what I've seen so far. Thank
> you Rich for designing
> such a nice langage, and Stuart for writing such a great book!
>
> I'm a little worried about the pattern matching/destructuring binding
> feature though. It
> looks very powerful, but also very dangerous. It seems to encourage
> people to "peek
> inside" the internals of structured values with no restrictions.
>
> The kind of scenario I'm worrying about is this:
> - Alice writes library foo and use a particular way to encode values
> (say simple vectors).
> She publishes foo v1.0.
> - Bob starts using foo, and because it is so simple and convenient,
> uses desctucturing
> everywhere.
> - Alice adds new features to version 1.1 her library, realizes the
> simple vectors are not
> enough and decides to use hashmaps instead.
> - Bob updates to version 1.1 of foo, and some of his code starts to
> break, because all the
> patterns he's used are now obsolete. He has no other solution than
> to audit all his code
> to locate (not necessarily a trivial task) and update the
> destructuring patterns which
> concern foo data.
>
> Basically the only way I see to avoid this is for Alice to consider
> her choices in
> encoding part of the published API of the library, and commit to never
> change it after
> initial publication, which is rather too restrictive.
>
> I understand that the problem would exist even without destructuring
> bindings, but from
> reading Stuart's book, it seems their use is encouraged and considered
> good style. Coming
> from an OO background which puts a strong focus on data encapsulation,
> this makes me a
> little nervous.
>
> Languages like Haskell also have pattern matching, but from what I
> understand, because
> they are strongly and statically typed, incompatible changes are
> detected at compile time
> so they can easily be found and fixed.
>
> Am I worrying for nothing? I have not yet written anything serious in
> Clojure so perhaps
> these problems do not occur in practice. Maybe following some simple
> guidelines are enough
> to avoid problems?
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
