[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:1.9.2.12) 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:
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