Re: [Help-smalltalk] AbstractAutoload

[Paolo Bonzini]

On 01/06/2011 10:30 AM, Denis Washington wrote:
> Hi,
>
> First of all, I'd like to introduce myself. My name is Denis Washington, 
> and I am a student living in Berlin, Germany. I just stumbled upon GNU 
> Smalltalk a few months ago, and I must say I love it! I am really 
> impressed by the beauty of Smalltalk, especially when being able to use 
> it in the "for-those-who-can-type" style that GNU Smalltalk supports. 
> Many thanks to Paolo and everyone else who made this happen!
>
> I am currently playing with the idea of implementing GObject 
> Introspection [1] bindings for GNU Smalltalk, which would allow the 
> run-time generation of bindings for GObject libraries with the 
> appropiate introspection metadata. This does not only include GTK+ and 
> Glib, but many others such as Clutter and GStreamer, for which we would 
> then have bindings "for free". I don't know if I have the skills needed 
> to do this (I know C fairly well, but am only learning Smalltalk), but I 
> guess it doesn't hurt to try. ;)
>
> Anyway, here is my actual question. I want to implement the bindings 
> generation lazily - a GObject class should be bound only if and when it 
> is first needed. I looked through the base classes and found out that 
> there is an Autoload class which does something similar, but only does 
> autoloading through file-ins. Therefor, I propose the addition of an 
> AbstractAutoload as a superclass of Autoload where most functionality of 
> Autoload is moved, plus the ability to let subclasses specify how a 
> class is autoloaded. For instance, it could have a class method 
> class:in:loadDo: that allows to create subclasses like the following:
>
> AbstractAutoload subclass: GObjectAutoload [
>
> class: nameSymbol in: aNamespace [
> ^super
> class: nameSymbol
> in: aNamespace
> load: [
> "Create wrapper for GObject class and return it"
> ];
> yourself
> ]
> ]
>
> Such an AbstractAutoload would probably also have other uses, for 
> instance for other automatic bindings or similar magic.
>
> What do you think?

With the attached any object that implements #autoload can be used as
a loader.  This ensures that the black magic stays confined in
Autoload/AutoloadClass.  For example:

st> Eval [ Autoload class: #Complex in: Smalltalk loader: (PackageLoader 
packageAt: 'Complex'). nil ]
"Global garbage collection... done"
nil
st> Complex real: 1 imaginary: 2
Loading package Complex
(1+2i)

(Complex is not a great example since the constructor method #i is not present, 
but you get the idea).

Paolo

autoload-v3.patch
Description: Text document