Wow, I wasn't expecting that. Brilliant. I think this could definitely help new users. Looks good to me. Maybe in future, a section on inheritance (coinsert) might be nice.
Thanks, Jon -------------------------------------------- On Fri, 10/13/17, Henry Rich <[email protected]> wrote: Subject: Re: [Jprogramming] Garbage Collection and Objects To: [email protected] Date: Friday, October 13, 2017, 10:40 AM OK, I just banged out http://code.jsoftware.com/wiki/Vocabulary/ObjectOrientedProgramming Please read & criticize. Henry Rich On 10/12/2017 8:43 PM, 'Jon Hough' via Programming wrote: > OK, I think I get it, thanks. The only final point I would make is that the necessity to "clean up your own garbage" should be > a little more explicit in the J Wiki / J website. I would add something myself to the Wiki, but I don't have access and there seems > to be no section in the Wiki regarding OOP. > e.g. google search > object orientation site:jsoftware.com > gives JForC and Learning J explanations of OOP, but not much else. > Then again, maybe this was clear to everyone else and it was just my reading comprehension that was lacking when reading JforC/Learning J's > explanation of OOP (they both mention codestroy, but I didn't put 2 and 2 together.) > > > -------------------------------------------- > On Fri, 10/13/17, Raul Miller <[email protected]> wrote: > > Subject: Re: [Jprogramming] Garbage Collection and Objects > To: "Programming forum" <[email protected]> > Date: Friday, October 13, 2017, 12:26 AM > > Objects are, themselves, named > collections of named values. > > It's not just that they are referenced via > box literals - they are > just a different > flavor of classes, and are not GC'd because they use > that same design. You can always reference > objects via conl 1. > > This > design does, unfortunately, make it much harder to > reference > unallocated memory. But the cost > is that you can inspect arbitrary > objects > from the J command line. > > Thanks, > > -- > Raul > > On Thu, > Oct 12, 2017 at 10:56 AM, 'Jon Hough' via > Programming > <[email protected]> > wrote: > > By "explicitly > release" you mean dereference in the following sense > right? > > thingy=: ? 1000 * 1000 $ 0 NB. > Lots of memory allocated. > > thingy=. 1 > NB. The 1000x1000 matrix was dereferenced and is eventually > GCed. > > > > But objects > don't work like this: > > thingy =: 100 > conew 'A' NB. Memory allocated for instance of A > > thingy=: 1 NB. instance of A was > dereferenced, but memory not reclaimed - memory leak. > > > > My only question is, > why not automatically reclaim dereferenced objects? > > I guess it is difficult to decide if an > object is no longer reachable, since objects > > are referenced as boxed literals. Any > boxed literal could inadvertently "reference" > > an object that would otherwise be ready > for GC. > > In an imaginary J with a > "Pointer" datatype, or whatnot, it would be > > easier to figure out that an object is not > reachable, just by reference counting > > > the "Pointers" to the object. > > > > > -------------------------------------------- > > On Thu, 10/12/17, Raul Miller <[email protected]> > wrote: > > > > Subject: > Re: [Jprogramming] Garbage Collection and Objects > > To: "Programming forum" <[email protected]> > > Date: Thursday, October 12, 2017, 9:21 > PM > > > > Anything > involving names in > > locales needs > explicit GC. > > > > So, > for example: > > > > > thingy=: i.1e6 > > > > > That name - thingy - will persist until you > > explicitly release it. > > > > Locales actually > make this a bit easier (since > > you can > erase the > > entire locale rather > than > > having to erase all the names in > it). > > > > The problem > comes when you have been trained to > > > use millions of tiny > > objects. > That's a > > bad habit not just > because of "GC", but because > > it's > > a poor > use of space and time, in J. > > > Generally speaking, in J you want > > to > arrange > > things so the low level > structures are regular and the > > > complexity bubbles up to the top levels. This > > tends to be great for > > comprehension, but > > painful or worse when you are not > supposed to be > > able to understand > what you are working on. > > > > Thanks, > > > > -- > > Raul > > > > On Thu, Oct 12, > 2017 at 5:50 AM, 'Jon > > Hough' > via Programming > > <[email protected]> > > wrote: > > > Is > there a reason J doesn't > > perform > GC on objects? I was unaware we had to destroy our > > own objects > > > > (In retrospect, I guess the > > existence > of codestroy was a hint ). > > > > > > Example: > > > > > > > oclass 'B' > > > > > > > create=: 3 : 0 > > > > > > Mat=: ? (y,y) $ 0 > > > > > ) > > > > > > > destroy=: > > codestroy > > > > > > > > > > > > > > > > > coclass > 'A' > > > > > > > > > > create=: 3 : 0 > > > iterations=: y > > > myB=: > > > '' > > > ) > > > > > > > > > runLoop=: 3 : 0 > > > ctr=: 0 > > > > while. ctr > > < iterations do. > > > myB=: 400 conew > > 'B' > > > > ctr=:>:ctr > > > end. > > > > > > 'finished' > > > ) > > > > > > > > > > > destroy=: > codestroy > > > > > > > > > > myA=: 1000 conew > > 'A' > > > > runLoop__myA 0 > > > NB. Let myB > reference an int now. It might > > be > expected that the > > > NB. 400x400 > > matrix's memory allocation was > freed, but it > > > NB. is still > there. > > > > > > myB__myA=: 1 > > > > > > > > Viewing > memory usage in htop or Activity Monitor, this > > program goes into the Gigabytes quickly > and as far as I can > > see the > > > memory is never reclaimed. > > > I am not complaining, I am just > wondering, > > why unreferenced objects > are not GCed, > > > and also recommend > that OOP explanations > > in the Wiki, > JforC (assuming a new edition) be a little > > more explicit > > > > in the necessity of > > > codestroy. > > > > > > This is > > > A's runLoop that destroy unreferenced objects > > > runLoop=: 3 : 0 > > > ctr=: > > 0 > > > while. ctr < iterations do. > > > if.-. myB -: '' do. > > > destroy__myB '' > > > end. > > > > myB=: 400 conew > > 'B' > > > ctr=:>:ctr > > > end. > > > > > 'finished' > > > ) > > > > > > > > > > > Using this, memory allocation does not > increase. I'm > > sure this is > probably obvious to J experts, but as far as I > > can see, doing there is > > > no explicit > > > explanaiton of this anywhere. > > > > > > ---------------------------------------------------------------------- > > > 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 --- This email has been checked for viruses by AVG. http://www.avg.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
