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 is trying to implement other types of protocols, each protocol has the option to at least implement its own dispatch mechanism. The underlying data object can then perhaps then be represented and manipulated in several different protocols. The article he linked to is somewhat clear on this. Also check out: http://en.wikipedia.org/wiki/Metaobject http://en.wikipedia.org/wiki/Common_Lisp_Object_System Chris On Feb 5, 5:36 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > 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 <mev...@mac.com> > > > > > On Feb 1, 7:22 pm, David Nolen <dnolen.li...@gmail.com> wrote: > > > > (time (dotimes [x 1000000] > > > (make-instance rect :height 100 :width 150))) > > > > > ~280ms > > > > (defstruct rect-struct :tag :position :width :height) > > > (time (dotimes [x 1000000] > > > (struct-map rect-struct :tag ::rect :position [50 50] :width 100 :height > > > 190))) > > > > > ~800ms > > > > Also, it is now available under an MIT license, feel free to fork, send > > > patches at will etc. > > > I'm still quite interested in this project, and I'm tempted to try > > rewriting a subsystem in my own main project with it, but in the > > course of developing some behavior that I needed, I went off in a > > slightly different quasi-object-like direction. If I were going to add > > something to Spinoza, it would be eql specializers. > > > I'm not going to add anything to Spinoza, though, at least not right > > now; instead, I'm going to keep working on my own model/protocol/thing > > subsystem. Similar to Spinoza, it uses maps to represent objects; > > objects are called 'things'. A thing has a 'model' and a 'protocol'. > > The model determines what fields the thing has, and whether there are > > any type restrictions on the values; the protocol determines what > > operations (that is, what multifunctions) work on the thing. > > Doesn't that sound like multifunctions whose dispatching is tied to the > type ('model') of a 'thing' ? > And if this is correct, in what does it differ from the concept of interface > in Java ? > > 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 order to > > satisfy a need I had in a larger project, I think I'll push ahead with > > it a bit to see whether it's worthwhile. > > Once again, does'nt this correspond to the introduction of the interface > concept in java ? > Or, asked differently, compared to what you're thinking about, what does the > java 'interface' concept lack ? > > > If I were going to add one thing to my own model/protocol/thing > > subsystem--or add one thing to Clojure to support it--it would be > > predicate dispatch. Who knows? Maybe I will, if I decide that I want > > it badly enough. > > -- > Cordialement, > > Laurent PETIT --~--~---------~--~----~------------~-------~--~----~ 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
