A class approach to problem solving is a very useful organization structure for dealing with the normal case that you are unsure how to solve the problem (or the problem is likely to be redefined perhaps by yourself as you go).
You can almost always replace a class with a record/struct structure in other languages. In J, the struct is a list of boxes if all of the members are not of homogeneous types, or a list if they are homogeneous. In J, it is no problem if the members are matrices or trees (sub-records). And you can have lists/matrices/trees of records. There is still an organizational advantage to a class approach. It puts complexity in the class in order to avoid complexity by the caller. You can validate each member, write functions that only consider a subset of parameters, and have relatively static state that assists the caller. Keeping the record analogy, it is probably useful to "pre-organize" where changes to that record would be saved instead of using more complex nested hierarchical boxing that groups records on such pre-organized data. There are still non-class approaches to such organization needs. The obvious is to store the database location and connection parameters in a shared/global variable, but then one day you will think you need 2 or more databases. The approach of a global list of databases is still doable, but you are likely to need to rewrite code that assumed just one database. Another source of complexity that has a simpler class solution than caller-managed code can be generally described as mixed pointer/data structures that include various states of binding. In J, the verb (2 + myvar"_) will produce a constant verb based on the value of myvar at definition, while (2 + 3 : 'myvar') will obtain the latest value of myvar. Traditional pointers are obtained by passing the name in a string as a parameter. It is clearer to describe the mixed pointer data structure problem with an example: A class allows a simple caller interface to assume that a table is always in memory and contains the latest updated data and indexes, with complex managed state that frees the caller from worrying about it. Even then, though there is still a record approach that can be caller managed, usually with significant performance advantage since the caller knows what he will call next, while a class approach must handle all potential sequences of future calls. tldr; classes are very useful in the normal case where we don't know what we are doing. After a correct program has been completed, the classes look stupid and inefficient. I think adverbs and composition in J allows for simplification of caller managed code, and a set of library functions to process the data structure simplify use for callers further down the chain. ----- Original Message ----- From: Dan Bron <[email protected]> To: [email protected] Cc: Sent: Wednesday, September 17, 2014 9:42 AM Subject: Re: [Jprogramming] OOJ and calling a verb from another locale John Hough wrote: > But for my specific problem OOP is the way to go I think. Raul wrote: > Out of curiosity, why? John responded: > Well, maybe I don't. But > I have half a dozen variables I want to tie together. Fair enough, but this just pushes the question back, a bit. Ultimately, J programs manage state, as all non-pure-functional languages do (and, arguably, as pure functional languages do, whether or not they admit it). But J does hew closer to the functional paradigm than Java or C++, and correspondingly puts less emphasis on managing state, and consequently, typically J programs manage fewer unique variables than the equivalent program in Java or C++. Add on top of that that J encourages collecting all variables which change together into a single array, and you sometimes end up with very low-variable programs indeed. I can't say that this must be the case for your current application, of course; I can only observe that, as I studied and used J, my style evolved towards using fewer and fewer variables, and placed more emphasis on data transformation through the composition of stateless functions. Not to say "use fewer variables" is better in some generic, universal sense, only that it is probably "J-er". But, then, as Raul is so often and so rightly points out, all design choices are necessarily compromises. -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
