C++ work

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

C++ work

Aaron Laws
The short question is: What GUI framework is gnucash likely to target in
c++?

I've heard it mentioned that the current framework (GTK?) doesn't make
sense in c++ because it's so gobject-oriented, but I didn't hear anything
else suggested. I know there's a QT effort which seems like a reasonable
way to go, but haven't heard it actually endorsed anywhere.

Currently, c++ work is starting at the deepest point (the part of the code
that is relied on by everything), qof, so that a C api has to be maintained
until everything that relies on QOF has a way of accessing the c++
interfaces. This means that c++ and C interfaces need to be created and
maintained in parallel until everything's ready to switch. This has grated
on me for quite a while, but I see it as a very difficult problem. I don't
see a quick way to fix it. I've tried (and technically succeeded ^_^)
compiling the whole project as c++, but that's not so great because the
dynamic linking doesn't work because of mangling. Repairing this solution
doesn't seem like a profitable way forward. It's sort of like throwing all
your belongings into a river, then swimming across yourself, and trying to
collect everything on the other side, making sure you didn't lose anything.

Another way that I've been trying to consider is to start on the part of
project upon which nothing relies. That way, that part of the project can
be completely C++. Then, take the next thing which doesn't expose a *used*
C api. Rinse and repeat. This way, there will never (?) have to be a
duplicated API in any system.

Another way to think about this is as a tree structure. I'll throw
something up, and I'll eagerly await corrections! Read "->" as "relies on":

GUI (GTK?) -> Business Logic
Alternate gui (WEB?) -> Business Logic
GUI (GTK?) -> Reporting Infrastructure
Business Logic -> QOF
Reporting Infrastructure -> QOF
QOF -> libdrm, etc.

So, if QOF is changed, it still needs to support Business Logic with a C
api until Business Logic is changed which can't happen until all GUIs that
rely on it are changed. If, however, a gui layer is changed, that's all
there is to it; there are no dependencies (if there are, we should have
started at the dependency!). Once all GUIs (I know there's only one, but
I'm trying to create a sufficiently complicated example!) are c++-ready,
the Business Logic can be converted. No redundant API is necessary.

I'm having trouble even evaluating what I'm talking about because I don't
know any details. Knowing which GUI framework development efforts have in
mind would help a ton :-).

In Christ,
Aaron Laws
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

Mike Alexander
--On September 9, 2014 at 3:12:33 PM -0400 Aaron Laws
<[hidden email]> wrote:

> Currently, c++ work is starting at the deepest point (the part of the
> code that is relied on by everything), qof, so that a C api has to be
> maintained until everything that relies on QOF has a way of accessing
> the c++ interfaces. This means that c++ and C interfaces need to be
> created and maintained in parallel until everything's ready to
> switch. This has grated on me for quite a while, but I see it as a
> very difficult problem. I don't see a quick way to fix it.

I don't agree that this is such a big problem.  Keeping existing C
interfaces to code rewritten in C++ isn't that big a deal.  Sure, it
adds a little bit of work, but not much compared to the work of
converting the code to a proper class hierarchy in C++.  I went through
all this in another project of similar size to GnuCash so I have some
experience with the problems involved.  The approach we took there was
mostly to rewrite things in C++ if they were going to be rewritten or
extensively modified anyway.  Sometimes things were rewritten because
the benefits of using C++ seemed great enough to be worth the effort,
but we certainly didn't try to avoid C dependencies on C++ code.  When
I left the company it was about half converted.  That was 8 years ago,
and I suspect there are still parts that are in C because it isn't
worth the cost to rewrite them.

            Mike
 
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

Geert Janssens
In reply to this post by Aaron Laws
On Tuesday 09 September 2014 15:12:33 Aaron Laws wrote:
> The short question is: What GUI framework is gnucash likely to target
> in c++?
>
Equally short answer: likely Qt or WxWidgets. But we never did a detailed evaluation yet.

> I've heard it mentioned that the current framework (GTK?) doesn't make
> sense in c++ because it's so gobject-oriented, but I didn't hear
> anything else suggested. I know there's a QT effort which seems like
> a reasonable way to go, but haven't heard it actually endorsed
> anywhere.
>
Exactly

