nklein software

• Deprecated
• Overview
• Obtaining
• Comparison to ContextL
• Protocol Example
• Internationalization Example

Deprecated

When I wrote this library, I had read about ContextL and decided that I only wanted a very small subset of it and wanted it to be very easy to use. It turns out that I didn’t quite understand the complexity-level of ContextL. It is actually very similar to what I have described below.

With this library, you set up some versions and a variable to track the current version:

In ContextL, you just set up some layers:

In my library, you then set up a generic function that uses a special method combination that keys off of the special variable:

In ContextL, you declare a layered function:

In my library, you then declare different methods using the version as a method qualifier.

In ContextL, you declare layered methods specifying which layer the functions belong to:

In my library, you set your special variable appropriately and invoke the method:

In ContextL, you declare which layer you want to be active when you go to invoke the method:

The library below does not let you specify other method qualifiers like :around or :after. ContextL does.

I am going to leave this library published because I think it is a reasonably understandable, yet non-trivial, use of non-standard method combinations. However, I am going to end up using ContextL for the projects that I had intended for this library.

Overview

There are situations where one might like to dispatch a method on some information other than the required parameters of the method. For many situations, it is sufficient to switch between those methods based on some external parameter. The method-versions library allows one to do just that.

For more complicated situations where one also wants to turn on and off slots within classes, one might prefer ContextL. For situations where one wants to dispatch a method based on predicates on the arguments, one might prefer Filtered Functions.

Obtaining

• The home page: http://nklein.com/software/method-versions/
• The tar-ball: method-versions-0.1.2011.05.18.tar.gz
• The GPG signature for the tar-ball: method-versions-0.1.2011.05.18.tar.gz.asc
• The main git repository: http://git.nklein.com/lisp/libs/method-versions.git
• A browsable mirror of the git repository: http://github.com/nklein/method-versions

Comparison to ContextL

The ContextL library provides:

• user-defined layers
• methods defined differently in different layers
• functions defined differently in different layers
• slots only available when certain layers are active
• reflective layer activation allowing one to:
  • make layer A depend on layer B
  • make layer B exclusive with layer C
  • etc.

For the serialization, logging, and network protocol requirements that I expect to need in some of my other projects, ContextL seemed like overkill. This library does a very small portion of that. Its only goal is to allow a hierarchy of method definitions and selecting a particular point in the hierarchy.

Protocol Example

The method-versions library provides a method-combination one can use to create multiple versions of a method and switch which one is invoked through a special variable.

For example, suppose you were working on a protocol for a simple client-server application. You may have methods like this:

After a few months of beta-testing, you want to extend the login command to include a geographic location. If you just update your send-cmd and recv-cmd methods for the login-cmd, then you will have to jump through all kinds of hoops to make sure that you can handle receiving a login command from users with the new send-cmd in their binary and users with the old send-cmd in their binary.

You can use the method-versions library to create a version of your server that can handle both versions in a sane manner.

First, you define a version for the new variant of your protocol.

Note: The define-method-version accepts an optional second parameter which specifies the parent version. So, for future expansion, one could end up with the following:

After you have established your versions, you define a special variable which will track which version of your methods you would like to use during any given invocation and declare your generic method to use the method-versions-method-combination with your tracking variable.

Next, you declare your default versions as before and declare your :v1.0 versions using the version as a method qualifier. (For brevity, we only show the recv-cmd here, but the send-cmd is similar.)

Now, if you want to receive a message coming in from a client who is using the original version, you would ensure *protocol-version* is set to nil and then invoke the recv-cmd method.

For clients who are using the new version, you would set the *protocol-version* appropriately and then invoke the recv-cmd method.

Of course, you will have to know which version of the protocol the client is sending. We recommend that you assume the client is using the default version and add a message to your connection establishment phase where the client tells the server what version the client is using.

Then, use that version when receiving subsequent commands from that client.

Internationalization Example

In this example, we do a silly form of internationalization. To that end, we will use English as the default language and define some other languages.

We will prepare a language parameter and a welcome method that is versioned on the language.

And, we define welcome methods for the various languages (accidentally forgetting spanish).

Then, we will try each of the languages in turn.