Obsolete Classes? 
Author Message
 Obsolete Classes?

We are writing an application where ST classes are dynamically created
and removed. Unfortunately, I recognized that certain classes aren't
really destroyed after a removal. They still exist in a realm of
shades, disguised by an `Obsolete' in front of their names. And in
addition, there also exist instances of these spooks, wasting object
memory.
Q: How can I find all these obsolete classes
   (eg, MetaClass allObsoleteClasses)?  
   How can I get rid of them?

[ We are using ParcPlace Smalltalk-80 Release 4.1 on a Sun. ]

Thanx for your help,
---
Alois.

---

University of Technology Vienna         |     TEL: (+43-1) 58801-6127
Paniglg. 16, A-1040 Vienna, Austria     |     FAX: (+43-1) 5055304



Mon, 05 Feb 1996 17:23:03 GMT  
 Obsolete Classes?
|> We are writing an application where ST classes are dynamically created
|> and removed. Unfortunately, I recognized that certain classes aren't
|> really destroyed after a removal. They still exist in a realm of
|> shades, disguised by an `Obsolete' in front of their names. And in
|> addition, there also exist instances of these spooks, wasting object
|> memory.
|> Q: How can I find all these obsolete classes
|>    (eg, MetaClass allObsoleteClasses)?  
|>    How can I get rid of them?
|>
|> [ We are using ParcPlace Smalltalk-80 Release 4.1 on a Sun. ]

A suggestion that might work: Eliminate all references to instances of the
class before you remove the class.




Mon, 05 Feb 1996 22:44:51 GMT  
 Obsolete Classes?
My big question is: How are you handling the creation of instances
of these dynamically created and deleted classes ?

It sounds like the ParcPlace method of handling class deletion is
different from the Digitalk technique I see in ST/V 286.  In ST/V 286,
when a class is deleted there will often still be references to that
class in existence within the bytecodes of methods in which the class
was referenced.  Typically, this is occurs in a method where you have
some statement such as "something := AClass new".  The compiled version
of this method contains the reference to AClass, and this reference will
continue to exist even after you delete AClass.  However, when AClass is
deleted, Digitalk's solution is to have all references to AClass modified
so that they then refer to class DeletedClass ( I assume that ParcPlace is
doing something similar when you see the class with "Obsolete" pre-pended
to the class name ).

Thus, when I see the de{*filter*} pop up complaining that DeletedClass
"doesNotUnderstand: someMessage" I realize that somewhere I need to change
a method and recompile it.  Then it will have the correct class reference.
Since for me it is often a previous incarnation with the same name, the fix
is very easily accomplished by deleting and pasting back in any white space
within the method and resaving the method.

I suspect that you have something similar, as I only become aware of
DeletedClass in daily life when I encounter a method which still refers
to a previous incarnation of a class or some class no longer in existence.

I do not believe you need to go to any extra effort to delete these
shadow classes, the GC will get them like any other non-referenced object.
This of course depends on how ParcPlace handles deleted classes.

BTW, the above discussion is based on my own deductions from working with
V/286.  It may or may not be in the documentation, but this explanation
is the one that made sense to me.




Tue, 06 Feb 1996 03:41:29 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Obsolete classes in VisualWorks 2.0

2. Class BASIC_ROUTINES should be made obsolete.

3. obsolete

4. SstCron samples use obsolete (and non-functional) code

5. timings (was: Does perl make awk obsolete?)

6. SstCron samples use obsolete (and non-functional) code

7. When is ELKS95 obsolete?

8. Obsolete features

9. Is Clarion obsolete ??

10. Misleading obsolete feature in std_files

11. obsolete WORD FIND NUMBER

12. Forth is outdated and obsolete

 

 
Powered by phpBB® Forum Software