Posts Tagged ‘object-oriented programming’

Sheeple 3.0.2

Tuesday, December 15th, 2009

It’s taken a while to get this release out — we kept adding stuff on — but it’s finally out. Even though it’s a minor version bump, there’s some important API changes with this new version, including the complete removal of ADD-PROPERTY. Originally, I thought it would be a good idea to force users to add a property manually before being allowed to set a value. Then I realized that the Python community has had this ability for a very long time. The freenode Pythonistas seemed to pretty consistently agree that it had never caused serious problems. Thus, A-P is gone, and (SETF PROPERTY-VALUE) is now used to both add a property, and to set a value on existing ones.

There is also now a manual! A pretty one in both PDF and HTML form, which can be found at our new project page on common-lisp.net. There’s also some mailing lists on that page you might want to sign up for if you feel like tracking Sheeple development.

Things have slowly been ramping up. Ever since I gave that talk at the TC Lispers meeting, a few other people have given Sheeple a whirl. I’m pleased that their experiences have been good, even though Sheeple is still a bit unstable. Of particular note is Patrick Stein’s Wooly, a GL-based GUI toolkit using Sheeple objects.

Development has slowed down a bit since I started working at Clockwork, but I’ve been working with Adlai lately towards a native-Sheeple MOP. So far, the basics of object creation have been taken care of, and a property MOP should be up and running soon. We’ve also decided to rename persistent-sheeple, but that will get announced once we have enough of a MOP to hook up our objects to CouchDB.

Tags: , , , ,
Posted in lisp, releases, sheeple | Comments Off

Sheeple MOP

Wednesday, August 5th, 2009

There’s been some work done on Sheeple’s MOP, and I figured I’d write a bit about what got done today…

The original reason for writing Sheeple, like I said before, was to use it with Sykosomatic (which I still haven’t written an entry for, meh). That said, Sykosomatic’s object system needs to be fully persistent. Sheeple itself is not persistent — it works like a standard run-time object system.

Because I’m a masochist and a nerd, I figured I’d simply write Sheeple as the regular object system that it is, then “just” add a Metaobject Protocol like CLOS’ once the base language was set. Ho boy, did I ask for trouble. MOPs are a royal pain in the ass to do properly, and they’re a bit mind-bending. Regardless, Sheeple has been slowly getting MOP features over time. The neat part? The MOP itself is written in CLOS (as are a lot of Sheeple’s internals).

What I managed to get done today is the protocol for manipulating properties and property behavior through property metaobjects.

To show how it works, let’s go over an example of how one might implement persistent-sheeple, so maybe the damn thing can actually be used for Sykosomatic…

(in-package :sheeple-user)

(defvar *max-oid* 0)
(defclass persistent-sheep (standard-sheep)
  ((oid :initform (incf *max-oid*) :reader oid)))

(defclass persistent-property (standard-property) ())

The first step to changing behavior is to make some subclasses. We’ll be dispatching on these.

(defmethod initialize-instance :after ((sheep persistent-sheep) &key)
  (allocate-sheep-externally sheep))

