AbstractAutoload

> 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?
>
> Regards,
> Denis
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk
>

> On 07.01.2011 10:21, Gwenaël Casaccio wrote:
>>
>> Hi Denis,
>>
>> First of all welcome Denis ;-). Having GObject introspection would be
>> very cool, I've made an initial work
>> but never finish it. Lazy generation would be nice but why not as a
>> second step, first generate the binding after do it lazily ?
>>
>> Cheers,
>> Gwen
>
> Yes, that would probably be the best. It just striked me that something like
> AbstractAutoload might be valuable to more people than just me, that's why I
> posted it here.
>
> Cool to hear that you also started to work on GObject introspection
> bindings, would you mind to send me what you wrote or put it to some public
> place so that I can take a look? That would help me a lot! Maybe we could
> even work together on making the binding happen.
>
> Denis
>

> On 07.01.2011 10:21, Gwenaël Casaccio wrote:
>>
>> Hi Denis,
>>
>> First of all welcome Denis ;-). Having GObject introspection would be
>> very cool, I've made an initial work
>> but never finish it. Lazy generation would be nice but why not as a
>> second step, first generate the binding after do it lazily ?
>>
>> Cheers,
>> Gwen
>
> Yes, that would probably be the best. It just striked me that something like
> AbstractAutoload might be valuable to more people than just me, that's why I
> posted it here.

> 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