Mail Archives: geda-user/2016/08/08/19:47:43
> 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
- Raw text -