(defmethod add-parent :around ((new-parent standard-sheep)
                               (child persistent-sheep))
  (if (or (eql new-parent =dolly=)
          (eql (find-class 'persistent-sheep)
               (class-of new-parent)))
      (progn
        (call-next-method)
        (add-parent-externally new-parent child))
      (error "We don't support adding non-persistent~
              sheep as parents!")))

The first and most important part of having a persistent object is that it’s somehow allocated externally. All Sheeple are standard CLOS instances, so this method will get called each and every time the sheep object is created.

We also go ahead and write a method for add-parent. This is important because we want to make sure that we can successfully serialize the sheep. We must always have at -least- =dolly= as a parent, so we have to make an exception for that. Other than that, no non-persistent sheep are allowed into a persistent-sheep’s hierarchy list. Note that methods defined on add-parent must not override the standard behavior (basically, the (standard-sheep standard-sheep) method must always be called). Other than that, clients are free to go wild with what they do with this one.

With this much code (aside from serialization and db-management stuff!) we can now have externally-stored sheep objects. The rest of sheeple will work normally at this point. The whole point of persistent-sheeple, though, is to be able to store property values externally, so here we go… 

(defmethod add-property :around ((sheep persistent-sheep) pname
                                 value &key transientp)
  (register-property-externally sheep pname)
  (if transientp
      (call-next-method)
      (call-next-method sheep pname value
                        :property-metaclass 'persistent-property)))

(defmethod add-property-using-property-metaobject :before
    ((sheep persistent-sheep) value
     (property persistent-property) &key)
  (allocate-property-externally sheep pname))

Because Sheeple requires that properties be specifically added to the hierarchy-list, we have these two functions: The first one takes care of creating a property metaobject for the second one to dispatch on. In this case, we make our :around method on add-property accept a keyword that tells it whether a property should be transient or not.

For the purpose of this exercise, we assume that a transient property is simply a regular property on a persistent-sheep. Since we want to make sure we’ve got the property available when we restore the database, though, we register its existence regardless of whether it’s transient or not.

Next up, in a-p-u-p-m, we actually dispatch on the property object itself, instead of just the class. This :before method sits there to make sure we have external DB space to allocate a value on, since we’re sure in this case that we’ll be assigning actual values to this one.

Once that’s set, it’s just a matter of making sure we can get/set those values, and we’re home free…

(defmethod direct-property-value ((sheep persistent-sheep)
                                  (property persistent-property))
  (get-property-value-externally sheep (property-name property)))

(defmethod (setf property-value) (new-value (sheep persistent-sheep)
                                  (property persistent-property))
  (set-property-value-externally sheep (property-name property)
                                 new-value))

And that’s it. We override the standard getting/setting behavior so nothing is set locally: Storage lives in the database.

Keep in mind here that a built-in :before method for (setf property-value) will take care of calling add-property as appropriate when the sheep object does not have a direct property metaobject registered for that property-name.

Now we can actually use it:

(defproto =psheep= ()
  ((foo "bar")
   (baz "quux" :transientp t))
  (:metaclass 'persistent-sheep))

(note: defproto changed a bit in recent commits, more on that later…)

And there you have it! (setf (foo =psheep=) "Blargh") is all it takes to start changing stuff in your new persistent sheep. The rest of sheeple will work as expected. It’s worth noting that roles belonging to this object won’t be persisted, since we only messed around with object creation and properties.

Discussion

While I’m very pleased that the MOP has come this far, I have to admit that it probably doesn’t work very well right now. It’s very new, and very much still a work-in-progress. There’s probably certain things that could be cleaned up and all that, but I think it’s certainly a step in the right direction.

I’m honestly not entirely sure what I’m doing half the time. Even though I’ve read through AMOP several times, some of this is still a bit confusing, and I haven’t actually used CLOS’ MOP very much at all. I’m playing it by ear (with a hell of a lot of help from the debugger!)

Hopefully, as the MOP grows (and evolves), it’ll settle into something generally useful. For now, though, YMMV if you want to mess with it.

Tags: , ,
Posted in lisp, sheeple | Comments Off

Sheeple continued: Dispatch

Monday, July 20th, 2009

In the last entry, I wrote a bit about the basics of how object instantiation and property/slot access works in Sheeple. In this entry, I’ll introduce a whole different realm of Sheeple: the method dispatch system. If you’re familiar with Javascript, it might already be obvious to you how polymorphic method dispatch can be implemented with the small bit of Sheeple we know so far:

SHEEPLE-USER> (add-property *sheep* 'foo
                            (lambda ()
                              (print "Method called!")))
#<Sheep #x15031356>
SHEEPLE-USER> (foo *sheep*)
#<Anonymous Function #x1506C446>

For those confused: the above equivalent in javascript would be:

sheep.foo = function () { alert("Method called!"); }
sheep.foo -> function object

And there you have it. Actually calling the function is just a matter of using Lisp’s version of adding () at the end of a variable:

SHEEPLE-USER> (funcall (foo *sheep*))
"Method called!"

In JS:

sheep.foo(); => an alert pops up. The method was called.

Nothing new here. It’s cute and all, but Sheeple has a much nicer facility for defining ‘methods’. I’ve opted to call these “Messages/Replies.” For those familiar with CLOS, the basic concept is exactly like Generic Functions/Methods. In fact, I would have named them the same thing, but I wanted to be able to operate in parallel with CLOS — which I do regularly. The big deal about these message/replies is that, instead of dispatching on a single value (whichever object holds the function that will be called), method lookup involves 0 or more arguments. The semantics, of course, end up being more complex than the singly-dispatched approach, but it opens up a world of possibilities and expressive power (not to mention completely obsoletes the Visitor pattern).

The concept of messages/replies is as follows: You have something called a ‘Message’ that works like a generic dispatcher. It defines the basic idea of what arguments to this function should look like, and it defines which arguments will be dispatched on. It does some other things, but the important part here is that Messages work like interfaces (no-implementation definitions) for replies that will be defined.

In Smalltalk terms, a Message is passed to not necessarily just one object, but to multiple objects, and the code that is run is whatever the collective Reply they agree on to that message is.

SHEEPLE-USER> (defmessage synergize (a b))
#<Message: SYNERGIZE #x150A23DE>

This gives us an empty message. As far as Lisp is concerned, it can be called just like any function.Right now, though, it won’t be able to do anything, (It will signal an error saying there are no applicable replies) because we haven’t defined any replies for it, so let’s define one.

SHEEPLE-USER> (defreply synergize ((a (proto 'number))
                                   (b (proto 'number)))
                (+ a b))
#<Reply: SYNERGIZE #x150433F6>

This reply specializes the arguments A and B on (proto ‘number), which is an abstract object that represents all numbers. This means that if SYNERGIZE is called with its first and second arguments being numbers, the body of this reply will execute.

SHEEPLE-USER> (synergize 5 2)
7

We did numbers, but what does it mean to ’synergize’ strings?

SHEEPLE-USER> (defreply synergize ((a (proto 'string))
                                   (b (proto 'string)))
                (concatenate 'string a b))
#<Reply: SYNERGIZE #x150B4A76>
SHEEPLE-USER> (synergize "foo" "bar")
"foobar"

So far so good. Now we can start mixing and matching and seeing what kind of behavior we end up with. A more

SHEEPLE-USER> (defreply synergize ((a (proto 'string)) b)
                (concatenate 'string a
                             (format nil "+object: ~A" b)))
#<Reply: SYNERGIZE #x150B49F6>
SHEEPLE-USER> (synergize "foo" 45)
"foo+object: 45"

By not wrapping our parameter in parens, we default to the toplevel object in the Sheeple hierarchy: (proto ‘t). This means that this reply will be applicable when -any- lisp object is given as the second argument to SYNERGIZE. This is essentially single-dispatch, except our old string-string reply will still apply, since it’s more specific than this general one:

SHEEPLE-USER> (synergize "foo" "bar")
"foobar"

As a note: dispatch is left-weighted, so higher specificity to the left of the argument list (lambda list in lisp terms) will outweigh higher specificity in arguments to its right. The algorithm itself is based on Slate’s description of Prototype Multiple Dispatch (PMD, take a look at Fundamentals). Sheeple supports much more than what I’ve shown. It has :before, :around, and :after replies (which have identical semantics to the way CLOS handles them), and has a mechanism for handling &key, &rest, &optional, and company (which, again, works identical to CLOS’ facilities).

The big difference, in the end, between CLOS and Sheeple is that Sheeple dispatches everything on actual objects. It’s like defining all CLOS methods with EQL specializers in a world where the objects themselves hold the hierarchy. The biggest implication of this, I think, is that the hierarchy never bottoms out — and that’s quite useful when you’re developing.

Next time, I’ll start talking about how development with Sheeple actually works. I’ve written a couple of applications using it, and there’s been some good lessons learned from those — which have then reshaped the way Sheeple works. Questions so far? Leave a comment! Or just check out Sheeple’s documentation.

Tags: , , , , ,
Posted in lisp, sheeple | Comments Off

Sheeple

Sunday, July 19th, 2009

For a few months now, I’ve been working on something I call Sheeple. What is Sheeple? From the
official description:

Sheeple is a Dynamic, CLOS-like, Delegative Prototype-based Object-Oriented Programming
Framework (or “POOP Framework”) that strives to optimize application flexibility, minimize cost
while increasing value, maximize programmer resources, and empower application implementers to
better assist them in leveraging modern paradigms in order to proactively achieve next-generation
synergy in tomorrow’s web 3.0 world. It is implemented in (mostly) ANSI Common Lisp. Sheeple is
fully buzzword compliant.

Now that doesn’t really say much of anything, but it’s
amusing, specially since some actual (professional!) projects actually describe things in such a
way.

What does it actually do, though?

Well, Sheeple is a library for Common Lisp that implements a Prototype-based object-oriented language very similar to Common Lisp’s standard CLOS. It does things like multiple dispatch, multiple inheritance and such.

One goal I had while designing it was to have it be as practical as possible. Javascript is making waves around the internet these days — not just because it’s the de-facto standard browser-scripting language, but because it’s prototype-based.

The idea of having a prototype-based language instead of using classes for OO is nothing new. Even so, it seems like there’s still debate about the merits of using prototypes instead of classes. In fact, some prototype-based languages, specifically Javascript, have libraries that implement classes!

Even though there are various languages to choose from, there are still few languages that provide what I would consider full facilities. Cecil seems to be one of those ‘full’ languages, but I really ended up disliking its approach — it was too complicated, and there were too many obvious minefields. Sheeple is an attempt at providing the kind of massive framework CLOS provides for class-based OO, but with prototypes, while remaining easy-to-use, straightforward, and most importantly, convenient. Whether it’s successful at this right now (it’s still in development after all), and whether it will ever be is a different question. ;)

Here’s some basic sample code, from the docs:

The CLONE function called with no args creates a regular sheep object with DOLLY as its only parent object.

SHEEPLE-USER> (defparameter *my-sheep* (clone))
*MY-SHEEP*

Sheeple (I refer to single objects as ‘a sheep’, and multiple objects as ’sheeple’) are, at the basic level, simply glorified hash tables: key/value stores that can be changed at runtime. Every property a sheep object has is named by a symbol.

SHEEPLE-USER> (add-property *my-sheep* 'var "value")
#<Sheep #x1508F91E>
SHEEPLE-USER> (var *my-sheep*)
"value"

A relationship hierarchy in the style of super/subclasses is created by simply cloning an existing object.

SHEEPLE-USER> (defparameter *child* (clone *my-sheep*))
*CHILD*

You can think of the way this new object works as “It’s just like its parent, but X, Y, and Z are different.”
This is called differential inheritance. Sheeple, unlike other languages that follow the prototype model for OO, such as Slate or Self, does differential inheritance by default, making it more like Io in that sense.
To understand how differential inheritance works, look at this example:

SHEEPLE-USER> (var *child*)
"value"

Here’ we can see that the value of child’s VAR property is the same value that *my-sheep* had in that property.
The funky awesome stuff comes when we change the parent object in some way:

SHEEPLE-USER> (setf (var *my-sheep*) "new-value")
"new-value"
SHEEPLE-USER> (var *my-sheep*)
"new-value"
SHEEPLE-USER> (var *child*)
"new-value"

As you can see, changing the value of one of the parent object’s properties changes the value *child* sees whenever it tries to access that property. This maintains the “*child* is just like *parent* relationship, although it has some other benefits that I like (which I’ll discuss in a later post about differential inheritance).

But what if we never intended for *child*’s var property to change?
In that case, all we would have to do is set that property in *child*, and the change in *my-sheep* would never have affected it.

SHEEPLE-USER> (setf (var *child*) "my-own-value"
"my-own-value"
SHEEPLE-USER> (var *child*)
"my-own-value"

In general, the design I’m aiming for is “parents can change their own behavior, which can affect children, but they cannot directly touch the children, nor can children touch them”… or something like that. The truth is that differential inheritance can be a bit tricky to understand, and there’s some major caveats. Once you really get why it’s useful, and know how to avoid pitfalls, though, I think it can turn into a genuinely useful tool.

In a later post, I’ll write about Sheeple’s method dispatch mechanism, which is based on Slate’s PMD, and why you want it. If you’re too impatient, just check out Sheeple’s code on github, and skim through doc/user-guide.org, which is a bit of a working spec of a good chunk of the language.

Tags: , , , ,
Posted in lisp, sheeple | 4 Comments »