Re: Warning STklos feature: function redefination

From: Ken Anderson <kanderso_at_bbn.com>
Date: Mon, 31 Jul 1995 09:31:16 +0100

  From: Moises Lejter <mlm_at_cs.brown.edu>
  Date: Sat, 29 Jul 1995 04:13:23 -0400
  To: kanderso_at_BBN.COM
  Cc: jzinky_at_BBN.COM, stk_at_kaolin.unice.fr
  Subject: Re: Warning STklos feature: function redefination
  References: <199507211214.IAA15457_at_atom-ant.bbn.com>
          <199507211243.IAA11793_at_lager.BBN.COM>
  Reply-To: mlm_at_cs.brown.edu
  
  Instead of simply warning the programmer that an existing function is
  about to be redefined, it seemed to me a better solution not to lose
  the original definition of the function.
  
  The following patches, one to gf.c, the other to stklos.stk, provide
  an alternative. Once they are applied, the introduction of a new
  generic by the same name as an existing function does not clobber that
  function. Instead, the old definition is stashed away and used as the
  last resort, for those function calls for which no method that matches
  the arguments can be found.
  
  As a result, existing code will not break if one accidentally (or
  intentionally) introduces a new generic that overrides some function
  in some library somewhere. In particular, this happen all over the
  place, when some of the STklos classes are loaded into STk (I am still
  in 2.1.6) - they redefine as generics some functions that were already
  used by the core STk Tk support.
  
I don't think this is a good idea. You are either intentionally
overwriting an existing function or you are not. If it is unintentional
something like a warning or an error is informative. If it is intentional
you have already saved the orginal behavior if it is of use to you. If you
want the orginal behavior to be the default method of a generic function of
the same name, you should express that in your code rather than relying on
something that only happens automatically if a generic already names an
existing function. If this is a common idiom, write a macro.

k
Received on Mon Jul 31 1995 - 15:33:22 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST