From: Sam S. <sd...@gn...> - 2017-07-19 21:30:21
|
Bruno, > * Bruno Haible <oe...@py...t> [2017-07-19 23:00:22 +0200]: > >> (declaim (dynamically-modifiable gf1 gf2 gf3)) > > I don't think this will work right: If you store this information only in > the GF, then after redefining the GF without (dynamically-modifiable), the > effect will be lost - which is counter-intuitive. Whereas if you store Not necessarily. When _redefining_ GF we can look at the old definition and carry the slot over to the new one, unless we also see (declare ((not dynamically-modifiable))) in the new definition. > this information on the property list of the symbol or in the undocumented > variable clos::*dynamically-modifiable-generic-function-names*, the > semantics will be too complex, i.e. too hard to understand. Then it will not be possible to change the dynamically-modifiable status of a GF without redefining it. I am not sure this is a good idea. BTW, we might want to also add (declaim ((not dynamically-modifiable) gf1 gf2 gf3)) > - the only use of clos::*dynamically-modifiable-generic-function-names* > will be for clos-genfun2b.lisp line 856. or no! please! we can do better: (letf (((gf-dynamically-modifiable gf) t)) (remove-method gf old-method)) Thanks. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://no2bds.org http://thereligionofpeace.com http://think-israel.org http://memri.org When C++ is your hammer, everything looks like a thumb. |