> Currently, c++ work is starting at the deepest point (the part of the
> code that is relied on by everything), qof, so that a C api has to be
> maintained until everything that relies on QOF has a way of accessing
> the c++ interfaces. This means that c++ and C interfaces need to be
> created and maintained in parallel until everything's ready to
> switch. This has grated on me for quite a while, but I see it as a
> very difficult problem. I don't see a quick way to fix it. I've tried
> (and technically succeeded ^_^) compiling the whole project as c++,
> but that's not so great because the dynamic linking doesn't work
> because of mangling. Repairing this solution doesn't seem like a
> profitable way forward. It's sort of like throwing all your
> belongings into a river, then swimming across yourself, and trying to
> collect everything on the other side, making sure you didn't lose
> anything.
>
> Another way that I've been trying to consider is to start on the part
> of project upon which nothing relies. That way, that part of the
> project can be completely C++. Then, take the next thing which
> doesn't expose a *used* C api. Rinse and repeat. This way, there will
> never (?) have to be a duplicated API in any system.
>
Sounds nice in theory. I fear it will be equally if not more difficult than the current approach
though.

Taking your example of first replacing the gui.

As you bring up yourself it is heavily gobject based. And in addition the controller, model and
view code are mixed up. Rewriting it in (say) Qt, means it will now use Qt objects. But the
"business logic" (our engine code) is still gobject based.

So now in order for the gui to talk to the business logic you have to create an interface layer
between the engine and the gui that will do the proper translations between the two object
models. That is probably more work than maintaining the existing C api in the path currently
chosen.

In addition logically it doesn't make sense to start from the gui and drill down to the model.
Your gui should be based on the model and controller logic so it only makes sense to start there.
Going the other way around as a sure way to make wrong assumptions about how the lower
layers will be implemented and in the best case mean several revisions to the higher layers or
having to start over in the worst case.

> Another way to think about this is as a tree structure. I'll throw
> something up, and I'll eagerly await corrections! Read "->" as "relies
> on":
>
> GUI (GTK?) -> Business Logic
So rewrite the gui and an interface layer between the two
> Alternate gui (WEB?) -> Business Logic
Same here.
> GUI (GTK?) -> Reporting Infrastructure
Same here.
> Business Logic -> QOF
Rewrite the business logic and write an interface layer between the two.
Oops, the way we write the business logic now means we need to change the gui layer, because
it made some invalid assumptions on what the business logic would be.
So rewrite the gui here as well
> Reporting Infrastructure -> QOF
Rewrite the reporting infrastructure and write an interface layer between the two.
Oops, the way we write the reporting infrastructure now means we need to change the gui
layer, because it made some invalid assumptions on what the business logic would be.
So rewrite the gui here as well

> QOF -> libdrm, etc.
Rewrite qof and realize we end up with a different implementation that we thought we would.
So rewrite the business logic and the reporting infrastructure once more. And bollocks, that kills
our gui design again. Rewrite the gui...

>
> So, if QOF is changed, it still needs to support Business Logic with a
> C api until Business Logic is changed which can't happen until all
> GUIs that rely on it are changed. If, however, a gui layer is
> changed, that's all there is to it; there are no dependencies (if
> there are, we should have started at the dependency!). Once all GUIs
> (I know there's only one, but I'm trying to create a sufficiently
> complicated example!) are c++-ready, the Business Logic can be
> converted. No redundant API is necessary.
>
See my worst case but not unlikely scenario above. I predict much more work when working top
down because it's impossible to rely on a lower level interface if the implementation hasn't
been done yet.

Regards,

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

John Ralls-2

On Sep 9, 2014, at 2:24 PM, Geert Janssens <[hidden email]> wrote:

