I guess you can add another verb similar to conew which keeps track of object created for a class. eg a table of class and object, and search for the class before creating a new object. On Aug 14, 2014 10:00 AM, "Jon Hough" <[email protected]> wrote:
> Well, it does seem Java style oop is not suited to J. > Also, many programming bigwigs hate singletons for a variety of reasons. > But they can be useful. > An example I can think of is in writing a game engine. It often makes > sense to have certain manager classes, e.g. audio manager, playersettings > etc, as singletons. > So on game startup you could load audio files into the audio manager and > they become available to play from any point in the game app, and you > always know what sound files are being played at any time. > I am wondering how such things would be achieved in J. I suppose locales > do the trick. > > --- Original Message --- > > From: "Raul Miller" <[email protected]> > Sent: August 14, 2014 2:38 AM > To: "Programming forum" <[email protected]> > Subject: Re: [Jprogramming] Singleton Objects in J > > 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
