Re: Keyword problem in PCL

[kanderso@VAX.BBN.COM]

   Return-Path: <@MCC.COM:krall%pp.mcc.com@mcc.com>
    08:20:56-CDT
   Posted-Date: Friday, 15 May 1987, 08:20-CDT
   Message-Id: <8705151321.AA10737@pp.mcc.com>
   Date: Fri, 15 May 87 08:20 CDT
   From: Ed Krall <krall%pp.mcc.com%pp.mcc.com@MCC.COM>
   MMDF-Warning:  Parse error in original version of preceding line at VAX.BBN.COM
   Sender: krall%pp.mcc.com@MCC.COM
   Subject: Keyword problem in PCL
   To: commonloops.pa@XEROX.COM

   Perhaps I am missing something, but the following behavior is a bit of a
   problem:

   Class AAA  has an instance variable or slot called "name".  Therefore
   subclass AA of AAA also has this slot.  When I do a 

   	(make-instance 'AA :name "joe"),

   the slot that gets initialized is the one named pcl::name not user::name.
   Why is this?  Because 

   1.	the keyword lookup procedure (referenced from
   	initialize-from-init-plist in the file slots.lsp) does a simple
   	forward  search on the value returned by class-instance-slots, and

   2.	this value lists the instance slots in ancestral order, and 

   3.	the slots pcl::name and user::name have the same keyword, :name. 
    
   I wonder if this is the optimal behavior.  Shouldn't the more recent or
   local declaration (user::name) shadow the older and more general one
   (pcl::name)?

The problem is that the decision to use keywords to initialize
variables (in flavors and PCL) collapses the symbol namespace as
described above.  In the original Flavors documentation, this was
considered a good thing because messages were generic operations, and
you shouldn't have to remember what package every message is in.
In the more recent view of object oriented programming as described in
CLOS, i'm not so sure using keywords is still so good an idea.  

In Symbolics General 7 Flavors, at least you are warned of the symbol
name clash, and this should happen in PCL too.  Whenever i get such a
warning, i rename one of the slots.

k