Mail Archives: geda-user/2016/08/08/07:06:38
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--
- Raw text -