On Feb 7, 12:32 pm, David Nolen wrote:
> > On the issue list there is a patch for per-defmulti hierarchies,
> > waiting for Rich's approval. Although it's not predicate dispatch
> > it might help to bridge the time until the SoC project gives us
> > predicate dispatch.
>
> > Sincerely
> > Meike
On Feb 6, 5:18 pm, David Nolen wrote:
> > I built 4 iterations of a model/protocol/thing system, accumulating
> > more requirements for it with each iteration. This discussion has had
> > the nice side-effect of grooming my requirements into a tidy state
> > that I can use for reference. What I
>
> On the issue list there is a patch for per-defmulti hierarchies,
> waiting for Rich's approval. Although it's not predicate dispatch
> it might help to bridge the time until the SoC project gives us
> predicate dispatch.
>
> Sincerely
> Meikel
>
>
+1 for this, without this the usefulness of mak
Hello,
Am 06.02.2009 um 09:34 schrieb mikel:
(prefer-method frob ::idea ::thing)
(prefer-method [::runtime-tag1 ::idea] [::runtime-tag1 ::thing])
(prefer-method [::runtime-tag2 ::thing] [::runtime-tag2 ::idea])
Provide a dispatch fn that extracts the runtime tag.
Yuck. Instead of definin
>
> I built 4 iterations of a model/protocol/thing system, accumulating
> more requirements for it with each iteration. This discussion has had
> the nice side-effect of grooming my requirements into a tidy state
> that I can use for reference. What I'm doing next is stripping out all
> of the m/p/
On Feb 6, 7:27 am, David Nolen wrote:
> > Yuck. Instead of defining a method on ::idea, you now must define a
> > method on [something-that-has-no-meaning-in-context ::idea] (because
> > the dispatch function must now return a vector, which means the
> > defmethods must now be called on vector
>
> Yuck. Instead of defining a method on ::idea, you now must define a
> method on [something-that-has-no-meaning-in-context ::idea] (because
> the dispatch function must now return a vector, which means the
> defmethods must now be called on vector dispatch values...).
Sure but as you mention
On Feb 6, 12:18 am, David Nolen wrote:
> > (prefer-method frob ::idea ::thing)
>
> (prefer-method [::runtime-tag1 ::idea] [::runtime-tag1 ::thing])
> (prefer-method [::runtime-tag2 ::thing] [::runtime-tag2 ::idea])
>
> Provide a dispatch fn that extracts the runtime tag.
Yuck. Instead of def
Have thoughts about this, will have to collect them, will reply soon.
On Thu, Feb 5, 2009 at 9:06 PM, mikel wrote:
>
>
>
> On Feb 5, 7:12 pm, David Nolen wrote:
> > > I'm not looking for a way to statically define protocols in which
> > > classes participate. Consider an example similar to the
>
> (prefer-method frob ::idea ::thing)
>
(prefer-method [::runtime-tag1 ::idea] [::runtime-tag1 ::thing])
(prefer-method [::runtime-tag2 ::thing] [::runtime-tag2 ::idea])
Provide a dispatch fn that extracts the runtime tag.
--~--~-~--~~~---~--~~
You received th
On Feb 5, 7:44 pm, David Nolen wrote:
> > The fly in the ointment is: what happens if both
> > protocols specialize frob? Then Clojure will complain that it can't
> > tell which method to call. In order to resolve that problem, we must
> > use prefer-method to declare that one protocol or the
On Feb 5, 7:12 pm, David Nolen wrote:
> > I'm not looking for a way to statically define protocols in which
> > classes participate. Consider an example similar to the one I gave in
> > my reply to Laurent:
>
> Static defining of anything is just a matter of chose, especially in
> Clojure. For
>
> The fly in the ointment is: what happens if both
> protocols specialize frob? Then Clojure will complain that it can't
> tell which method to call. In order to resolve that problem, we must
> use prefer-method to declare that one protocol or the other is
> preferred.
>
> But what if I want to
>
> I'm not looking for a way to statically define protocols in which
> classes participate. Consider an example similar to the one I gave in
> my reply to Laurent:
Static defining of anything is just a matter of chose, especially in
Clojure. For example in Spinoza you have pose-as which changes
On Feb 5, 3:01 pm, David Nolen wrote:
> > I don't argue that this model is better than what you're doing with
> > Spinoza, but for years (see
> >http://www.mactech.com/articles/frameworks/8_2/Protocol_Evins.html
> > from 1994) I've wanted an object model that explicitly separates
> > structure
On Feb 5, 6:36 am, Laurent PETIT wrote:
> Doesn't that sound like multifunctions whose dispatching is tied to the
> type ('model') of a 'thing' ?
Yes, but see below.
> Once again, does'nt this correspond to the introduction of the interface
> concept in java ?
No. I think the article I li
(isa? [:spinoza-example-one/circle] [:spinoza/object]) ;; true
Just to note, the above shows that protocols could have their own
inheritance chain. This is insanely powerful and could be implemented very
quickly.
--~--~-~--~~~---~--~~
You received this message bec
>
> I don't argue that this model is better than what you're doing with
> Spinoza, but for years (see
> http://www.mactech.com/articles/frameworks/8_2/Protocol_Evins.html
> from 1994) I've wanted an object model that explicitly separates
> structure from protocol, and since I partially built one in
A protocol is a level of abstraction above an interface.
Java (and c++) virtual dispatch is one implementation of a meta-object
protocol, where dispatch is dynamic upon the first argument to the
function and object derivation means a certain order of function
overriding, etc.
Most likely mikel i
Hello,
Please accept my apologizes if the following remarks/questions sound stupid
or silly to you, but I can't resist ask/remark in order to gain a better
understanding of what you meant when writing the following :
2009/2/5 mikel
> On Feb 1, 7:22 pm, David Nolen wrote:
> >
> > (time (dotime
On Feb 1, 7:22 pm, David Nolen wrote:
> I've changed the name of my project since that was a joke
> anyway.http://github.com/swannodette/spinoza/tree/master
>
> Spinoza isn't just for people who want object oriented behaviors. It's also
> for anyone who plans on instantiating many structs. S
Haha, nope that's probably beyond the scope of what I'm trying to achieve.
Spinoza just adds some object orientedness to struct-maps that's all. As
far as I can tell there not much explicit control over memory consumption in
Clojure.
On Tue, Feb 3, 2009 at 2:56 PM, Bradbev wrote:
>
> On Feb 1,
On Feb 1, 5:22 pm, David Nolen wrote:
> I've changed the name of my project since that was a joke
> anyway.http://github.com/swannodette/spinoza/tree/master
>
> Spinoza isn't just for people who want object oriented behaviors. It's also
> for anyone who plans on instantiating many structs. Spi
On Mon, Feb 2, 2009 at 11:10 AM, David Nolen wrote:
> Just to be clear make-instance is a macro on struct:
Ah! That wasn't clear to be before. I thought you were making a case
for plain maps being more efficient than struct-maps.
--
R. Mark Volkmann
Object Computing, Inc.
--~--~-~--~-
Just to be clear make-instance is a macro on struct:
(defmacro make-instance
"Takes a defclassed struct-basis and creates a struct. Initializes
properties to default values."
[aclass & initializers]
(let [class-key (eval (make-pair aclass))
class-sym (symbol (name aclass))
Hey, it is an extremely simplified example ;)
Which is more readable in the long run?
(struct sprite ::foobar 98 ::hunta ::laser [5.5 3.3] 4.01 78)
or
(make-instance foobar :id 98
:mode ::hunta
:weapon ::laser
On Sun, Feb 1, 2009 at 7:22 PM, David Nolen wrote:
> I've changed the name of my project since that was a joke anyway.
> http://github.com/swannodette/spinoza/tree/master
>
> Spinoza isn't just for people who want object oriented behaviors. It's also
> for anyone who plans on instantiating many
In your example, why are you using struct-map to create your structs
instead of just using struct?
(struct rect-struct ::rect [50 50] 100 190)
produces the same struct, but is about three times faster than using
struct-map.
(time (dotimes [x 100]
(struct-map rect-struct :tag ::rect
I've changed the name of my project since that was a joke anyway.
http://github.com/swannodette/spinoza/tree/master
Spinoza isn't just for people who want object oriented behaviors. It's also
for anyone who plans on instantiating many structs. Spinoza's make-instance
macro automatically orders y
29 matches
Mail list logo
