Objects, Inheritance and Barking Up Wrong Trees?

I am currently trying to determine the best way to override an object method; at the moment, I've been doing the obvious thing, copying the function into a new binding: ss-histfield: stylize [ histfield: field with [ feel: make feel [ old-engage: get 'engage engage: func [face act event index][ switch/default act [ ; << Special Case Code Here >> ] [ old-engage face act event index ] ] ] ] ] While this works, it is more brittle than I would like, since the old-engage binding isn't private to histfield's feel, and could collide with a child trying to do a similar thing, or revisions to the field feel. Does anyone have a simpler / better solution for doing this? Btw, I am aware that there is probably another way to override feel/engage, but this is one of two sticking points that my Python-oriented mind tends to get hung up on. The other is my addiction to Dictionaries. --Scott.

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

> I am currently trying to determine the best way to override an object > method; at the moment, I've been doing the obvious thing, copying the > ] > While this works, it is more brittle than I would like, since the

> binding isn't private to histfield's feel, and could collide with a

> trying to do a similar thing, or revisions to the field feel. Does

> have a simpler / better solution for doing this? > Btw, I am aware that there is probably another way to override

> but this is one of two sticking points that my Python-oriented mind

> get hung up on. The other is my addiction to Dictionaries.

>> a: context[

>> c: make a[

>> a/b 123

>> c/b 123

My latest guess, found after digging around in the mailing lists and looking at information on how to create private object slots, is to use 'uses' to declare a local variable to hold the old value.. child-object: make parent-object [ uses [old-somefn] [ old-somefn: get 'somefn somefn: func [ .. ][ .. old-somefn .. ] ] ] It appears a lot less brittle, since old-somefn is now local to child-object, and objects derived from child-object can use the same pattern. Does anyone know of a special case that would break this? (Beyond redefining 'uses' in a parent.. ) --Scott.