[gclist] glib/gtk w/ GC

[Enrico Weigelt]

On Thu, Feb 20, 2003 at 11:25:06PM +1000, Steven Shaw wrote:

<snip>
> You wish to convince people to use gc?
> 
> What I'm trying to say is that some people who use glib who wouldn't want gc
> (perhaps because they couldn't live with the downside).
No, i simply want an lib like glib, but gc-based.
I'll then start porting some applications to this one.

<snip>
> > > You might find some resistance to what you propose because of that.
> > > I guess you are proposing a fork anyways?
> > Well, i dont care of them. An forkoff will me necessary, because
> > this new lib _will_ break the existing interfaces.
> 
> Sure. I guess everyone using original-glib can continue to use that if they
> want. Others can adopt the new gc-glib you propose.
Yes, but that's not the whole point. 
IMHO it is very important, that an library which is meant to be production
stable _must_ provide at least the same interface (or an derived one) of
it's earlier version, so it can _always_ be used as an drop-in replacement
for the older versions.

> > btw: at this point we also should start defining _strict_ interfaces,
> > which must bei 100% reliable: if an version a supports some interface,
> > the following versions _must_ continue providing them.
> 
> Tell me more about _strict_ interfaces. Why are you so concerned over it?
> Are you proposing something like MS-COM?
No, i'm speaking of library/module interfaces at several points of view.
Let's take some examples:

* glib-1.2-binary-i386:
    + derived from glib-1.1-binary-i386
    + runs on systems which provide i386 processor enviroment
    + links clients against glib.so.1.2-i386
    + exported functions (w/ function signatures, ...)

* glib-1.2-binary-i686:
    + derived from glib-1.2-binary-i686
    + runs on systems which provide i686 processor enviroment
    + links clients against glib.so.1.2-i686
    + exported functions ...

* glib-1.2-C-include:
    + derived from glib-1.1-C-include
    + provides functions, types, variables, defines
    + provides rules for interface translation on compile time
    + specifies pathes, etc.    

So if we are doing an translation (loading an binary into an VM dyn. linking
is also an translation process just as compiling sources to binaries)

Now we're compiling an application againgst glib, we import the interface
glib-1.2-C-include. The translator now knows evrything about the glib's 
C-binding necessary to build an glib-based application. As an product of
this translation we have an package which needs glib as an dynamic library
in some special binary format (i.e.i686), do it requires the appropriate
interface (glib-1.2-binary-i686)

> I wish there was a programming system where it was easy to have constant
> (inevitable) evolution of the interfaces; where old libraries can be used
> side-by-side with new ones. 
Yes, i want to enforce this. It's an kind of design-by-contract.

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux ITS 
 Webhosting ab 5 EUR/Monat.          UUCP, rawIP und vieles mehr.

 phone:     +49 36207 519931         www:       http://www.metux.de/     
 fax:       +49 36207 519932         email:     contact@metux.de
 cellphone: +49 174 7066481	     smsgate:   sms.weigelt@metux.de
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/