On Mar 19, 2:13 pm, Rich Hickey <richhic...@gmail.com> wrote:
> On Mar 19, 2009, at 2:14 PM, mikel wrote:
>
>
>
> > On Mar 19, 7:17 am, David Nolen <dnolen.li...@gmail.com> wrote:
> >> Doesn't On Lisp talk about simulating CLOS with closures? It's free
> >> online.
>
> > Building either class-based or prototype-based object systems on
> > closures is pretty straightforward. A closure carries abritrary state
> > around in the closed-over lexical environment. Make the closure
> > function a suitable dispatching function, and you can then use it as a
> > building block to build any sort of object system you like. Probably
> > you then want to write some macros to provide a graceful syntax for
> > interacting with whatever object system it is you've invented.
>
> This style of 'object' system is somewhat complicated/precluded by the
> fact that, in Clojure, locals are immutable, thus any such object
> would be immutable too. That's not what you'll see in the books, where
> closed-over locals act as mutable fields of the object.
Yep, that's true, and a good point. I glossed over it as more-or-less
obvious, but that's a mistake on my part.
> Closing over
> individually mutable things like refs or atoms, while possible, would
> really be missing the point of Clojure's approach to programming with
> values. If someone's going to do an object system for Clojure, it
> should be one in which the entire state of an object is available as a
> value.
There's more than one reason to build an object system. Building a
production object system on closures might not be the best approach
for a number of reasons, depending on what your goals are, but for
someone experimenting with object-system semantics in order to learn
more or experiment with some ideas, implementing objects as closures
over Refs might be a perfectly reasonable approach.
> > The part of CLOS that I actually want is generic functions. I also
> > experimented with making my own gf implementation, then switched my
> > app back and forth between that and Clojure's multifns a few times to
> > see whether I really prefer gfs. Turns out I do, so I'm plowing some
> > more work into the gf implementation.
>
> What specifically about gfs do you miss/prefer?
Implicit specialization on all arguments. Eql specializers. A
completely deterministic method-dispatch algorithm (no need for prefer-
method; the need for hand-tweaking dispatch has been a pain when
trying to design extensible APIs). CALL-NEXT-METHOD. Method-
combination (especially :before and :after methods). No requirement to
separately specify a dispatch function.
I've added a couple of modest extensions to CLOS-style GFs. Although
you don't have to specify a dispatch function, you may if you wish.
There's also a simpler means of customizing dispatch: you can supply a
sequence of matching functions, ordered from least- to most-specific,
and the default dispatch algorithm will use those instead of the
"standard" ones. CLOS parameter matches include wildcard (any value
matches), class, and "eql specializers" (a parameter matches if and
only if it's equal to a specified value). I add matches on user-
specified test functions (the so-called "predicate dispatch"). I also
add the option to specify matching with isa? on a user-supplied
hierarchy, per parameter.
Maybe I've misunderstood how best to use multifns; that would be a
happy discovery. I would cheerfully abandon my gf implementation if I
discovered ways to use multifns that made me stop missing gfs.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
