Mail Archives: geda-user/2016/08/02/21:44:03
> On Aug 2, 2016, at 3:40 PM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
>
> Edward Hennessy:
>> Roland Lutz:
>> > The core library should not know about GObjects in any way. Of > course, it would be possible to create a GObject wrapper for the core > library which could be used for creating language bindings.
>>
>> Sure, but its extra work to create all the wrapper objects. And wrapping RIAA with reference counting is a mess.
>
> RIAA and reference counting both don't make sense on this level. We're talking about a simple C library which defines some structs and declares functions to work on them. If you want a nice C++ class which allocates and frees e.g. a revision RIAA-like, just write it. Having this kind of logic in the library API just makes things unnecessarily complicated.
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.
>> > The library would use a value-oriented approach: the properties of a > schematic object are only defined in respect to a given revision. If > an application needed property change hooks, it could execute them > itself from the command which replaces its current revision with a new > one.
>>
>> Sure, the wrapper objects from above could provide property change notification. It’s extra work to manage this layer. And when scripts modify the “libcore” POD objects, it might not even be capable of determining a property change occurred.
>
> There's no such thing as a "change" in a value-oriented approach. That's intentional because having a place-oriented approach would force that model on all code parts, while it's easy the other way around.
>
> Detecting a property change is always possible because once you finalize a revision, no code part can change it (except by poking directly into memory). When a script creates a modified copy of a revision and passes it back to the main application, it can query for differences between the two revisions and act accordingly.
You are referring to programming with immutable objects?
If you are referring to immutable objects, then my take:
- they make command line and multi-threaded applications awesome
- they make GUI programming a giant mess
>> > I'm not sure what's your point here. Do you want to facilitate using > gschem widgets in other GTK applications? The actual Cairo rendering > code may be useful to non-GTK or even non-interactive applications.
>>
>> Exactly.
>
> Exactly what? libgedacairo is already available as a library which could, in theory, be used in other applications. The only problem I see right now is that it depends on the internal libgeda object representation which doesn't make much sense for applications outside the main geda-gaf repository.
Exactly refers to your question: "Do you want to facilitate using gschem widgets in other GTK applications?”
>> What is the downside of using Vala?
>
> Potential contributors would have to learn a new programming language.
>
>> What can go wrong and what is the chance of it going wrong?
>
> The single developer knowing Vala could leave the project. Mono could be bought by Microsoft and discontinued.
What is the upside to using Vala?
In regards to C#:
- Xamarin was already bought by Microsoft.
- Miguel de Icaza is now a Microsoft employee.
- Compilers and framework are being open sourced under the MIT license.
Some controversy and questions of Microsoft’s intent exist, but I’ll let the reader research on their own — it’s all speculative.
>> I disagree with you on the “libcore” responsibilities, because small amounts of additional code at this level can significantly reduce the amount of work needed to implement the GUI level.
>
> There's a difference between crafting a good API and merging application specifics into a library. What if a program should use the core library but isn't written in C++, or doesn't use GLib?
>
>> > 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.
You are not selling this technical direction:
- 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)
- Not using a more productive language (more work for the GUI programmer)
- Might decide to rewrite GUI in a different language, later (GUI programmer’s work thrown away)
Come on, just add something to make the GUI programmer’s job easier...
Ed
- Raw text -