[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] AbstractAutoload

From: Paolo Bonzini
Subject: Re: [Help-smalltalk] AbstractAutoload
Date: Mon, 10 Jan 2011 13:05:40 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6

On 01/06/2011 10:30 AM, Denis Washington wrote:

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 [
class: nameSymbol
in: aNamespace
load: [
"Create wrapper for GObject class and return it"

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"
st> Complex real: 1 imaginary: 2
Loading package Complex

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


Attachment: autoload-v3.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]