X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 8 Aug 2016 13:04:33 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Edward Hennessy (ehennes AT sbcglobal DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] Plans for gEDA/gaf (was: [OT] ngspice integration
 in KiCad)
In-Reply-To: <9D48E76E-9D22-4708-A5E3-3AFF976C697B@sbcglobal.net>
Message-ID: <alpine.DEB.2.11.1608081223140.1856@nimbus>
References: <CANqhZFwC48g07MUY411a20C5oipkmmkzUimhz8OgvL2Thi-yDg AT mail DOT gmail DOT com> <20160723065723 DOT GC17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 00 DOT 1607231009290 DOT 7286 AT igor2priv> <20160723092248 DOT GF17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607231423480 DOT 2224 AT nimbus>
 <20160724053502 DOT GM17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607271434200 DOT 1841 AT nimbus> <9719FF2C-AC85-4824-89E9-447216E7FA65 AT sbcglobal DOT net> <alpine DOT DEB DOT 2 DOT 11 DOT 1607301258260 DOT 1409 AT nimbus> <939E39F7-B4DA-4B56-A640-C7E6E4ECF955 AT sbcglobal DOT net>
 <alpine DOT DEB DOT 2 DOT 11 DOT 1608021426490 DOT 1398 AT nimbus> <CAOP4iL2MsJG+U45C83zWevHcWwLoJAnYa9uYzM0fqoXvxg66qg AT mail DOT gmail DOT com> <9ED612EF-E3F5-48CC-8FB3-B67CA7DEE432 AT noqsi DOT com> <CAOP4iL1TcA4nzvCBJuFQ7GaOA-Owub2ikedXOvrcWipr9=buxA AT mail DOT gmail DOT com> <9D554144-D41A-463F-955F-68227BC3D167 AT noqsi DOT com>
 <CAOP4iL2mhxmbjkkLKTgbtME-VEmAFwQCAQGc412KKNfAdzA1og AT mail DOT gmail DOT com> <alpine.DEB.2.11.! 1608030034050 DOT 9981 AT nimbus> <9D48E76E-9D22-4708-A5E3-3AFF976C697B AT sbcglobal DOT net>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-758051510-1470654273=:1856"
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-758051510-1470654273=:1856
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Tue, 2 Aug 2016, Edward Hennessy (ehennes AT sbcglobal DOT net) [via 
geda-user AT delorie DOT com] wrote:
> If the system has a heap, and the code uses pointers, then something 
> must be used. Wrapping plain pointers with reference counting, RAII, or 
> garbage collection is a mess.

Using GLib or something similar would be way too heavyweight for the core 
library.  It may make sense for a GUI application, but you would force it 
onto any program which could be using the core library.  This would 
decrease its usefulness significantly.

If you look at the current data structures in libxornstorage, you'll see 
that your argument doesn't hold.  There's currently three kinds of opaque 
types (revisions, objects, and selestions), and nine object data structs 
(not counting helper structs).  Revisions bring their own "reference 
counting" because they're value-oriented; you can just create a revision 
whenever you'd create a smart pointer.  Objects and object data structs 
are managed via revisions, no need to allocate or free them yourself. 
The only type for which something like RAII would make sense are 
selections, and they are used rarely enough that this isn't a problem.

> You are referring to programming with immutable objects?

It's a hybrid approach: you can create a revision object, either from 
scratch or as a copy of an existing revision, and change it as you like. 
Then, once you "finalize" it, it becomes immutable.

This has the advantage that it significantly reduces the amount of 
create/free actions during the construction of a revision while it still 
allows to have immutable objects for e.g. undo/redo history.

> Exactly refers to your question: "Do you want to facilitate using gschem 
> widgets in other GTK applications?”

I'm not sure what would be the use case, but you could obviously do that. 
I don't think merging the libgedacairo library into the gschem widget 
library would be a good idea, though.  libgedacairo may be useful to 
applications which don't use the GTK toolkit.

>>>> Why would the core library need to know about scripting?
>>>
>>> For example, libgeda has the capability of executing a script to load 
>>> a component.
>>
>> The core library wouldn't have to know about scripting in order to 
>> allow that; providing a hook for adding custom library sources would be 
>> sufficient.
>
> You missed my point of dependency inversion and its BFF: dependency 
> injection.

What's better than dependency inversion/injection?  No dependency at all.

> - No memory management (more work for the GUI programmer)
> - Need to write wrapper objects for "libcore” (more work for the GUI 
> programmer)
> - No property change notification (more work for the GUI programmer)
> - No automatic bindings (more work for the GUI programmer)

See it the other way round: I want to keep the core library free of 
pollution from the GUI application.  That's the idea of a "core" library. 
The current libgeda is almost unusable by third-party applications exactly 
because it is too strongly coupled with gschem; I want to change that.

--8323329-758051510-1470654273=:1856--