The rationale behind dyadic coclass is that in most OO languages class definition includes inheritance in one construct.
In fact SmallTalk has even the same item order <Parent> subclass: <NewClass> http://en.wikipedia.org/wiki/Smalltalk#Classes So it should be naturally intuitive and is a syntax sugar for most common class declarations. Most users then wouldn't need to bother about the notion of coinsert at all. Even for forms, where OOP is encouraged, using modular import can be expressed the same: 'pbase jgl2' coclass 'pmainform' As for wierdness of the dyadic definition: that's a small price for syntax convenience*). The dyadic form would otherwise be just vacant. Here is the summary - COCLASSPATH: removed - coextend: replaced by coinsert - cocurrent: replaced by monadic coclass - coinsert: mostly replaced with dyadic coclass becomes advanced low-level verb (tentative) As shown in the proto, the only OOP verbs that need to be used in user code are 'class' and 'new'. *) double cocurrent shows interesting workings of locale switch rules. It looks like locale is reset on return from an inner call to value at current verb entry. Other variations of coclass dyad: coclass_z_=: 3 : 0 18!:4 <,> y : 18!:4 y=. <,> y coinsert x 18!:4 y ) coclass_z_=: 3 : 0 18!:4 <,> y : ('coinsert_',y,'_')~ x 18!:4 <,> y ) coclass_z_=: 3 : 0 18!:4 <,> y : y=. <,> y coinsert__y x 18!:4 <,> y ) --- Chris Burke <[EMAIL PROTECTED]> wrote: > Oleg Kobchenko wrote: > > --- "Miller, Raul D" <[EMAIL PROTECTED]> wrote: > > > >>At least part of this would go away if > >>coextend=: coinsert > > > > Here is a proto of COCLASSPATH-less, coextend-less OOP. > > coinsert and other co's still exist and used. > > This sounds like a good idea. I tried removing COCLASSPATH and coextend > from the scripts, replacing with coinsert, and everything works fine. > So, unless we hit some showstoppers, the next beta will have the > simplified code. > > One thing I am not too keen on is the dyadic coclass, which is a little > ugly - the dyad has to do a cocurrent, then coinsert, then the cocurrent > again. Also, I suspect the dyad might be little used. > > If coclass was only a monad, its definition would be the same as > cocurrent, and we could then remove one definition. I suggest we retain > coclass and remove cocurrent. > ---------------------------------------------------------------------- > 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