> On Tuesday 09 September 2014 15:12:33 Aaron Laws wrote:
>> The short question is: What GUI framework is gnucash likely to target
>> in c++?
>>
> Equally short answer: likely Qt or WxWidgets. But we never did a detailed evaluation yet.
>
>> I've heard it mentioned that the current framework (GTK?) doesn't make
>> sense in c++ because it's so gobject-oriented, but I didn't hear
>> anything else suggested. I know there's a QT effort which seems like
>> a reasonable way to go, but haven't heard it actually endorsed
>> anywhere.
>>
> Exactly
>
>> Currently, c++ work is starting at the deepest point (the part of the
>> code that is relied on by everything), qof, so that a C api has to be
>> maintained until everything that relies on QOF has a way of accessing
>> the c++ interfaces. This means that c++ and C interfaces need to be
>> created and maintained in parallel until everything's ready to
>> switch. This has grated on me for quite a while, but I see it as a
>> very difficult problem. I don't see a quick way to fix it. I've tried
>> (and technically succeeded ^_^) compiling the whole project as c++,
>> but that's not so great because the dynamic linking doesn't work
>> because of mangling. Repairing this solution doesn't seem like a
>> profitable way forward. It's sort of like throwing all your
>> belongings into a river, then swimming across yourself, and trying to
>> collect everything on the other side, making sure you didn't lose
>> anything.
>>
>> Another way that I've been trying to consider is to start on the part
>> of project upon which nothing relies. That way, that part of the
>> project can be completely C++. Then, take the next thing which
>> doesn't expose a *used* C api. Rinse and repeat. This way, there will
>> never (?) have to be a duplicated API in any system.
>>
> Sounds nice in theory. I fear it will be equally if not more difficult than the current approach
> though.
>
> Taking your example of first replacing the gui.
>
> As you bring up yourself it is heavily gobject based. And in addition the controller, model and
> view code are mixed up. Rewriting it in (say) Qt, means it will now use Qt objects. But the
> "business logic" (our engine code) is still gobject based.
>
> So now in order for the gui to talk to the business logic you have to create an interface layer
> between the engine and the gui that will do the proper translations between the two object
> models. That is probably more work than maintaining the existing C api in the path currently
> chosen.
>
> In addition logically it doesn't make sense to start from the gui and drill down to the model.
> Your gui should be based on the model and controller logic so it only makes sense to start there.
> Going the other way around as a sure way to make wrong assumptions about how the lower
> layers will be implemented and in the best case mean several revisions to the higher layers or
> having to start over in the worst case.
>
>> Another way to think about this is as a tree structure. I'll throw
>> something up, and I'll eagerly await corrections! Read "->" as "relies
>> on":
>>
>> GUI (GTK?) -> Business Logic
> So rewrite the gui and an interface layer between the two
>> Alternate gui (WEB?) -> Business Logic
> Same here.
>> GUI (GTK?) -> Reporting Infrastructure
> Same here.
>> Business Logic -> QOF
> Rewrite the business logic and write an interface layer between the two.
> Oops, the way we write the business logic now means we need to change the gui layer, because
> it made some invalid assumptions on what the business logic would be.
> So rewrite the gui here as well
>> Reporting Infrastructure -> QOF
> Rewrite the reporting infrastructure and write an interface layer between the two.
> Oops, the way we write the reporting infrastructure now means we need to change the gui
> layer, because it made some invalid assumptions on what the business logic would be.
> So rewrite the gui here as well
>
>> QOF -> libdrm, etc.
> Rewrite qof and realize we end up with a different implementation that we thought we would.
> So rewrite the business logic and the reporting infrastructure once more. And bollocks, that kills
> our gui design again. Rewrite the gui...
>
>>
>> So, if QOF is changed, it still needs to support Business Logic with a
>> C api until Business Logic is changed which can't happen until all
>> GUIs that rely on it are changed. If, however, a gui layer is
>> changed, that's all there is to it; there are no dependencies (if
>> there are, we should have started at the dependency!). Once all GUIs
>> (I know there's only one, but I'm trying to create a sufficiently
>> complicated example!) are c++-ready, the Business Logic can be
>> converted. No redundant API is necessary.
>>
> See my worst case but not unlikely scenario above. I predict much more work when working top
> down because it's impossible to rely on a lower level interface if the implementation hasn't
> been done yet.

What Geert mentioned in passing but left out of his discussion is that there’s a lot of business logic code mixed into the GUI code. That has to be teased out and separated so that the model stuff goes down into the engine where it belongs and the stuff that’s just computation for display or input goes into some middle classes in separate directories, and the GUI directories contain just the code which describes the GUI itself, calling the controller classes as they need.

