Pascal Costanza wrote: > Rob Thorpe wrote: >> Pascal Costanza wrote: >>> Matthias Blume wrote: >>>> Pascal Costanza <[EMAIL PROTECTED]> writes: >>>> >>>>> (slot-value p 'address) is an attempt to access the field 'address in >>>>> the object p. In many languages, the notation for this is p.address. >>>>> >>>>> Although the class definition for person doesn't mention the field >>>>> address, the call to (eval (read)) allows the user to change the >>>>> definition of the class person and update its existing >>>>> instances. Therefore at runtime, the call to (slot-value p 'adress) >>>>> has a chance to succeed. >>>> >>>> I am quite comfortable with the thought that this sort of evil would >>>> get rejected by a statically typed language. :-) >>> >>> This sort of feature is clearly not meant for you. ;-P >> >> To be fair though that kind of thing would only really be used while >> debugging a program. >> Its no different than adding a new member to a class while in the >> debugger. >> >> There are other places where you might add a slot to an object at >> runtime, but they would be done in tidier ways. > > Yes, but the question remains how a static type system can deal with > this kind of updates.
It's not difficult in principle: - for each class [*], define a function which converts an 'old' value of that class to a 'new' value (the ability to do this is necessary anyway to support some kinds of upgrade). A default conversion function may be autogenerated if the class definition has changed only in minor ways. - typecheck the new program and the conversion functions, using the old type definitions for the argument of each conversion function, and the new type definitions for its result. - have the debugger apply the conversions to all values, and then resume the program. [*] or nearest equivalent in a non-OO language. -- David Hopwood <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
