Re: EIEIO built in methods -- question

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> There's not a lot of documentation out there about using EIEIO, so I
> want to check something. First of all I'm using emacs-version "24.3.1"
> (the archlinux package).

That's because it just tries to emulate CLOS.  Use the Hyperspec or
other Common Lisp tutorial or book covering OOP.

http://www.lispworks.com/documentation/HyperSpec/Body/c_object.htm


> This is so everyday in Python (the other language I have experience in)
> and so weird to me in (e)lisp that I'm experiencing a kind of cognitive
> clash, and want to make sure I'm not doing something very wrong. 

All right.  But what is it you want to do?


> How does
> this look to anyone who knows EIEIO (or I guess CLOS)?:
>
> (defclass persistent-thing (eieio-persistent)
>   ()
>   :documentation "Just for testing, :file slot comes from the superclass")
>
> (defmethod constructor :static ((thing persistent-thing) newname &rest slots)
>   (let ((filename (plist-get slots :file)))
>     (when (member filename my-big-bad-list-of-filenames)
>       (error "There's already a thing writing to %s" filename))
>    (apply 'call-next-method thing newname slots)))
>
> Is this how we should be doing it? 

What "it"?


> Essentially, Python's "**kwargs"
> turns into "&rest slots" --> (apply 'call-next-method .... slots).

Yes, lisp &rest has been translated to python **.


> I'd be interested in writing up a small introduction about how to use
> "internal" methods, ie methods on the eieio-default-superclass. 

The way to use "internal" methods is to NOT use them!
That's why they're internal, because external code don't, must not,
should not use them!


> So far I've messed with constructor, destructor, object-print, and I
> guess initialize-instance (oooh, damn, I just realized I should
> probably be using initialize-instance rather than constructor in my
> above example).  There are several more I haven't experimented with,
> but that should be documented.
>
> If I make a documentation patch against the manual, will someone with
> actual EIEIO/CLOS experience take a look at it?

So I still don't know what you want :-(


-- 
__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