Hi,
On 5 Nov., 03:17, ka <[email protected]> wrote:
> Yes Meikel that is exactly what I have right now. Just trying to learn
> and stir up a discussion here :)
And it's a good discussion. I think many in the community - myself
included! - don't grok protocols, yet. So any discussion on how they
are intended to be used is of value. :)
> (deftype ReallyCool ... Coolness .. Comparable .. Serializable)
> (deftype SneakyCool .. Coolness)
>
> (x (ReallyCool.)) ;yay rocket launches and reaches moon!
> (x (SneakyCool.)) ;rocket launches alright (no exception thrown), but
> blows mid air
Yeah. That's tragic. But the fate of dynamic typing. As I said: what
is the difference to your protocol function calling seq on an argument
of your protocol function which turns out at runtime to be not
seqable? 3 2 1 0 "We have a lift off!" "100m" "200m"..*BOOM*. You may
want some dependency graph on your protocols, but why stop half the
way? Then we can go the full way to static typing. I don't see the
first argument of a protocol function differently from an importance
point of view besides it's used to choose the implementation which is
used in the call.
> I know you might argue its a code bug and caller's problem etc. - but
> you just allowed a rocket to blow up.
Yeah. Then use Haskell, OCaml or Ada. Any dynamically typed languge
will suffer from such types of problems. I think the magic word
usually used here is "testing".
> static public ISeq seq(Object coll){
> if(coll instanceof ASeq)
> return (ASeq) coll;
> else if(coll instanceof LazySeq)
> return ((LazySeq) coll).seq();
> else
> return seqFrom(coll);
>
> }
>
> @Laurent,> * first, when I see calls to (instance?) (satisifies?), it rings a
> bell in my head. "design problem".
>
> Do you see the above seq method as a design problem? - or if you don't
> care about Java, consider clojure.walk.
I think no one (including Rich) disagrees when I say that this sucks.
This type of thing is exactly the reason why protocols exist: to
handle this problem fast. (Multimethods would scratch the same itch,
but are too slow for low-level code. seq is called quite a lot around
the library.)
> I simply asked - is there anything fundamentally wrong with the notion
> of those protocols being composable. Protocol P is a set of abstract
> functions, can we have a convenient way of saying P = union(P1, P2) ?
Maybe that's perfectly fine? I don't know. I leave this to people with
more experience than I have. But as I said I have a feeling that there
is swinging a lot of object-oriented thinking in this style of
reasoning. I'm not sure whether this is good or bad, or whether I'm
just reacting alergic to O's.
> On a related note how is this:
>
> (defn dispatch-fn [this ..]
> (if (and (comparable? this) (serializable? this))
> :green-signal :red-signal)
>
> (defmulti x dispatch-fn)
> (defmulti y dispatch-fn)
> (defmulti z dispatch-fn)
I don't understand this: what do you do in case of :red-signal? Handle
things gracefully? How is this different to catching an exception?
On 5 Nov., 03:42, David Nolen <[email protected]> wrote:
> This highlights a sore spot in the current multimethod implementation - the
> dispatch fn is "closed".
The dispatch function might just as well be another (open)
multimethod.
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
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
