[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EIEIO built in methods -- question
From: |
Eric Abrahamsen |
Subject: |
Re: EIEIO built in methods -- question |
Date: |
Fri, 14 Jun 2013 09:37:20 +0800 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) |
David Engster <deng@randomsample.de> writes:
> Eric Abrahamsen writes:
[...]
>> Unless there's some potential fatal flaw with this that I'm not seeing,
>> this is precisely the behavior I wanted.
>
> You can of course throw an error. However, this simply shifts all the
> hard work to the *user* of your class. It's him now who has to make sure
> that he is not creating a `persisty' for a file for which this was done
> already, or otherwise his application will throw an error. How he does
> that is up to him, but he has to do it every time he constructs an
> instance.
>
> Wouldn't it be much nicer if the class constructor would simply return
> the *already existing* instance instead? This is the main problem.
Aha! Finally I understand what we're talking about. I hadn't even
considered that as a potential solution to my issue -- I had no idea
what you guys were talking about. In my case I'd almost rather warn the
user that they're trying to do something bad, but I can certainly see
where the silent short-circuiting would be handy. I see what your
previous code is doing now.
There's the eieio-singleton class provided as part of the package, which
does the same thing in principle: only lets you create one instance of
the class. The constructor:
(defmethod constructor :STATIC ((class eieio-singleton) name &rest slots)
"Constructor for singleton CLASS.
NAME and SLOTS initialize the new object.
This constructor guarantees that no matter how many you request,
only one object ever exists."
;; NOTE TO SELF: In next version, make `slot-boundp' support classes
;; with class allocated slots or default values.
(let ((old (oref-default class singleton)))
(if (eq old eieio-unbound)
(oset-default class singleton (call-next-method))
old)))
This is the same idea, yes? I don't know why "name" and "slots" aren't
passed to `call-next-method'.
Anyhow, I appreciate all the ideas and pointers!
Eric
> You can achieve that through different methods, depending on what your
> language offers. The easiest way, which I guess should work in any
> OO-language, is to use a factory method or function. This is also what
> Pascal suggested with his `make-persistent-thingy'. However, this has
> several drawbacks in practice: you have to document it, and ideally you
> should forbid other ways to create objects of your type, which isn't
> always possible.
>
> The `constructor' however actually returns the instance of your
> `persisty', so he can return an already existing object. This is what my
> code did. You should replace the `oref' there with `oref-default',
> though.
>
>> I'll do some more experimentation with class-allocated slots, that's
>> still a bit opaque to me.
>
> This is explained very nicely in Seibel's book.
>
>> I don't think I'm necessarily stuck in Python/C++ etc, but I do think
>> it's helpful to tell people "what it looks like over here".
>
> IMO CLOS really begins to show its powers when you start to use multiple
> dispatch. Unfortunately, EIEIO does not support that...
>
> -David
- Re: EIEIO built in methods -- question, (continued)
- Re: EIEIO built in methods -- question, Eric Abrahamsen, 2013/06/09
- Re: EIEIO built in methods -- question, Pascal J. Bourguignon, 2013/06/09
- Re: EIEIO built in methods -- question, Eric Abrahamsen, 2013/06/09
- Message not available
- Re: EIEIO built in methods -- question, Pascal J. Bourguignon, 2013/06/09
- Re: EIEIO built in methods -- question, David Engster, 2013/06/10
- Re: EIEIO built in methods -- question, Eric Abrahamsen, 2013/06/10
- Re: EIEIO built in methods -- question, David Engster, 2013/06/12
- Re: EIEIO built in methods -- question, Eric Abrahamsen, 2013/06/13
- Re: EIEIO built in methods -- question, Eric Abrahamsen, 2013/06/13
- Re: EIEIO built in methods -- question, David Engster, 2013/06/13
- Re: EIEIO built in methods -- question,
Eric Abrahamsen <=
- Re: EIEIO built in methods -- question, David Engster, 2013/06/14
- Re: EIEIO built in methods -- question, Eric Abrahamsen, 2013/06/14
- Message not available
- Re: EIEIO built in methods -- question, Pascal J. Bourguignon, 2013/06/14
- Message not available
- Re: EIEIO built in methods -- question, Pascal J. Bourguignon, 2013/06/10
- Re: EIEIO built in methods -- question, David Engster, 2013/06/11