I scanned system folders for usage patterns on COCLASSPATH and found that there are numerous variations of non-standard use.
Shouldn't these all be consistent, or at least if there is a different justifiable pattern, there be an appropriate co-verb to express it. Such cointernalize '...', if coinsert and coextend are not enough. 1. coinsert other COCLASSPATH require'socket' coinsert COCLASSPATH_jsocket_ 2. copath own COCLASSPATH coextend 'jgl2' coextend 'jgl3' COCLASSPATH copath coname'' 3. copath other COCLASSPATH COCLASSPATH_jzplot_ copath 'jwplot' 4. direct assign COCLASSPATH COCLASSPATH=: ;: 'jviewmat jgl2 z' 5. re-assign names using COCLASSPATH a=. (nl_jgl2_ '') -. <'COCLASSPATH' 0!:100 > (a ,each <'_z_=: ') ,each a ,each <'_jgl2_' 6. combination of the above COCLASSPATH=: ,each 'jijs';'j';'z' (}.COCLASSPATH) copath <'jijs' --- Oleg Kobchenko <[EMAIL PROTECTED]> wrote: > > --- "Miller, Raul D" <[EMAIL PROTECTED]> wrote: > > > I don't see any advantage of the name pbx_create over > > create_pbx_ when they both refer to the same thing, > > and create_pbx_ is simpler to understand. > > That's the whole idea: to prevent locale switch. > Whenever you say verb_loc_ you are no longer in your locale. > Fix (f.) would have fixed it by instead executing a copy. > But locked script instead gives you back verb_loc_ and > you again end up in the other locale. > > This double def cover thing is a brillinat idea, > but it doesn't feel right to need to do it. > > > > One of these days, someone is going to figure out > > how to reliably deploy versions of these names > > which rely solely on the 18!: facilities and > > entirely discard the COXXX variables. > > This is interesting. So what is the relationship > between COCLASSPATH and 18!:2 ? > COCLASSPATH is a redundant convenience facility > to store up the path for the sole purpose of > conew to do copath on class instances. > > Interestingly, why not just store the > instance path-to-be as the copath of > the class locale, and then just copy class path > to instance path? > > Instead of > COCLASSPATH__c copath obj > have > (copath c) copath obj > > > > That, I think, was the original J design. > > > > Anyone really needing the current implementation > > can (and should) include a script giving > > coextend_z_ (and so on) their current, overly fussy > > definitions. > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
