From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11281 invoked by alias); 2 Jun 2003 06:51:22 -0000 Mailing-List: contact guile-gtk-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-gtk-owner@sources.redhat.com Received: (qmail 11246 invoked from network); 2 Jun 2003 06:51:22 -0000 Received: from unknown (HELO imf47bis.bellsouth.net) (205.152.58.151) by sources.redhat.com with SMTP; 2 Jun 2003 06:51:22 -0000 Received: from fridge ([68.154.193.135]) by imf47bis.bellsouth.net (InterMail vM.5.01.04.25 201-253-122-122-125-20020815) with ESMTP id <20030602065336.NQFD2907.imf47bis.bellsouth.net@fridge> for ; Mon, 2 Jun 2003 02:53:36 -0400 Received: from lark (mantis.schoolnet.na [::ffff:196.44.140.238]) (AUTH: LOGIN wingo) by fridge with esmtp; Mon, 02 Jun 2003 02:51:03 -0400 Received: from wingo by lark with local (Exim 3.36 #1 (Debian)) id 19KLhT-0003my-00 for ; Mon, 26 May 2003 18:23:55 +0100 Date: Mon, 02 Jun 2003 06:51:00 -0000 From: Andy Wingo To: guile-gtk@sources.redhat.com Subject: Re: GError Message-ID: <20030526172355.GA6014@lark> Mail-Followup-To: guile-gtk@sources.redhat.com References: <20030524113300.GB24132@lark> <87addamxbz.fsf@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87addamxbz.fsf@zip.com.au> X-Operating-System: Linux lark 2.4.20 User-Agent: Mutt/1.5.4i X-SW-Source: 2003-q2/txt/msg00125.txt.bz2 Hi Kevin, On Mon, 26 May 2003, Kevin Ryde wrote: > Andy Wingo writes: > > > > With regards to GError, I think the solution you propose is too much > > like C programming. > > Oh, well, if it's nice and close then at least people familiar with > the C style will find the guile interface comfortingly similar. Or > vice versa even. I'm not sure that an identical function mapping is really a goal. I am programming in scheme because I prefer it to C. In making these bindings, the goal has been to make the functionality of the gnome APIs available from scheme, not strict API transliteration. I don't think throwing exceptions will bother anyone who chooses scheme over C. A quick search through gnome/defs shows the following occurences of GError: * Gdk: 7 uses, all regarding file i/o (pixbuf loading and saving, mostly) * Pango: 1 use, pango_parse_markup * GConf: a boatload of uses, for a boatload of reasons: permissions, client-server communication, etc etc * applets: 1 use, setting something gconf-related * libgnome: 4 uses, regarding failure to display help or uris * glib: only appears in g_error_* These are the sorts of things exceptions are made for. Furthermore, exposing GError to the programmer leads to nastiness on the scheme side of things. You could implement exceptions by adding 'c-only to the typespec and extending g-wrap to ignore, from the scheme side, parameters with 'c-only in their typespecs. The scm->c and c->scm ccodegens would still be run, however, allowing the error to be initialized and checked. regards, wingo.