The pushing the model stuff down into the engine part of that job makes the most sense to do when the engine is migrated, but the extracting part could be done now. In fact having the pieces clearly separated ahead of time would make it easier to define the engine API when the time comes.

And oh-by-the-way, there’s also some GUI that’s still in scheme and has business logic in it that the C parts of GnuCash can’t see at all. That also needs to get pulled apart into the appropriate MVC layers.

All of that aside, there’s a fundamental flaw in your reasoning. If you write a new C++ GUI, even if there wasn’t an MVC separation issue, all of the controller calls would be to C functions, because that’s what the controller layer if it existed would be written in. It would in turn be calling C functions in the model layer, because that’s what the engine is written in. So even if nothing changed, you’d still be in the position of rewriting each upper layer over to operate on C++ objects instead of GObject objects as you drill down. Everything would be done twice as a *best* case.

Regards,
John Ralls




_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

Ted Creedon-2
mark up the screenshots with proposed changes

then write the user's manual, systems administrator's manual & systems
administrator's reference manual - submit for comments & approvals

then write C++ header files that wrap your subroutines &compile & link

only then can you begin code conversion

writing code is the last step, not the first step - and its very boring-
but you do get zero defect code

tedc
retired senior project manager
Tektronix Research Labs

On Tue, Sep 9, 2014 at 2:50 PM, John Ralls <[hidden email]> wrote:

