home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.clos
- Path: sparky!uunet!elroy.jpl.nasa.gov!ufo!Aig.Jpl.Nasa.Gov!charest
- From: charest@Aig.Jpl.Nasa.Gov (Len Charest)
- Subject: Re: Extending syntax/semantics of method specializers
- Message-ID: <1992Nov23.192133.10895@jpl-devvax.jpl.nasa.gov>
- Sender: usenet@jpl-devvax.jpl.nasa.gov (For NNTP so rrn will be able to post)
- Nntp-Posting-Host: ai-cyclops
- Reply-To: charest@aig.jpl.nasa.gov
- Organization: NASA/Jet Propulsion Laboratory
- References: <1992Nov20.221251.28590@jpl-devvax.jpl.nasa.gov> <9211210425.AA12235@verdi.iisd.sra.com> <1992Nov23.113551@disun47.epfl.ch>
- Date: Mon, 23 Nov 1992 19:21:33 GMT
- Lines: 22
-
- In article <1992Nov23.113551@disun47.epfl.ch>, matomira@disun47.epfl.ch (Fernando Mato Mira) writes:
-
- |> The current implemention of CLOS does not allow for the creation of generic
- |> classes, that is, classes where slot types are determined by type parameters.
- |> Under the current implementation, this inhibits the creation of type
- |> specifiers in the style of "(list integer)" for user-defined classes.
- [ generic classes proposal deleted]
-
- Generic classes would go a long way towards extending the expressiveness of
- DEFMETHOD. However, they would not cover all of the discrimination strategies I
- mentioned in my original post--especially the one I find most attractive: method
- selection based on the *value* of a variable. To wit:
-
- (defun interesting-value-p (x)
- (eq x *interesting-value*))
-
- (defmethod observe ((thing (satisfies interesting-value-p)))
- ...)
- ..................................................
- Len Charest, Jr.
- JPL Artificial Intelligence Group
- charest@aig.jpl.nasa.gov
-