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
-~----------~----~----~----~------~----~------~--~---
