Objects, Inheritance and Barking Up Wrong Trees?
[1/3] from: scott:dunlop:nextel at: 25-Apr-2001 23:02
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.
[2/3] from: agem:crosswinds at: 27-Apr-2001 5:09
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 26.04.01, 04:02:32, schrieb "Dunlop, Scott" <[Scott--Dunlop--nextel--com]>
zum Thema [REBOL] 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
<<quoted lines omitted: 14>>
> ]
> 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.
Ugly, and you cannot use [()]'s in your top-level-code, but
with 'compose you can do:
>> a: context[
[ b: func[a][probe a]
[ ]
>> c: make a[
[ b: func[a]compose/deep[
[ (second :b)
[ probe a * a
[ ]
[ ]
>> a/b 123
123
== 123
>> c/b 123
123
15129
== 15129
Volker
[3/3] from: scott:dunlop:nextel at: 27-Apr-2001 0:22
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.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted