Number: 914
Date: 1-May-84 18':44':48
Submitter: Sannella.PA
Source: Roach
Subject: Proposal': extend GETPROPLIST to supersede IMAGEOBJPROP, PROCESSPROP, WINDOWPROP
Assigned To:
Attn: Lisp
Status: Open
In/By:
Problem Type: Design - Impl
Impact: Annoying
Difficulty: Easy
Frequency:
Priority: Unlikely
System: Language Support
Subsystem: Storage Formats/Mgt
Machine:
Disk:
Lisp Version:
Source Files:
Microcode Version:
Memory Size:
File Server:
Server Software Version:
Disposition: [lmm': no overwhelming endorsement. More likely, "object oriented programming" would give us the same thing, e.g., make GETPROPLIST cause message pass on non-atoms. Perhaps the ]'
[KBR': ATTN ← LISPSUPPORT instead of ROACH]'
["masinter" " 4-Sep-84 14':16':15" Attn': Status':(Declined->Open) Priority':(->Unlikely)]
Description: '
Date': 16 APR 84 11':30 PST'
From': ROACH.PA'
Subject': PROPOSAL TO EXTEND GETPROPLIST'
To': LISPSUPPORT'
'
'
'
PROPOSAL TO EXTEND GETPROPLIST'
'
'
Could we not dispense with these functions?'
'
(IMAGEOBJPROP IMAGEOBJ PROP {VAL})'
(PROCESSPROP PROC PROP {NEWVALUE})'
(WINDOWPROP WINDOW PROP {NEWVALUE})'
'
I see no good reason why MENU''s, WINDOW''s, and other datatypes should'
have associated functions and fields to essentially duplicate the'
existing Interlisp property mechanism. GETPROPLIST and SETPROPLIST'
could be made to work on all lisp objects, maintaining the existing'
implementation for non-NIL LITATOMs. Datatypes tending to have plists'
should just have their plist cells built into them. Objects with'
non-NIL plists but no built in plist should be hashed in a hash table.'
(Two numbers should be considered the same object if they are IEQP or'
FEQP.) This workable scheme is essentially what is done in the lisp'
variant BRANDX, for example. The advantages of the scheme are upwards'
compatibility, less need to emulate Interlisp code, and easier use of'
some user''s packages.'
Kelly'
Workaround:
Test Case:
Edit-By: masinter
Edit-Date: 4-Sep-84 14':16':17