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