I don't know what you mean by locking a script.
You probably already know this but the result of create_parent_ f. is to copy
the code from the parent class into the child class... and the result of
executing it is creating all the variables that the original code did into the
child class. Its a brilliant feature equivalent to copy and paste on demand at
runtime.
If that information is unavailable (presumed effect of 'script locking'), a
more foolproof way to extend an object would be to keep/manage a local copy
inside your new class instead of inheriting from it. (I can't tell if your
workaround lets you do everything you need).
bill lam <[EMAIL PROTECTED]> wrote: In the oop lab, it mentions:
How to extend a class:
0. add coextend parent to the new class script
1. call parent create with: create_parent_ f.
2. do your create stuff AFTER you create your parent
3. do your destroy stuff BEFORE you destroy your parent
4. call parent destroy with: destroy_parent_ f.
5. call parent methods with: method_parent_ f.
This is an elegent method, but has a minor restriction.
When a script is locked, "method_parent_ f." is "method_parent_" itself
because it is not possible to examine the content of method_parent_
once the script is locked.
I found a workaround to this problem using redefining.
NB. original script using f.
coclass 'pbcx'
coextend 'pbc'
create=: verb define
create_pbc_ y. NB. our parent's create
NB. do our create stuff here
0
)
destroy=: verb define
NB. destroy our stuff here
destroy_pbc_ f. y. NB. our parent's destroy
)
getfirst=: verb def 'get {. keys'
NB. modified script using redefining
coclass 'pbcx'
coextend 'pbc'
pbc_create_pbc_=: create_pbc_ NB. redefining hidden name
pbc_destroy_pbc_=: destroy_pbc_ NB. redefining hidden name
create=: verb define
pbc_create y. NB. our parent's create
NB. do our create stuff here
0
)
destroy=: verb define
NB. destroy our stuff here
pbc_destroy y. NB. our parent's destroy
)
getfirst=: verb def 'get {. keys'
NB. looking at names accessible from bcx
create__bcx1 ''
copathnlx__bcx1 ''
+-----------+--+----+---+
|COCREATOR |16| | |
+-----------+--+----+---+
|data |16| |pbc|
+-----------+--+----+---+
|keys |16| |pbc|
+-----------+--+----+---+
|sn |16| |pbc|
+-----------+--+----+---+
|COCLASSPATH| |pbcx|pbc|
+-----------+--+----+---+
|create | |pbcx|pbc|
+-----------+--+----+---+
|destroy | |pbcx|pbc|
+-----------+--+----+---+
|getfirst | |pbcx| |
+-----------+--+----+---+
|get | | |pbc|
+-----------+--+----+---+
|pbc_create | | |pbc|
+-----------+--+----+---+
|pbc_destroy| | |pbc|
+-----------+--+----+---+
|put | | |pbc|
+-----------+--+----+---+
It can be seen that pbc's "create" and "destroy" are hidden by pbcx,
but "pbc_create" and "pbc_destroy" are accessible by pbcx. Moreover
no suffix "_pbc_" is needed so that it will not switch locale.
Note.
1)
Depending on whether you intended to lock the script, you may use either method
to coextend a class.
2)
You need either "method_parent_ f." or "parent_method" or other workarounds iff
the class has its own "method" and also needs to access parent's "method"
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
---------------------------------
7 bucks a month. This is Huge Yahoo! Music Unlimited
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
