[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Solutions to Name/Object Mapping for Generic Functions
- To: email@example.com
- Subject: Re: Solutions to Name/Object Mapping for Generic Functions
- From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Date: Thu, 27 Aug 87 15:05:47 CDT
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Msg of Thu, 27 Aug 87 10:51:21 MST from firstname.lastname@example.org
THE PROBLEM AND PROPERTIES OF A GOOD SOLUTION
The following are some possible solutions:
1) The symbol function cell could be eliminated as a global object and
the name to funcallable object mapping could be maintained within the
environment, as is the case in Scheme.
2) The generic function slot accessor functions could take an
environment argument and return information accordingly. This
was the solution I believe Patrick proposed.
3) We could simply leave it up to implementors to supply these
hooks, if they so choose.
If you are talking about name-to-generic-function mapping, 2 is not what
I have proposed. Name-to-generic-function mapping shouldn't depend on
the metaclass protocol since it should behave the same as
name-to-regular-function. Not being affected by the metaclass protocol,
it can be left to the implementation. The hook should be specified
though. If some implementations decide to ignore the environment,
that's fine. Since the environment is going to be passed explicitly(see
Moon's reponse to my proposal), we either need a new primitive for that,
or change SYMBOL-FUNCTION to accept an environment argument. A new
primitive for metaclass programmers is probably the best thing to do.
However I object to 3 since it will make serious metaclass programming