Re: EIEIO built in methods -- question

[Pascal J. Bourguignon]

David Engster <deng@randomsample.de> writes:

> If you could provide a doc-fix for the EIEIO section regarding CLOS
> compatibility, that would be much appreciated, since you know much more
> about CLOS than I do.

Unfortunately, I won't have the time to do so for the foreseable future
(new job, etc).  But if you try to do it yourself you'll learn a lot
(read the Hyperspec, and/or about the MOP
http://www.alu.org/mop/index.html
(not that eieio tries to implement the MOP, but it'll give you some
perspective, and some other references;
http://www.dreamsongs.com/CLOS.html
).



>> So instead of using make-instance to get your persistent-things, use
>> your own function that will test for singletons:
>>
>>
>> (defvar *file-things-map* (make-hash-table :test (function equal)))
>>
>> (defun make-persistent-thing (&rest arguments)
>
> [...]
>
> Well, in some other OO languages, these singleton classes are usually
> implemented through static members. AFAIK, in CLOS you also have these
> in the form of slots with class allocation, which is also supported by
> EIEIO. In fact, if you look at the eieio-singleton class, this is also
> how it is implemented there.

Yes, for slots.

But remember that methods are not attached to classes or objects in
CLOS, but to generic functions.

It's the generic functions who have methods, to implement themselves
according to the classes of its argumentS. <--  Yes, it means multiple
dispatch, in CLOS, but eieio lost all veleities of implementing multiple
dispatch (an earlier version could do it, if badly, but not the later
version).

Anyways, if generic function dispatch on the class, then "static
methods" are mere lisp functions.  Hence (defun make-<your-class> ...)

Also, remember that in lisp, things are orthogonal: there's no confusion
of name spaces and classes.  If you want a "static method" in a name
space along with the other methods of the class, then you just put the
symbols naming them in a separate package.  Ah yes, emacs lisp doesn't
implement (yet?) packages… Only obarrays, and since it has no reader
macro, some C hacking will be required to implement packages in emacs
lisp (or metalinguistically, as emacs-cl does it).

Anyways, you can name them:

(defun <my-class>-new (...) (make-instance '<my-class> ...)
(defclass <my-class> ()
  ((<my-slot> :accessor <my-class>-<my-slot>)))

so that the prefix <my-class>- is your namespace.

Remember, what :accessor does, is to define for you:

(defgeneric <my-class>-<my-slot> (object))
(defmethod <my-class>-<my-slot> ((object <myclass>))
  (slot-value object '<my-slot>))
(defmethod (setf <my-class>-<my-slot>) (new-value (object <myclass>))
  (setf (slot-value object '<my-slot>) new-value))

;; that's all.


By the way, I don't know the code base of PCL, but now that emacs has
lexical closures, it may be portable to emacs lisp without too much
pain.



> So, I guess you could implement a more specific singleton which check
> for the :file slot through something like this:
>
> (defclass persistent-thing (eieio-persistent)
>   ((allfiles :type list :initform nil
>            :allocation :class)))


Well you see, the problem of :allocation :class is that you need an
instance to access it.  When you're trying to construct an instance, you
may not have one to get the :allocation :class slot.  Or you can do the
test after allocating the instance, but it's suboptimal.


> Not as elegant as the "true CLOS-way", but it should work.

If it does, it does.


>> But let's not critisize eieio authors.  AFAIK, they've just applied
>> usual Agile directives, implementing an object system only to fulfill a
>> very definite and limited goal, that of implementing cedet.  Their
>> product manager never had a budget to schedule a sprint about
>> implementing CLOS in emacs lisp.  The customer only wanted cedet, not
>> CLOS (and if he wanted CLOS, he would know where to find it).
>
> I guess you're speaking tongue in cheek here, still it should be
> mentioned that there was no "they". It's pretty much all Eric Ludlam's
> code, and I don't think agile directives were around in the mid
> 90's... :-)

Yes, it's just that it reflects a mentality that is not often found in
lisp culture.  Lisp culture is rather to do the things right (cathedral)
rather than to do them quick, and gain market share and popularity
(bazar).

Both have advantages.  Personnally, I prefer to have fewer choice of
libraries, but when I use one, to find that it is complete, instead of
just implementing what was needed to implement some limited application.




> @Eric: If you'd like to improve the documentation, that would be much
> appreciated. I would definitely read over it, but I'm no expert in
> EIEIO, so it'd be best if you could send your contributions to
> emacs-devel or submit it as a bug report, so that others can also check
> it.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.
You can take the lisper out of the lisp job, but you can't take the lisp out
of the lisper (; -- antifuchs