I believe all the object-oriented design practices and design patterns should be applicable to J programming.
For example, dozens of globals is a bad things, hundreds is still worse. To avoid this, the concept "globals" is treated as singleton pattern and the globals are grouped into classes, so that each class has a limited related responsibility. For more complex cases, those classes are nested and clustered, so that the singleton is an instance, i.e. its properties are not class variables, but the instance itself is. With this regard, I have some critique on the Project based approach in J: the sources are small managable code units, grouped nicely into folders. But when built it all is packed into the same single locale. So the principle of modularity is compromized: to be able to communicate within the single class, code from different code units need to access private parts of other units. This is similar to the problem with globals only in locale scope. As an alternative, I would see what is done in SmallTalk, Java, .NET: there are multitude of small classes each with very limited responsibility complying with the 5-7 item short memory rule. As soon as it grows larger, it is broken in one of different ways: hierarchichally, by encapsulation, etc. And each class continues to live in memory separately as it was defined in the code unit. So the code is managable both in the source and at runtime. Objective-C API has been widely practicing the concept of cluster classes, where the public API is a simple one abstract class (interface), e.g. Array -- that's what the user operates; and the implementation has numerous possibly hierarchically defined inner classes like IntArray, BitArray, StringArray, etc. Because user never knows about their existence, (until now; sorry, user) including their internal globals, programming is much simpler. I think what Markus meant is to absolve the low-level API from the awareness of the modus of thier use, so they stay ignorant of your PENCOL. Alternatively, you may have decided to keep the state closer to the low-level painting routines and delegate to them this responsibility to keep PENCOL, etc around. So your upper-level code will borrow the whole DRAWSTATE singleton from that API. Or better if the painting routines can be used by someone else, make an instance of that state, and keep that around. Think loose coupling, tight cohesion. --- Ewart Shaw <[EMAIL PROTECTED]> wrote: > > Hello again all. > > I've been working away on a (large, complex) software package, > and have a question on programming style. This stems from > a recent post I made to comp.lang.apl about niladic functions: > > > ========== (original query) ========== > > > I used the APL niladic function to generate > >tutorials in several versions of APL. When J > >came out I was planning to do the same, but > >was unable to do so because J does not support > >niladic functions. > > ============ (my response) =========== > > You can write a monadic function fun say that ignores its argument, > and call it in J with > fun'' > > I mainly use niladic functions to return globals, for example > setpc=: 3 : 'PENCOL=: y' NB. usually more complex than this! > getpc=: 3 : 'PENCOL' NB. again may be more complex > NB. e.g. return 0 0 0 if PENCOL undefined > ... > p=. getpc'' NB. pen colour > ... > > As a side-effect of the "idiom" fun'' it's then easy for me > to check when I may be using globals, just by searching for '' . > This technique makes development less error-prone, at least for me > - for example, if (when?) I decide to change PENCOL to be a stack. > > ========== (further response) ========== > > Someone (Markus Triska) then replied saying that > "Passing PENCOL to all functions using it is even less error-prone" > > ========== (end of extracts) ========== > > > My experience has been different from Markus's: I know if a > particular function needs access to PENCOL, but keeping track of > "all functions using it" would be a nightmare, particularly in the > development stage (& I expect the development stage to last forever). > I've also found my approach useful whether or not I'm using J's > object-oriented features. > > Has anyone any comments? How do other people avoid being strangled > by spaghetti code? (I'm talking several hundred k of .ijs scripts) > > Regards, Ewart __________________________________________________ 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
