Commonly, when importing a namespace using shared pool dictionaries, you wonder "why can't I just import this once for my entire namespace?" Well, in the upcoming 3.1, you can.

Eval [PackageLoader fileInPackages: #('Parser' 'NetClients')]

Namespace current: Test [
    <import: STInST>

    Object subclass: MyTest [
        test [^RBParser]
    ]

    <import: NetClients>

    MyTest extend [
        test2 [^URIResolver]
    ]
]

GST, and Smalltalk in general, has many more places in which to search for variables than most programming systems. Besides instance variables, in-class and inherited, the compiler has to search a number of pools:

• All inherited namespaces and their superspaces
• All inherited class pools
• All inherited shared pools

Traditionally, GST's search order has been somewhat idiosyncratic. This isn't a problem, of course, until you start making name clashes.

I have been thinking about my favorite programming languages: Smalltalk, Common Lisp, and Scheme. These languages have much in common, and share many features, all the way down to syntax extension. I tend to be working in or studying any of these three when I am not pushing PHP for money.

These languages have an amazing pedigree, and many of their features have been ever so slowly moving into the mainstream. So what keeps this little club so exclusive? Is it my affinity for Lisp macrology? Is it the necessarily corresponding dearth of built-in funny characters? Perhaps, but I also realized they shared lexical, non-local block return in common, an interesting feature that others seem to overlook.

All three languages encourage you to define new control structures procedurally, using higher-order functions. This is especially true of Smalltalk where even retrieving array and dictionary elements has useful¹ associated control structures:

anArray at: 42 ifAbsent: [self defaultAt: 42].
anArray at: 42 ifPresent: [:newElt |
    self defaultAt: 42 put: newElt].