From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Avoid GOOPS in (system foreign-object)? Date: Fri, 22 May 2015 10:50:25 +0200 Message-ID: References: <87wq022bn3.fsf@gnu.org> <87oaldm2a9.fsf@gnu.org> Reply-To: mikael@djurfeldt.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3a82e25249b80516a7c0d3 X-Trace: ger.gmane.org 1432284637 3030 80.91.229.3 (22 May 2015 08:50:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 May 2015 08:50:37 +0000 (UTC) Cc: Andy Wingo , guile-devel To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri May 22 10:50:36 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yvif5-00045X-4k for guile-devel@m.gmane.org; Fri, 22 May 2015 10:50:35 +0200 Original-Received: from localhost ([::1]:60944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yvif4-0000O4-Es for guile-devel@m.gmane.org; Fri, 22 May 2015 04:50:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yviey-0000Ny-2l for guile-devel@gnu.org; Fri, 22 May 2015 04:50:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yview-0007w0-MU for guile-devel@gnu.org; Fri, 22 May 2015 04:50:27 -0400 Original-Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]:34128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yview-0007vf-7R; Fri, 22 May 2015 04:50:26 -0400 Original-Received: by wghq2 with SMTP id q2so11169068wgh.1; Fri, 22 May 2015 01:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EtoDzhyo+fRSiv6K1mVrpfkwVSKW8Z6Iq6fhKfoK2Fg=; b=zLqOZud5y8pfIUZM9eME8ePAW2TsZpsAay7r/inqXO9uhuXtfBzkRhtDPHWDBWDqw4 xGXyFkc+wNPOKJIst0klPr6a9CnYI09JFJRZnmp/xuPd8fpCd2a365uNMKHcNkSvVuHK 5hUrMMiKDogBFe6Q0er8z0hJbMlLKdA/1mrTbfiCyATWbd04AljOPfVr1//+Q6YP1AJO 51qR0YodTIySbVpfAYWP1wpba3gLhAFIf1TU4vIo0H+iLVjxny7nal06URGF/wqotNc4 UvgV+wzBJTxez6O4F7meWJIRkFDmNnYQOqUEwDi91YYapK7RptWE7pin4gOoy7yFdET2 IPFQ== X-Received: by 10.194.209.130 with SMTP id mm2mr12752002wjc.64.1432284625519; Fri, 22 May 2015 01:50:25 -0700 (PDT) Original-Received: by 10.194.80.167 with HTTP; Fri, 22 May 2015 01:50:25 -0700 (PDT) In-Reply-To: <87oaldm2a9.fsf@gnu.org> X-Google-Sender-Auth: po5mFRSKNFsLGJ_XukKGBIu5N5I X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::233 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17724 Archived-At: --047d7b3a82e25249b80516a7c0d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 22, 2015 at 10:42 AM, Ludovic Court=C3=A8s wrote= : > > Just wanted to say that I think that we (or at least I) at some point i= n > > time had the goal to replace structs with pure GOOPS data structures. I= n > > the context of FFI, this would allow you to be more flexible than what > > structs allow, ultimately being able to access arbitrary C structs and > C++ > > structs/classes directly from Scheme. I find that a proper MOP (which > > maybe still is not fully developed) is a nicer way to handle non-standa= rd > > access than the strange character strings in struct vtables... > > The struct layout strings are a bit clunky, indeed. ;-) I like the > flexibility that GOOPS provide, especially when it comes to extending > things like =E2=80=98equal?=E2=80=99, =E2=80=98write=E2=80=99, and so on. > > I think it=E2=80=99s better if GOOPS is not a requirement for basic inter= faces > like this SMOB replacement, though. One of the concerns is performance. > For instance, in 2.0, start-up time with GOOPS is on the order of 3 > times higher than without it > Right, but it's probably possible to re-organize things such that it's not necessary to load all of GOOPS to use basic interfaces, even if everything is based on a common non-struct data type... Just meant as input---do what you think is best! --047d7b3a82e25249b80516a7c0d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 22, 2015 at 10:42 AM, Ludovic Court=C3=A8s <ludo@g= nu.org> wrote:
> Just wanted= to say that I think that we (or at least I) at some point in
> time had the goal to replace structs with pure GOOPS data structures. = In
> the context of FFI, this would allow you to be more flexible than what=
> structs allow, ultimately being able to access arbitrary C structs and= C++
> structs/classes directly from Scheme.=C2=A0 I find that a proper MOP (= which
> maybe still is not fully developed) is a nicer way to handle non-stand= ard
> access than the strange character strings in struct vtables...

The struct layout strings are a bit clunky, indeed.=C2=A0 ;-)=C2=A0 = I like the
flexibility that GOOPS provide, especially when it comes to extending
things like =E2=80=98equal?=E2=80=99, =E2=80=98write=E2=80=99, and so on.
I think it=E2=80=99s better if GOOPS is not a requirement for basic interfa= ces
like this SMOB replacement, though.=C2=A0 One of the concerns is performanc= e.
For instance, in 2.0, start-up time with GOOPS is on the order of 3
times higher than without it

Right, but= it's probably possible to re-organize things such that it's not ne= cessary to load all of GOOPS to use basic interfaces, even if everything is= based on a common non-struct data type...=C2=A0 Just meant as input---do w= hat you think is best!
--047d7b3a82e25249b80516a7c0d3--