From b796d64313edd66af1db08384cd33761dd53e156 Mon Sep 17 00:00:00 2001 From: clinton Date: Fri, 30 Jan 2009 09:06:24 +0000 Subject: [PATCH] * Quick spell check of the metaobject protocols page I was using this page to test my print stylesheets and so have been staring at my own horrible spelling mistakes for days. I added a link to CloserMOP at the end so that no one yells at me for this generating an RSS feed entry. --- Metaobject Protocols.muse | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/Metaobject Protocols.muse b/Metaobject Protocols.muse index 2af221c..d975253 100644 --- a/Metaobject Protocols.muse +++ b/Metaobject Protocols.muse @@ -47,7 +47,7 @@ Classes are defined with =defclass= ((bar :accessor bar-of :initform (list 1 2 3)))) -Slot defintions have several options; the above example shows only the +Slot definitions have several options; the above example shows only the =:accessor= and =:initform= options which are the most commonly used. =:accessor= generates an accessor for the slot (e.g. if you have an instance of =example= you can =(setf (foo-of some-example-instance) @@ -123,7 +123,7 @@ Design Patterns are generalized versions of common patterns found in programs. Many of them are merely methods to get around deficiencies in the language, and can be quite messy to implement in some languages. Ideally a pattern would be subsumed by the language, but -real world contraints require language standards to remain fairly +real world constraints require language standards to remain fairly static. * Metasoftware @@ -225,7 +225,7 @@ Intercessory MOPs allow the user to customize language behavior by implementing methods which override certain aspects of the language behavior. This class of MOPs are what make MOPs especially powerful. No longer must a problem be restructured to fit the -implementation language; the underyling language can be reshaped to +implementation language; the underlying language can be reshaped to fit the task at hand, and obfuscation of the intended structure of the application can be avoided. @@ -239,17 +239,17 @@ any existing class observable. In a language lacking a MOP, implementing the observer pattern requires modifying every accessor of a class to explicitly invoke any -observers, and neccesitates the addition of a mixin class to the class -heirarchy. The fact that an object can be observed is a meta property +observers, and necessitates the addition of a mixin class to the class +hierarchy. The fact that an object can be observed is a meta property of the class, and forcing it to be implemented at the application -level dirties the inheritance heirarchy and adds uneccesary meta +level dirties the inheritance hierarchy and adds unnecessary meta details to the program. ;;; This metaclass adds a slot to instances which use it, and so the ;;; system is defined in its own package to avoid name conflicts (defpackage :observer - (:use :cl #+sbcl :sb-mop) + (:use :cl :c2mop) (:export observable register-observer unregister-observer)) (in-package :observer) @@ -410,12 +410,12 @@ the implementation to return large data structures by reference to avoid expensive copying without having to do expensive data integrity checks or copying. -** Procedural Only Where Neccesary +** Procedural Only Where Necessary -Some operations like method invocation are inheretly stateful and so +Some operations like method invocation are inherently stateful and so must use a procedural protocol. There is no benefit to be gained from using a functional protocol, and indeed an attempt would result in -obtuse code that severely restricted the implementian. Do note that +obtuse code that severely restricted the implementation. Do note that only a very small part of method invocation is stateful (the actual call), and most of it can be implemented functionally (e.g. computing the discriminating function). @@ -424,7 +424,7 @@ the discriminating function). *** [[http://common-lisp.net/project/ucw/][UCW]] and [[http://common-lisp.net/project/bese/arnesi.html][Arnesi]] -Arnesi uses the CLOS MOP to implement methods which are transparantly +Arnesi uses the CLOS MOP to implement methods which are transparently rewritten into continuation passing style. This allows their execution to be suspended at certain points and resumed later. UCW builds on top of this to support a web framework where the statelessness of http is @@ -441,7 +441,7 @@ implementing relational slots). *** [[http://common-lisp.net/project/elephant/][Elephant]] -Elephant uses the CLOS MOP to transparantly store any class to disk +Elephant uses the CLOS MOP to transparently store any class to disk and handle paging between the disk store and memory efficiently without user intervention. @@ -486,3 +486,11 @@ of a code walker and something similar to the Lisp macro system. It is a bit long, but it seems to follow a similar structure to AMOP in introducing MOPs and their usefulness. The pages are slides with notes, and so the 331 pages might not actually take that long to read. + +** Software + +*** [[http://common-lisp.net/project/closer/closer-mop.html][Closer to MOP]] + +Compatibility layer that attempts to present the *Art of the Metaobject +Protocol* MOP specification properly in as many Common Lisp +implementation as possible. -- 2.20.1