>
> On Sep 9, 2014, at 2:24 PM, Geert Janssens <[hidden email]>
> wrote:
>
> > On Tuesday 09 September 2014 15:12:33 Aaron Laws wrote:
> >> The short question is: What GUI framework is gnucash likely to target
> >> in c++?
> >>
> > Equally short answer: likely Qt or WxWidgets. But we never did a
> detailed evaluation yet.
> >
> >> I've heard it mentioned that the current framework (GTK?) doesn't make
> >> sense in c++ because it's so gobject-oriented, but I didn't hear
> >> anything else suggested. I know there's a QT effort which seems like
> >> a reasonable way to go, but haven't heard it actually endorsed
> >> anywhere.
> >>
> > Exactly
> >
> >> Currently, c++ work is starting at the deepest point (the part of the
> >> code that is relied on by everything), qof, so that a C api has to be
> >> maintained until everything that relies on QOF has a way of accessing
> >> the c++ interfaces. This means that c++ and C interfaces need to be
> >> created and maintained in parallel until everything's ready to
> >> switch. This has grated on me for quite a while, but I see it as a
> >> very difficult problem. I don't see a quick way to fix it. I've tried
> >> (and technically succeeded ^_^) compiling the whole project as c++,
> >> but that's not so great because the dynamic linking doesn't work
> >> because of mangling. Repairing this solution doesn't seem like a
> >> profitable way forward. It's sort of like throwing all your
> >> belongings into a river, then swimming across yourself, and trying to
> >> collect everything on the other side, making sure you didn't lose
> >> anything.
> >>
> >> Another way that I've been trying to consider is to start on the part
> >> of project upon which nothing relies. That way, that part of the
> >> project can be completely C++. Then, take the next thing which
> >> doesn't expose a *used* C api. Rinse and repeat. This way, there will
> >> never (?) have to be a duplicated API in any system.
> >>
> > Sounds nice in theory. I fear it will be equally if not more difficult
> than the current approach
> > though.
> >
> > Taking your example of first replacing the gui.
> >
> > As you bring up yourself it is heavily gobject based. And in addition
> the controller, model and
> > view code are mixed up. Rewriting it in (say) Qt, means it will now use
> Qt objects. But the
> > "business logic" (our engine code) is still gobject based.
> >
> > So now in order for the gui to talk to the business logic you have to
> create an interface layer
> > between the engine and the gui that will do the proper translations
> between the two object
> > models. That is probably more work than maintaining the existing C api
> in the path currently
> > chosen.
> >
> > In addition logically it doesn't make sense to start from the gui and
> drill down to the model.
> > Your gui should be based on the model and controller logic so it only
> makes sense to start there.
> > Going the other way around as a sure way to make wrong assumptions about
> how the lower
> > layers will be implemented and in the best case mean several revisions
> to the higher layers or
> > having to start over in the worst case.
> >
> >> Another way to think about this is as a tree structure. I'll throw
> >> something up, and I'll eagerly await corrections! Read "->" as "relies
> >> on":
> >>
> >> GUI (GTK?) -> Business Logic
> > So rewrite the gui and an interface layer between the two
> >> Alternate gui (WEB?) -> Business Logic
> > Same here.
> >> GUI (GTK?) -> Reporting Infrastructure
> > Same here.
> >> Business Logic -> QOF
> > Rewrite the business logic and write an interface layer between the two.
> > Oops, the way we write the business logic now means we need to change
> the gui layer, because
> > it made some invalid assumptions on what the business logic would be.
> > So rewrite the gui here as well
> >> Reporting Infrastructure -> QOF
> > Rewrite the reporting infrastructure and write an interface layer
> between the two.
> > Oops, the way we write the reporting infrastructure now means we need to
> change the gui
> > layer, because it made some invalid assumptions on what the business
> logic would be.
> > So rewrite the gui here as well
> >
> >> QOF -> libdrm, etc.
> > Rewrite qof and realize we end up with a different implementation that
> we thought we would.
> > So rewrite the business logic and the reporting infrastructure once
> more. And bollocks, that kills
> > our gui design again. Rewrite the gui...
> >
> >>
> >> So, if QOF is changed, it still needs to support Business Logic with a
> >> C api until Business Logic is changed which can't happen until all
> >> GUIs that rely on it are changed. If, however, a gui layer is
> >> changed, that's all there is to it; there are no dependencies (if
> >> there are, we should have started at the dependency!). Once all GUIs
> >> (I know there's only one, but I'm trying to create a sufficiently
> >> complicated example!) are c++-ready, the Business Logic can be
> >> converted. No redundant API is necessary.
> >>
> > See my worst case but not unlikely scenario above. I predict much more
> work when working top
> > down because it's impossible to rely on a lower level interface if the
> implementation hasn't
> > been done yet.
>
> What Geert mentioned in passing but left out of his discussion is that
> there’s a lot of business logic code mixed into the GUI code. That has to
> be teased out and separated so that the model stuff goes down into the
> engine where it belongs and the stuff that’s just computation for display
> or input goes into some middle classes in separate directories, and the GUI
> directories contain just the code which describes the GUI itself, calling
> the controller classes as they need.
>
> The pushing the model stuff down into the engine part of that job makes
> the most sense to do when the engine is migrated, but the extracting part
> could be done now. In fact having the pieces clearly separated ahead of
> time would make it easier to define the engine API when the time comes.
>
> And oh-by-the-way, there’s also some GUI that’s still in scheme and has
> business logic in it that the C parts of GnuCash can’t see at all. That
> also needs to get pulled apart into the appropriate MVC layers.
>
> All of that aside, there’s a fundamental flaw in your reasoning. If you
> write a new C++ GUI, even if there wasn’t an MVC separation issue, all of
> the controller calls would be to C functions, because that’s what the
> controller layer if it existed would be written in. It would in turn be
> calling C functions in the model layer, because that’s what the engine is
> written in. So even if nothing changed, you’d still be in the position of
> rewriting each upper layer over to operate on C++ objects instead of
> GObject objects as you drill down. Everything would be done twice as a
> *best* case.
>
> Regards,
> John Ralls
>
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

John Ralls-2

On Sep 10, 2014, at 5:05 AM, Ted Creedon <[hidden email]> wrote:

> mark up the screenshots with proposed changes
>
> then write the user's manual, systems administrator's manual & systems
> administrator's reference manual - submit for comments & approvals
>
> then write C++ header files that wrap your subroutines &compile & link
>
> only then can you begin code conversion
>
> writing code is the last step, not the first step - and its very boring-
> but you do get zero defect code

I know of no project, waterfall or otherwise, that ever produced zero-defect code.

The changes we're discussing in this context are not reflected in the GUI and so there would be no markup on screen shots and no changes to the documentation.

Regards,
John Ralls




_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

