misc (was Re: full isolation)

[Ned Konz]

On Saturday 05 March 2005 9:37 am, Lex Spoon wrote:
> Yes, that would be excellent.  It is a little awkward to use a separate
> tool for browsing external code, like we do right now.  Additionally, it
> seems like this will make the code browsers more modular and easy to
> work with.  Instead of trawling through the system, the browser could
> ask questions to some sort of SourceCodePool object.  (Chuck's name for
> this concept -- but feel free to improve on it!).  I believe the
> refactoring browser has a similar concept floating around, named
> BrowserEnvironment perhaps?

Yes; there are various BrowserEnvironment subclasses that can enumerate their 
contents or answer inclusion tests (which is exactly what PackageInfo 
instances can do).

They also provide convenient ways to get to the SystemNavigation, 
SystemOrganization and ClassOrganization services. And they can hold a set of 
search strings, which is nice in the browser.

There is one flavor (ParseTreeEnvironment) which can be given patterns to 
match the parse tree against. So for instance you can have a 
BrowserEnvironment that includes only the methods that call menu construction 
operations with untranslated literal strings (a Lint rule that I just added).

These are among the ways you can create them (note that you can do logical set 
operations on them too):

&
forCategories:
forClass:protocols:
forClass:selectors:
forClasses:
forPackage:
forPackageContainingClassCategory:
implementorsMatching:
implementorsOf:
instVarReadersTo:in:
instVarRefsTo:in:
instVarWritersTo:in:
matches:
not
referencesTo:
referencesTo:in:
selectMethods:
|


There are also representations of instantiated and non-instantiated classes:

  RBAbstractClass #('name' 'newMethods' 'instanceVariableNames' 'model' 
'superclass' 'subclasses' 'removedMethods' 'realClass')
   RBClass #('classVariableNames' 'poolDictionaryNames' 'category')
   RBMetaclass #()

And 
 RBMethod #('class' 'compiledMethod' 'source' 'selector')

And there's RBNamespace:

 RBNamespace #('changes' 'environment' 'newClasses' 'removedClasses' 
'changedClasses' 'rootClasses' 'implementorsCache' 'sendersCache')

which gives a way to deal with multiple changes across a group of classes and 
methods. Its interface is more or less a duplicate of SystemDictionary, but 
it represents the future state of the contents of a BrowserEnvironment. At 
some point you can choose to go:

 someRBNamespace changes execute.

and actually commit the changes all at once.

There are also concrete representations of changes to the model (which provide 
execute and undo operations). These let you preview a set of changes.

Actually, what I'm doing right now (since we already had the 

  RefactoryChange #('name')
   CompositeRefactoryChange #('changes')
    RenameClassChange #('oldName' 'newName')
    RenameVariableChange #('className' 'isMeta' 'oldName' 'newName')
     RenameClassVariableChange #()
     RenameInstanceVariableChange #()
   RefactoryClassChange #('className' 'isMeta')
    AddClassChange #('definition' 'superclassName' 'instanceVariableNames' 
'classVariableNames' 'poolDictionaryNames' 'category')
     InteractiveAddClassChange #('controller' 'definedClass')
    AddMethodChange #('source' 'selector' 'protocols')
     InteractiveAddMethodChange #('controller' 'definedSelector')
    RefactoryVariableChange #('variable')
     AddClassVariableChange #()
     AddInstanceVariableChange #()
     AddPoolVariableChange #()
     RemoveClassVariableChange #()
     RemoveInstanceVariableChange #()
     RemovePoolVariableChange #()
    RemoveClassChange #()
    RemoveMethodChange #('selector')


I'd suggest that we consider using the RB model classes as a base for a future 
reflection and editing framework. They give a very clean interface to the 
system.

I should also note that the 'Monticello-Modeling' and 'Monticello-Patching' 
class could be mostly replaced by (or at least derived from) the 
'Refactory-Model' and 'Refactory-Change Objects' classes. 

-- 
Ned Konz
http://bike-nomad.com/squeak/