[Top][All Lists]

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

Re: [Help-smalltalk] AbstractAutoload

From: Gwenaël Casaccio
Subject: Re: [Help-smalltalk] AbstractAutoload
Date: Fri, 7 Jan 2011 10:21:39 +0100

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 ?


On Thu, Jan 6, 2011 at 10:30 AM, Denis Washington <address@hidden> 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?
> Regards,
> Denis
> _______________________________________________
> help-smalltalk mailing list
> address@hidden

reply via email to

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