Ted Creedon-2
All changes to the Tektronix MRP system made 1981-1985 were zero defect
Some were quite extensive.

The entire corporation's manufacturing system handling 1,000,000 parts was
netted daily. Any defect would have caused the parts delivery/ordering
system to crash on the IBM mainframe. Several thousand users..

Tek went bankrupt because the replacement MRP system and a major software
offering were not zero defect..

Also look at the space shuttle manipulator code, written in  Forth.

tedc

On Wed, Sep 10, 2014 at 6:51 AM, John Ralls <[hidden email]> wrote:

>
> On Sep 10, 2014, at 5:05 AM, Ted Creedon <[hidden email]> wrote:
>
> > mark up the screenshots with proposed changes
> >
> > then write the user's manual, systems administrator's manual & systems
> > administrator's reference manual - submit for comments & approvals
> >
> > then write C++ header files that wrap your subroutines &compile & link
> >
> > only then can you begin code conversion
> >
> > writing code is the last step, not the first step - and its very boring-
> > but you do get zero defect code
>
> I know of no project, waterfall or otherwise, that ever produced
> zero-defect code.
>
> The changes we're discussing in this context are not reflected in the GUI
> and so there would be no markup on screen shots and no changes to the
> documentation.
>
> Regards,
> John Ralls
>
>
>
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

Aaron Laws
In reply to this post by John Ralls-2
Thank you all for your responses. I agree that it's prohibitively difficult
(between all the re-writing and dealing with the current state of business
logic) to act on my suggestion. This conversation also helps solidify my
grasp of the current strategy.


In Christ,
Aaron Laws

On Tue, Sep 9, 2014 at 5:50 PM, John Ralls <[hidden email]> wrote:

