Have thoughts about this, will have to collect them, will reply soon.
On Thu, Feb 5, 2009 at 9:06 PM, mikel <mev...@mac.com> wrote:
>
>
>
> On Feb 5, 7:12 pm, David Nolen <dnolen.li...@gmail.com> 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 example in Spinoza you have pose-as which changes the class
> of
> > an object. The primary purpose of Spinoza is structural inheritance and
> > basic dispatch on type, but I've been thinking about runtime modification
> > and your post gives me a lot of ideas.
> >
> > > (make-thing {:models [::vehicle ::airborne]
> > > :protocols [::thing ::idea]
> > > :inits {:name "test-thing1" :number 1}})
> >
> > Something like this would be quite simple to build on top of Spinoza.
> Also
> > allowing protocols to be defined at class definition time and runtime
> would
> > work the same way that pose-as works
> >
> > (adopt-protocol obj ::some-protocol ::another-protocol)
> >
> > > Note that no classes are involved. The thing in question is not an
> > > instance of any class (except incidentallly, by virtue of the fact
> > > that Clojure's runtime is built on the JVM). I never defined any
> > > classes, nor did I wish to. A class definition would have been just an
> > > obstacle, not directly relevant to my goal, which was to instantiate
> > > an object that reflects these models and participates in these
> > > protocols.
> >
> > As I'm alluding above, this direction seems prototypal, and I've been
> > thinking about allowing for these kind of behaviors in Spinoza.
> >
> > Of course no collaboration beyond healthy discussion is expected. Thanks
> > for bringing the topic up again :)
>
> It's not quite the same as the usual prototype-based systems either.
> Generally, in a protoype-based system you have one of two inheritance
> schemes:
>
> 1. structure and behavior are copied (inherited) from one or more
> prototypes (or "parents"), as in Javascript
>
> or
>
> 2. structure is copied from one prototype (the "data parent");
> behavior is copied from another (the "behavior parent") as in Self
>
> The model/protocol/thing stuff does not use parent objects at all. It
> collects field specifications from model objects, but no inheritance
> relationship is established. It uses the protocols to establish
> multimethod dispatch in the manner of derive, but no delegate object
> is used.
>
> Ruben Kleiman's SK8 system had a prototype-based object model that
> would have made it easy to implement all the features of the model/
> protocol/thing subsystem, but his object system was not typical. It
> had more in common with frame systems like KEE than with typical
> class- or prototype-based object models. His object model included per-
> object configurable inheritance (and per-slot configurable accessors--
> in fact, each slot of an object--slot, not value--could itself be an
> arbitrary object with arbitrary model and protocol). I'm not entirely
> sure I want to recapitulate the entire SK8 object model for this
> project, though. :-)
>
> There are a few more things I want to get working:
>
> 1. you should be able to pass a set of map literals as the models
>
> 2. you should be able to pass a set of dynamically computed protocol
> objects (whatever those turn out to be) as the protocols
>
> 3. Given a thing, you should be able to ask it what models it
> represents and what protocols it implements
>
> 4. Given a model and a thing, you should be able to ask whether the
> thing represents the model
>
> 5. Given a protocol and a thing, you should be able to ask whether the
> thing implements the protocol
>
> 6. It should be easy and natural to create models, protocols, and
> things dynamically and without any static declarations being required.
> Classes, if they exist at all, should be optional. It should be
> possible to dynamically create a thing from arbitrary sets of models,
> protocols, and initial map entries (subject to consistency checks).
>
> 7. It should be straightforward to serialize models, protocols, and
> things (this subsystem is not an end in itself, but a component of a
> larger project in which it's important that the data objects be
> amenable to serialization and deserialization, both for storage in
> nonvolatile repositories and for transmission over communication
> channels; getting deserialization right for 3,4, and 5 is a problem
> when 6 is supported)
>
> 8. mutually contradictory models or protocols should be detected when
> used
>
> 9. It should be possible to resolve ambiguous dispatch conditions per
> instance rather than globally (Clojure's derive and prefer-method do
> not support this, but predicate dispatch would make it easy to do)
>
> 10. It should be possible to specialize a multifunction per instance
> (the CLOS feature is called "eql specializers")
>
> Naturally, all these features should come at reasonable cost in terms
> of performance, complexity, and clarity.
>
> It's not clear to me at the moment that Spinoza would make the
> numbered items easier to do, but it it would, then I should be using
> it.
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
