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
