Deconstruction of the code(the refactoring issue)

[Harbinger]

While i think the localized strings can be included with the next (or the next release of MPT, i plan on making some drastic changes, not only in regards to the GUI customization discussed in an earlier thread, but also in the refactoring of the code modules (standardizing the variable names, separating classes into smaller, more manageable files, etc.), as well as a streamlining of the composition process for the user (making it easier to jump in and compose with little knowledge of the interface and with as few steps between inspiration and composition as possible). Would it be better to put these kinds of changes in a SEPARATE build, or would it be better to definitely include drastic changes in the current build, but user changes made optionable (which will make it more work than it'll already be)?

A lot of this has to do with the overall directive we all share with ModPlug: which changes are too much change? How far do we want to go from the original concept? For example, i can -- given time and a little more expertise -- cut the tabs from 5 to 3 (Samples/Instruments, Patterns, Mixer/General), make the channels & columns hideable, and even add tabs to the mixer page. Perhaps this grand idea of simplification might be too much change. (On the flip side, i don't want to make the page so complicated like Renoise.) But i've made a lot of my own requests over the past few years in which now i can see the work involved in implementing them, but i'm almost at the point where i might be able to grant my own wishes.

The first step for anything is to "deconstruct" the code modules -- separate the classes from each other (where reasonable) so that changes can be made easily, although we'll be adding a lot more #includes. I want to break them down to basic parts. Some of the parts may need to be given some surgery to separate the "organs" as it were! I will also hafta figure out how to test that my changes have not broken something we've all grown to love. (Apparently the VSExpress d/l has a debugger application that may help me there.) While a lot of this refactoring will require lots of time, i consider it menial work, in the sense there are greater magicks the wizards can work on, while the apprentices (like me)  can spend time learning the scrolls while transcribing the original phrases -- to continue the metaphor. :wink:
One of the reasons why we should compartmentalize the classes even more is to make it easier not only for future development, but also for future porting. For this reason, i am also writing up a spreadsheet reference on all the variables and methods, and descriptions of each, what they do, and which other functions they call or call them. VS has the "which-goes-to-which" feature as well, but if i were to add all the descriptions to the code files themselves, i'd end up with more comments than actual function! :wink: Only problem is, if i'm going to do this reference, i hafta find and list all the variables, enums, and functions, then figure out what they do -- and it's not always obvious. Hell, it took me a while to realize that most of the function parameters in the .h files were DUMMY variables.

But if all goes well, the code will be a LOT easier to amend and emend, transfer to other programming "dialects", and generally just explore and work with. I remember one of us remarking many, many months ago that the code was too "tight" to make any big changes. Now i understand how. My goal is to loosen up the code and make it a lot more malleable. I understand it won't be easy, nor quick, but we've all agreed on the ship, now we need to make sure we're using the same map...

I'm interested in the thoughts of programmers and users alike on this subject...

[Saga Musix]

You know, the MPT code is really not that bad that there are 100 different classes in one file! From my point of view, the classes are separated reasonably and the code structure is clear enough to keep working on it. There are no drastic changes necessary, although small simplifications are always possible (I do that all the time). However, you are talking about several completely different things here, and that is simply too much at one point. The GUI changes alone are already one big task, and so is localization. You're talking like you want to fix stuff in one month which I have not been able to fix in more than one year.

[Rakib]

Why not split the different classes in different files, not everybody wants go trough 2-3000 lines of code to find the thing they want to change.

[Saga Musix]

Apparently, what I said was not clear enough? Every class (apart from some simple dialog classes, where splitting them into separate files would be even more confusing) has at least one own file, sometimes even several files.

[Harbinger]

The GUI changes alone are already one big task, and so is localization. You're talking like you want to fix stuff in one month which I have not been able to fix in more than one year.

Yes, i understand the breadth of what i wish to accomplish, now that i understand the programming language. I really like this object-orientated approach, but i find this is what tends to keep things tightened up; every reference to one class or object may affect every other reference to it. You can't pick something out and work on it without monitoring the effect on every other derivative or member. (While BASIC was very decompartmentalized, at least i could change one subroutine or variable without worrying about anything connected to it.)

I DO anticipate my plans taking me well over a year, unless i find a way to devote a lot more time to it. I want to do what i think is the easier task first of string localization, picking up skills along the way. Then i'll tackle GUI issues. I hope to tap into the expertise of those that have come before me, so i don't waste time on tactics already tried... :wink:

[Saga Musix]

every reference to one class or object may affect every other reference to it.

That would even happen in BASIC if you try to write some kind of framework, though. And it DOES happen in MPT every now and then, due to the lack of a good testing framework.