Re: EIEIO built in methods -- question

[David Engster <deng@randomsample.de>]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> 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

There's a lot to learn out there. Unfortunately, time is sparse, and
CLOS is not an itch I need to scratch at the moment.

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

Yes, I admit I keep forgetting that. Must be because of my C++ dayjob...

[...]

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

It's the latter I was suggesting.

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

I think this is a wrong and unfair description of what EIEIO is and how
it was developed, but I see no point in discussing this further. We try
to list the deficiencies of EIEIO compared to CLOS so nobody has to
waste time finding out it doesn't suit his needs, but obviously things
are missing, and I will add your points when I have time to do so. If
you have more issues that should be listed in the documentation, please
let me know.

-David