Subject: Re: All instances From: Erik Naggum <email@example.com> Date: Mon, 18 Jun 2001 12:04:08 GMT Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * email@example.com > By a lost object I don't mean unreferenced, but just that I don't know > where to look for it. Sigh. Then it is not the object that is lost, it is you. It is wrong to solve that problem in programming languages. > "Classname allInstances" is a safe, consistent, and useful feature of > Smalltalk. So you have made it clear that you think. I happen to disagree, based on the way you tell us that you use it. Incidentally, I use the same kind of function in Allegro CL, which I had hoped you would understand, but I consider it about as "safe and consistent" as that trick I did with changing the type information between bignum and bit vector. I know how to do both safely and without destroying anything, but the fact that you can get at _any_ object and meddle with it even if it was intended to be captured in such a way that code optimizers and all users expected a very consistent object between invocations does _not_ constitute "safe" to me. > It doesn't rummage around in garbage. It only finds live objects. So does the garbage collector. Please excuse the expression, which was intended to impart to you that you are using a feature that is necessarily looking for objects via a different mechanism than one usually _wants_ to use, and which is essentially the same as the garbage collector, namely that of following internal object chains or allocation patterns. Any other implementation of allInstances is really wasteful, but this _is_ the domain of the allocator (and garbage collector). (Maybe you do not understand what the garbage collector does, yet, and that is perfectl OK, but then you must not act as if you do, either.) > It typically takes a fraction of a second, and is only used at the top > level, for purposes such as exploring and debugging. If it is a safe, consistent and useful feature of SmallTalk, I _expect_ people to use it in very different ways than it was "intended". That is why it is a bad idea to publish such interfaces to the memory subsystem. > They just mostly satisfy idle curiosity, but in some cases can save a lot > of debugging time or learning time. Yes, sure, but my argument was actually that by so doing, you are not encouraged to write better code or learn by more efficient means. I see that you completely ignored this argument, and so my first hunch that it would be a waste of time to respond to you was probably correct. #:Erik -- Travel is a meat thing.