>
> On Sep 9, 2014, at 2:24 PM, Geert Janssens <[hidden email]>
> wrote:
>
> > On Tuesday 09 September 2014 15:12:33 Aaron Laws wrote:
> >> The short question is: What GUI framework is gnucash likely to target
> >> in c++?
> >>
> > Equally short answer: likely Qt or WxWidgets. But we never did a
> detailed evaluation yet.
> >
> >> I've heard it mentioned that the current framework (GTK?) doesn't make
> >> sense in c++ because it's so gobject-oriented, but I didn't hear
> >> anything else suggested. I know there's a QT effort which seems like
> >> a reasonable way to go, but haven't heard it actually endorsed
> >> anywhere.
> >>
> > Exactly
> >
> >> Currently, c++ work is starting at the deepest point (the part of the
> >> code that is relied on by everything), qof, so that a C api has to be
> >> maintained until everything that relies on QOF has a way of accessing
> >> the c++ interfaces. This means that c++ and C interfaces need to be
> >> created and maintained in parallel until everything's ready to
> >> switch. This has grated on me for quite a while, but I see it as a
> >> very difficult problem. I don't see a quick way to fix it. I've tried
> >> (and technically succeeded ^_^) compiling the whole project as c++,
> >> but that's not so great because the dynamic linking doesn't work
> >> because of mangling. Repairing this solution doesn't seem like a
> >> profitable way forward. It's sort of like throwing all your
> >> belongings into a river, then swimming across yourself, and trying to
> >> collect everything on the other side, making sure you didn't lose
> >> anything.
> >>
> >> Another way that I've been trying to consider is to start on the part
> >> of project upon which nothing relies. That way, that part of the
> >> project can be completely C++. Then, take the next thing which
> >> doesn't expose a *used* C api. Rinse and repeat. This way, there will
> >> never (?) have to be a duplicated API in any system.
> >>
> > Sounds nice in theory. I fear it will be equally if not more difficult
> than the current approach
> > though.
> >
> > Taking your example of first replacing the gui.
> >
> > As you bring up yourself it is heavily gobject based. And in addition
> the controller, model and
> > view code are mixed up. Rewriting it in (say) Qt, means it will now use
> Qt objects. But the
> > "business logic" (our engine code) is still gobject based.
> >
> > So now in order for the gui to talk to the business logic you have to
> create an interface layer
> > between the engine and the gui that will do the proper translations
> between the two object
> > models. That is probably more work than maintaining the existing C api
> in the path currently
> > chosen.
> >
> > In addition logically it doesn't make sense to start from the gui and
> drill down to the model.
> > Your gui should be based on the model and controller logic so it only
> makes sense to start there.
> > Going the other way around as a sure way to make wrong assumptions about
> how the lower
> > layers will be implemented and in the best case mean several revisions
> to the higher layers or
> > having to start over in the worst case.
> >
> >> Another way to think about this is as a tree structure. I'll throw
> >> something up, and I'll eagerly await corrections! Read "->" as "relies
> >> on":
> >>
> >> GUI (GTK?) -> Business Logic
> > So rewrite the gui and an interface layer between the two
> >> Alternate gui (WEB?) -> Business Logic
> > Same here.
> >> GUI (GTK?) -> Reporting Infrastructure
> > Same here.
> >> Business Logic -> QOF
> > Rewrite the business logic and write an interface layer between the two.
> > Oops, the way we write the business logic now means we need to change
> the gui layer, because
> > it made some invalid assumptions on what the business logic would be.
> > So rewrite the gui here as well
> >> Reporting Infrastructure -> QOF
> > Rewrite the reporting infrastructure and write an interface layer
> between the two.
> > Oops, the way we write the reporting infrastructure now means we need to
> change the gui
> > layer, because it made some invalid assumptions on what the business
> logic would be.
> > So rewrite the gui here as well
> >
> >> QOF -> libdrm, etc.
> > Rewrite qof and realize we end up with a different implementation that
> we thought we would.
> > So rewrite the business logic and the reporting infrastructure once
> more. And bollocks, that kills
> > our gui design again. Rewrite the gui...
> >
> >>
> >> So, if QOF is changed, it still needs to support Business Logic with a
> >> C api until Business Logic is changed which can't happen until all
> >> GUIs that rely on it are changed. If, however, a gui layer is
> >> changed, that's all there is to it; there are no dependencies (if
> >> there are, we should have started at the dependency!). Once all GUIs
> >> (I know there's only one, but I'm trying to create a sufficiently
> >> complicated example!) are c++-ready, the Business Logic can be
> >> converted. No redundant API is necessary.
> >>
> > See my worst case but not unlikely scenario above. I predict much more
> work when working top
> > down because it's impossible to rely on a lower level interface if the
> implementation hasn't
> > been done yet.
>
> What Geert mentioned in passing but left out of his discussion is that
> there’s a lot of business logic code mixed into the GUI code. That has to
> be teased out and separated so that the model stuff goes down into the
> engine where it belongs and the stuff that’s just computation for display
> or input goes into some middle classes in separate directories, and the GUI
> directories contain just the code which describes the GUI itself, calling
> the controller classes as they need.
>
> The pushing the model stuff down into the engine part of that job makes
> the most sense to do when the engine is migrated, but the extracting part
> could be done now. In fact having the pieces clearly separated ahead of
> time would make it easier to define the engine API when the time comes.
>
> And oh-by-the-way, there’s also some GUI that’s still in scheme and has
> business logic in it that the C parts of GnuCash can’t see at all. That
> also needs to get pulled apart into the appropriate MVC layers.
>
> All of that aside, there’s a fundamental flaw in your reasoning. If you
> write a new C++ GUI, even if there wasn’t an MVC separation issue, all of
> the controller calls would be to C functions, because that’s what the
> controller layer if it existed would be written in. It would in turn be
> calling C functions in the model layer, because that’s what the engine is
> written in. So even if nothing changed, you’d still be in the position of
> rewriting each upper layer over to operate on C++ objects instead of
> GObject objects as you drill down. Everything would be done twice as a
> *best* case.
>
> Regards,
> John Ralls
>
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++ work

Geert Janssens
On Wednesday 10 September 2014 11:25:33 Aaron Laws wrote:
> Thank you all for your responses. I agree that it's prohibitively
> difficult (between all the re-writing and dealing with the current
> state of business logic) to act on my suggestion. This conversation
> also helps solidify my grasp of the current strategy.
>
>
> In Christ,
> Aaron Laws

You're welcome. Also the fact you asked this question allowed us all to
express our vision on the rewrite strategy and to understand each
other better. A win for all involved :)

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel