>From my current point of view, if you want to do "object oriented programming" in J, it's probably worth thinking of a J session as an object, and an operating system command line as an object constructor.
But even more important is thinking about what problem(s) you are trying to solve, and how to tell if you are solving that problem correctly. Without that, all you've got is a solution looking for a problem (which, in turn, leads to the creation of problems, which seems kind of silly when problems are so plentifully available). Meanwhile... there are all sorts of analogies one can draw with objects, but when I thin about the role objects play in java, I think a bulk of that role in J is taken with arithmetic and related primitives (indexing, for example). In other words the role of a java "class" is [very roughly] the same as a J "array". Java allows for much more ornate constructs, of course - J puts a lot of pressure on the programmer to use an efficient and streamlined approach. But that's what makes J such a valuable thing to learn. Seeing a problem from different points of view is important for one's sense of perspective. Thanks, -- Raul On Wed, Aug 13, 2014 at 10:10 AM, 'Pascal Jasmin' via Programming <[email protected]> wrote: > If one copy of an object is needed where all of its settings can be > determined based on "global" variables set by previously loaded code (or > obviously, not dependent on any else at all), then a locale is much simpler > to use. You can also use a locale as "class variables" common to all > instances or otherwise global to the program. > > coclass 'myclass' > a=: 0 > create =: 3 : 'a=: y' > > obj = 1 conew 'myclass' > > 0 = a_myclass_ > 1 = a__obj > > So a locale is both a module and a class. It is a module in that all > definitions including nouns are set on load, and so it is automatically alive > with accessible data. It is a class in that new instances of it can be > created which will all have their independent modifiable "copies" of names > from the locale/class. Even the functions inside the instance may be changed > after creation too. > > > ----- Original Message ----- > From: Jon Hough <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, August 13, 2014 9:49:11 AM > Subject: Re: [Jprogramming] Singleton Objects in J > > I think it will take a while to digest all that. But I think what you are > saying is that in J we dont need to define an object with a private > constructor etc, to make singletonlike functionality. > We can use a locale and functions defined in the locale to get the same > effect? > > --- Original Message --- > > From: "'Pascal Jasmin' via Programming" <[email protected]> > Sent: August 13, 2014 10:23 PM > To: [email protected] > Subject: Re: [Jprogramming] Singleton Objects in J > > I'm not positive of the exact definition of singleton, but there are 2 common > intentions for it. > > 1. Have exactly one instance of an object. > > in this case a locale acts as both a singleton, or as class variables. It > does not require conew, as the class/singleton is "instanced" on file load. > > 2. Have 0 or 1 instance of an object. > > This version creates a minor problem of requiring a function to get an object > if it exists. Its a minor problem because to access members of the object > you need to either assign the return value to a variable or send string > messages to the return value. > > If your response to it not existing is to create the object, then you are > better off with the first version. > > One legitimate use of this latter pattern is only letting the first creator > set the settings of the class/instance, and then make them immutable. > > There are 2 patterns I like for imposing any control over constructors of an > object > > a. > new_Singleton_ =: 4 : '... (x;y) conew 18!:5''''' > > above can also be monadic. It changes the constructor from params conew > 'Singleton' to new_Singleton_ params, but this allows you to setup any custom > guards or tracking system, or creation substitution/prevention as part of the > instancing process. > > It does not prevent you from calling conew directly, and "ruining > everything", so treating the new name in a locale as an almost reserved word > can be convenient practice to copy and paste consistency among classes. > > b. > > newSingleton_z_ =: 4 : '... (x;y) conew 18!:5'''' ' > getSingleton_z_ =: ... > > this provides a one size fits all way of creating a singleton from any > class/locale. called as: > > newSingleton_Singleton_ params > > works because locales default to coinsert z inside them, so when you > substitute a VERB defined in z calling it in another locale, it sees the > called locale as the current one, so you can do the logic of checking the > current locale for a "conventional" name, and then returning it or setting it > after a conew call. > > you could also do: > > newSingleton_javalike_ =: 4 : '... (x;y) conew 18!:5'''' ' > > coclass 'Singleton' > coinsert 'javalike' > > and you still call it as: > newSingleton_Singleton_ params > > and define all the methods you want in the javalike locale, and then use them > in all the classes you want to be javalike by adding the line coinsert > 'javalike' to those locales. > > > ----- Original Message ----- > From: Jon Hough <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Wednesday, August 13, 2014 5:25:54 AM > Subject: [Jprogramming] Singleton Objects in J > > I looked through the jsoftware website but couldn't find any references > tocreating singleton objects in J.So I created my own singleton pattern for > J. It seems to work. > > coclass 'Singleton' > > NB. static instanceinstance =: 0 > > NB. private constructorcreate =. verb defineval =: 1) > > NB. Public gettergetinstance =: verb defineif. instance = 0 do. instance =: > conew 'Singleton'instanceelse. instanceend.) > > NB. Verb for checking.say =: verb defineval =: val + 100t =. 'HEY't) > > destroy =: codestroy > > One thing is, I'm not sure whether making create private stops conew being > called explicitly.To create THE instance or get it, the user should call > getinstance_Singleton_ '' > But users can still call conew 'Singleton' from outside the class without an > error being raised. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
