CLIM mail archive

[Prev][Next][Index][Thread]

Re: menu-bar



  Date: Thu, 5 May 1994 18:55:37 -0400
  From: miller@cs.rochester.edu
  To: "William M. York" <york@parc.xerox.com>
  Cc: colin@franz.com, ncramer@BBN.COM, abramson@verdi.sra.com, clim@BBN.COM
  Subject: Re: menu-bar 
  References: <9405050032.AA09414@vapor.Franz.COM>
  	<94May5.154016pdt.32390@sparkie.parc.xerox.com>
  
  >>>>> "William" == William M York <york@parc.xerox.com> writes:
  
      William> Of course, I don't have to tell you where I stand on these
      William> issues, but I thought that I'd raise the point as a way of
      William> publicly checking the state of things.  I think everyone
      William> loses in the long run when individual vendors extend
      William> outside the spec, even when those extensions are good ideas
      William> in and of themselves.
  
  I disagree with this completely. If that had been the attitude with CL,
  then nobody would have any support for Defsystem, Multiprocessing, or
  FFI (to name three :-), at all without "ANSI permission".
  
  Vendors should be able (need to be able) to provide upward compatible
  extensions if for no other reason than to support their customers. So
  long as these are clearly identified as non-portable extensions, I don't
  see a problem, and they provide a valuable testbed for future portable
  language extensions.
  
  Regards,
  Brad Miller

I also believe that vendor-supplied extensions are a good thing.
I would only ask that the "clim" package be sacrosanct, much like
the ANSI "common-lisp" package.  It is good hygiene to put new
symbols in other packages, "clim-extensions" for example.
The keyword :menu-bar wouldn't apply, of course, but the class
name MENU-BAR would.

jeff morrill


Follow-Ups: References:

Main Index | Thread Index