X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1470699968; bh=FOXOLMPeYMk1TT1APme5htRbjkuiWJMD96xZbQ/pIrw=; h=Subject:From:In-Reply-To:Date:References:To:From:Subject; b=rUak6MI00yHp523bUE19mNOLnr+QUge2Yfym7xj3IiPtMNvFXE60QgvdKJ5/xsENHSWDLBQbDD2U5vaiURgueGyZXny4zpAaiabt7HGdpV2Y2U6PobJRVI9hqjGEc2faI1DWaO/HRR0L0OqcDrwc0ZS741GIo8Tch7+ohxc6wey3KuR8NE6r1P4xB75SOSIiO9cT287FRaQSMPGzEV5aEyr6ckiTa8LG9IM/GDMIzuXK8drVaQbStn6U2duCsPxTAlTeyAf13s4mqZ44ozITc3fc/fm9yQKvUaZjNp9rwSLGg44SkUC2yG766vlp7X/Nifu6ZPBjDfUTFSobpQkpSQ==
X-Yahoo-Newman-Id: 606201 DOT 52157 DOT bm AT smtp113 DOT sbc DOT mail DOT gq1 DOT yahoo DOT com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 6CBhLQYVM1nDVkkSizfG5MTztZm2va3eFQ9TAGTQOQ1xViG
 mosXw4P0n2NpHCgN6FSnholnSo4MoQCio9dZFYZPOqlSPu97PoRVZZ8_di.s
 SuQBhfP4Odt.VrgjL_hn58H5n1qmJTLbFk8JUl.6ZVjVrK9o37Z.LgygcvjI
 4RBMP6YkYRbRxkarfZ7GWXqjw5nMGKYy0BJ2Hde498.iNBX1OPEuP4geqfzk
 AUZxWVEucxVaWVDUDGwSjE6jA7D8CrGAJh7eve22wwUktUDji6TFQNkr4gPO
 uhJI1Fp.8WV7Fj9iGfAg6kdHq5DaofLvhq50FghPnFXbQfbefzBGSI6642or
 VycICQ9Xu.OguWzqUWmX8dW0iMN6VWmZUd.zTYrtL0L_8Bzk_wpc7lsZCam1
 wLc8td7YllioTFf12KioECoj3HUza8E_S7NEuDkXr09Pc0cQe2tTwrn0y8Zr
 Q_DejNurtefsQm7ayiUUQgjjRfRm97LvyVQ4mVEPWfrV42K1AswmeOCGeno2
 rtN4qqJoEuIyQvY5unxOHyx2_73wDBghrUYHnmmuSGeYZ2dD7tHaObTZ5bUO
 W
X-Yahoo-SMTP: b8jVkbOswBAqZ4BhECp7nxPJUfTGEnEGv_G4qgQeZMeAbA--
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [geda-user] Plans for gEDA/gaf (was: [OT] ngspice integration in KiCad)
From: "Edward Hennessy (ehennes AT sbcglobal DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
In-Reply-To: <alpine.DEB.2.11.1608081223140.1856@nimbus>
Date: Mon, 8 Aug 2016 16:46:06 -0700
Message-Id: <AAC80DBF-E554-4B75-BD20-8D4A5F07EC23@sbcglobal.net>
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> <alpine DOT DEB DOT 2 DOT 11 DOT 1608081223140 DOT 1856 AT nimbus>
To: "geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
X-Mailer: Apple Mail (2.3124)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u78NkCFf019797
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


> On Aug 8, 2016, at 4:04 AM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
> 
> 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.

I’m still not understanding what you are getting at here. It still sounds like immutable objects and functional programming.

This paradigm works well for many situations:
- undo/redo, like you describe.
- multithreaded programming - no mutexes required.
- print spooling - the object tree does not become temporarily read-only during the operation.

However, GUI programming is still OO. I haven’t seen a functional programming UI developed and current GUI toolkits use an OO approach. Creating the adapter layer between the OO and functional programming layers is a mess.

The GUI must to maintain the identity of objects. For example, when one widget is editing the coordinates of a line and another is editing the color of a line, and when the color is changed, the widget editing coordinates must still refer to the same line — not the mutated copy.  In the OO paradigm, this identity is simply the pointer to the object. In functional programming, some other mechanism must be used.

GUI widgets that are editing objects must be aware of the object’s lifespan. Both reference counting and weak pointers can assist with this adaptation. Having an unmanaged or “raw” pointer is both difficult to manage and error prone.

An adapter layer would help the GUI around issues bolting to a functional paradigm. Would you to help create this layer?

>> 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.

I disagree. Dependency inversion is an excellent mechanism to decouple two systems. And, library dependencies are an excellent mechanism to leverage the work of other developers.

>> - 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.

Sure, there is tight coupling between the two modules. And, some of the functionality could be either pushed into the GUI, or could be made optional in the library. What was your plan for correcting pollution? (A term I disagree with.)

So far, I’m not seeing any common ground the direction of the project a whole. Is that the way you are being it too?

Ed