('SqueakLink-Connections' OracleConnection MySQLConnection PostgresConnection) ('SqueakLink-Model' DBTable DBRow DBQuery)and so on. But not all of your code will reside in these classes! For example, you may also have a series of methods to convert objects into an SQL-friendly format:
Object>>asSQL String>>asSQL Date>>asSQLThese extensions belong in the same package as the classes in 'SqueakLink-Connections' and 'SqueakLink-Model'. You mark this by placing those methods in a method category (of Object, String, Date, and so on) named '*squeaklink' (note the initial star). The combination of the 'SqueakLink-...' system categories and the '*squeaklink' method categories form a package named "SqueakLink". The rules, to be precise, are this: a package named "Foo" contains
refactory := PackageInfo named: 'RefactoringEngine'.It is now possible to introspect on this package; for example, refactory classes will return the long list of classes that make up the Refactoring Engine and the Refactoring Browser. refactory coreMethods will return a list of MethodReferences for all of the methods in those classes. refactory extensionMethods is perhaps one of the most interesting queries: it will return a list of all methods contained in the RefactoringEngine package but not contained within a RefactoringEngine class. This includes, for example, ClassDescription >> chooseThisClassInstVarThenDo: and SharedPool class >> keys.
Since the PackageInfo naming conventions are based on those used already by Squeak, it is
possible to use it to perform analysis of code that has not explicitly adapted to work with
it. For example, (PackageInfo named: 'Collections') externalSubclasses will return a
list of all Collection subclasses outside the Collections categories.
You can send #fileOut to an instance of PackageInfo to get a changeset of the