I'm confused by what you're saying here - these are examples of passing a
map, not of passing varargs.
If you want to pass a map, you'll need a set up like:
(defmulti test-html :language);; :language here is a keyword being used
as a function of one arg (the map)
(defmethod test-html :html
Just lastly, I've seen people use the following structure of data
(def test-html {:language ::html :data "hello"})
and passing it as an argument to the mutlimethod, though not sure if it
would or could apply to my case but when I use it simply returns nil under
this condition
(transform test-html
Yes, multimethod handles varargs.
On Wednesday, January 11, 2017 at 4:37:12 PM UTC-6, david swift wrote:
>
> Ah seems the repl state was the cause, restarted and the ordering worked
> correctly though it still confuses me greatly! but I'll get there
> eventually (I hope). as for the extra ')' th
Ah seems the repl state was the cause, restarted and the ordering worked
correctly though it still confuses me greatly! but I'll get there
eventually (I hope). as for the extra ')' that was manually retyping into
forum error :)
Using nightcode editor's insta-repl for testing and seems it doesn
On Wednesday, January 11, 2017 at 4:23:28 PM UTC-6, david swift wrote:
>
> Been working on a tiny snippet of code related to multimethods (something
> I've never quite wrapped my head around) and when it comes to the
> dispatching of the function I'm confused by the order in which I've to pass
Just the opposite: it means that, at runtime, you can simply load in a file
with your new defmethods and the multimethod gets updated to call through
to them dynamically. That's what you see when you're working at the REPL:
reloading a file (or typing in a new defmethod directly) is updating you
That would work.
But I would like to argue that the need to require all possible namespaces
which may implement a defmethod is a bit, should I say, closed?
This would mean that you can't build a plugin system based on multi methods,
right?
Erik.
--
i farta
> Den 23. nov. 2016 kl. 22.16 skr
Just move your defmulti form out of the namespace that's using it, core in
this case. Like this:
https://github.com/mohiji/multitest/commit/229b064cea42c37173496d96a117805494c8042a
On Wednesday, November 23, 2016 at 11:53:55 AM UTC-8, Erik Assum wrote:
>
> So, I guess my question then would be,
So, I guess my question then would be, how do I make it load without creating a
circular dependency?
Erik.
--
i farta
> Den 23. nov. 2016 kl. 20.50 skrev Jonathan Fischer :
>
> In your minimal case: nothing ever imports multitest.other, so the defmethod
> never gets loaded.
>
>> On Wednesda
In your minimal case: nothing ever imports multitest.other, so the
defmethod never gets loaded.
On Wednesday, November 23, 2016 at 11:31:21 AM UTC-8, Erik Assum wrote:
>
> Hi,
>
> I’ve got a defmulti defined in a namespace and it’s corresponding
> defmethods defined in other namespaces.
> This
i see
thx
2013/6/23 László Török
> you need a dispatch functions that produces discrete dispatch values
> using your example:
>
> (defmulti x #(cond
>(< % 10) :less-than-10
> ;;... further conditions producing different dispatch
> values
> ))
> ;; dispatch
you need a dispatch functions that produces discrete dispatch values
using your example:
(defmulti x #(cond
(< % 10) :less-than-10
;;... further conditions producing different dispatch
values
))
;; dispatch on the dispatch values
(defmethod x :less-then-10 [x]
Thank you for your response.
The reasons why I didn't use protocols are following.
1.
Currently ClojureScript doesn't have `extend`, which makes inheritance
easy.
http://david-mcneil.com/post/1475458103/implementation-inheritance-in-clojure
2.
I think an entity which is created by deftype or defr
If you are dispatching on types, use protocols. It's much faster.
Luc P
> I've experienced rewriting my ClojureScript code into multimethods
> base.
> I'd share my results.
>
> Initially I implemented polymorphism behavior as simple hashmap like
> this:
>
> (def parent
> {:foo (fn [x] ...)
If you are only dispatching on a single type - I think protocols will
always be much faster than multimethods.
I think that you only really want to use multimethods if you need to
dispatch on more than one type or on something that is not a type at all.
D
--
You received this message because
Functions (methods as you call them) can have several bodies depending
on the number of arguments, for example:
(defn stupid-max
([a] a)
([a b] (if (> a b) a b))
([a b c] (stupid-max (stupid-max a b) c)))
Mutlimethods decided which function to call depending on the value of
a dispatch functi
Hi,
On 2 Sep., 06:26, HB wrote:
> How a multimethod in Clojure differs from a method that have multiple
> bodies?
The latter can only dispatch based on the number of arguments and
cannot be extended later on. Compare:
(defmulti foo-multi type)
(defmethod foo-multi String
...)
(defmethod f
On Feb 11, 4:04 pm, Bryce wrote:
> I'm wondering what the rationale is for using multimethods vs. cond,
> and where it's best to use either? Multimethods seem to be very
> seldom used, usually to dispatch on type, but I can see advantages to
> using data to dynamically define only the methods you
hi,
the expression problem
(http://en.wikipedia.org/wiki/Expression_Problem) talks about some of
the relevant trade-offs.
sincerely.
--
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 t
Yeah, in practice it seems like multimethods are pretty much just used
as a way to let users of a library extend the API to support
additional types. If you had a cond expression dispatching on the
type of an argument, for example, then the user would have to modify
the source code of your library
On Thu, Feb 11, 2010 at 10:27 AM, Laurent PETIT wrote:
> 2010/2/11 Bryce :
> > I'm wondering what the rationale is for using multimethods vs. cond,
> > and where it's best to use either? Multimethods seem to be very
> > seldom used, usually to dispatch on type, but I can see advantages to
> > usi
2010/2/11 Bryce :
> I'm wondering what the rationale is for using multimethods vs. cond,
> and where it's best to use either? Multimethods seem to be very
> seldom used, usually to dispatch on type, but I can see advantages to
> using data to dynamically define only the methods you need, rather
>
On Oct 18, 12:29 am, Stuart Sierra
wrote:
> I think this is intentional, because the multifn doesn't call the
> dispatch function by name. Common usage is to use an anonymous fn for
> the dispatch.
Ok, wrapping it in an anonymous function solves the problem; thanks!
--~--~-~--~~
On Oct 17, 4:02 pm, pmf wrote:
> (declare my-dispatch-fn)
>
> (defmulti my-multi my-dispatch-fn) ; throws exception due to unbound
I think this is intentional, because the multifn doesn't call the
dispatch function by name. Common usage is to use an anonymous fn for
the dispatch.
-SS
--~--~---
Thanks for the answer, that's exactly what I wanted to know.
On Jul 23, 1:59 pm, Rich Hickey wrote:
> On Wed, Jul 22, 2009 at 4:33 PM, Dragan Djuric wrote:
>
> > I've just read in the Stuart's book that multimethod dispatching on
> > something other than Java inheritance is rarely used. It seems
> How fast the multimethods dispatch performs with large taxonomies
> compared to Java inheritance or small taxonomies? For example, a 1000
> or thousands elements in different taxonomies (or even a million?). Is
> it designed to perform well in such cases?
I've used hundreds of keywords in a hie
Ah. Thanks.
On Thu, Jul 23, 2009 at 8:45 AM, Stuart Halloway
wrote:
>
> Clojure's derive function creates an inheritance relationship between
> keywords (or symbols). I have taken to calling this "keyword
> inheritance" to emphasize that the inheritance is at the level of
> *names*, not of interf
Clojure's derive function creates an inheritance relationship between
keywords (or symbols). I have taken to calling this "keyword
inheritance" to emphasize that the inheritance is at the level of
*names*, not of interfaces or methods.
The book covers this in the section "Adding Inheritance
Hi Stuart,
Could you give me a two-sentence description, or a pointer to a description,
of what keyword inheritance is? Apparently this is something I haven't
encountered or don't remember...
Thanks a lot.
On Wed, Jul 22, 2009 at 10:48 PM, Stuart Halloway wrote:
>
> I certainly agree with the
On Wed, Jul 22, 2009 at 4:33 PM, Dragan Djuric wrote:
>
> I've just read in the Stuart's book that multimethod dispatching on
> something other than Java inheritance is rarely used. It seems to me
> that there is a huge potential for their use in something that I do,
> so I'd add "yet" to his word
I certainly agree with the addition of "yet". I am finding
multimethods to be more and more useful every day. I am now covering
keyword inheritance during *intro* talks on Clojure.
Stuart
> I've just read in the Stuart's book that multimethod dispatching on
> something other than Java inheri
> would it be possible for routines to check to see if they are not
> using multimethod-ness, and in that case be performance optimized, yet
> have the syntax for them all be somehow less different?
There is certainly a case for that, but (correct me if I'm wrong), but
one of the underlying philo
On 17.06.2009, at 08:36, Chris Dean wrote:
> Sure. It's easy to write one's own version of get et.al. What's hard
> to do is to get packages that you didn't write to use that version of
> get. You need everyone to use c.c.generic.collection or all the
> different libraries will have trouble in
Konrad Hinsen writes:
> But for many of Clojure's plain functions, it is not clear what their
> dispatch function should be if they were to be converted to
> multimethods.
Indeed. It can be a non-trivial design exercise. But your
clojure.contrib.generic code shows that one can make headway on
On 17.06.2009, at 00:20, Chris Dean wrote:
> To put it another way, why have the dichotomy between multimethods and
> plain functions at all?
Performance is one reason, as has been discussed already. But for
many of Clojure's plain functions, it is not clear what their
dispatch function shou
> I agree that it would be nice to be able to treat all functions as
> methods. But performance is also a key feature of Clojure that
> attracts a large percentage of its users, myself included. The initial
> reason I chose Clojure over Python, or Ruby, or any other scripting
> language was its ex
I agree that it would be nice to be able to treat all functions as
methods. But performance is also a key feature of Clojure that
attracts a large percentage of its users, myself included. The initial
reason I chose Clojure over Python, or Ruby, or any other scripting
language was its exceptional
> If the issue is performance, then I understand that. But my vote as a
> user (not that anyone asked for my opinion!) is that I would rather have
> everything logically be a method and take a performance penalty. For me
> it's a consistency and simplicity over performance argument, although
> n
On Jun 8, 3:51 pm, Konrad Hinsen wrote:
> See also my patch that creates such a universal root type [...]
Nice! That's exactly what I was thinking about
Peter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Cloju
On 08.06.2009, at 04:26, Stuart Sierra wrote:
>> If it is, it would be very useful to have something that is the
>> ancestor of everything (like T in common lisp).
>
> This has been thought about, at least: http://clojure.org/todo
> I think the question is... what should the universal ancestor be
On Jun 7, 7:46 pm, Peter Salvi wrote:
> (defmethod foo [:bar :anything] [a b] ...)
> (defmethod foo [:anything :baz] [a b] ...)
> (defmethod foo [:bar :baz] [a b] ...)
>
> This seems to do the trick... but is this really the way to do it?
This looks reasonable.
> If it is, it would be very usef
That should work fine as far as I can tell.
On Wed, Feb 25, 2009 at 3:36 PM, Jeffrey Straszheim <
straszheimjeff...@gmail.com> wrote:
> If in namespace one I define
>(defmulti fred dispatch-fred)
>
> and have imported that ns into another, can I just do
>
> (defmethod fred ::val [x] )
On Nov 19, 2:35 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> Rich,
>
> Very helpful, as always. Alias + the ability to pull in symbols names
> via refer was exactly what I was looking for.
>
> One scenario still worries me:
>
> 1. I create a multimethod that dispatches around a tag whose val
Rich,
Very helpful, as always. Alias + the ability to pull in symbols names
via refer was exactly what I was looking for.
One scenario still worries me:
1. I create a multimethod that dispatches around a tag whose value is
an unresolved keyword (:Foo instead of ::Foo). Everything works fine
On Nov 19, 7:45 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> 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
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
>
46 matches
Mail list logo
