Initial discussion

[Bart Cerneels]

>On Sunday 18 February 2007, Alexandre Oliveira wrote:
>> 1) Proper objects to hold data, instead of strings.
>> I mean Track, Artist, and Album objects, for example. No Strings with
>> names or ints with ids traveling around. Having these objects will
>> help keeping the code much cleaner, and will avoid repetion. For
>> example, all the ", The" magic could be handled in proper methods
>> hidden in the Artist class.
>> These objects should have as much methods and as little properties as
>> possible. They all inheriting a base object would be useful for some
>> stuff as well.

>I agree. We should replace MetaBundle completely. I'm not quite sure what you
>mean by "inheriting a base object". Do you already know a case where a common
>base class would be useful?
>Another think we should think about is creating the objects on the heap
>instead of on the stack. That way we lose the automatic memory management,
>but gain a lot of flexibility.

We could consider a garbage collector for just the Meta objects. This
reduces the risk of memory leaks and helps keeping Amarok's memory
footprint down by deleting less used objects.

>> 2) Database handling.
>>  Are we going to use the Qt database stuff, some library out there, or
>> just code the support ourselves?
>> If we're going to code it, we need something that is done by plugins
>> (to avoid the problems we had with mysql/postgresql running
>> dependency), and we need something that returns objects to us (as I
>> mentioned in #1), instead of the lists of strings we had in 1.4.
Consider this, using a framework reduces the boring workload allowing
us to focus on new features :). And will probably be less buggy.

>> 3) Reduce developers compiling time.
>> I don't mean we should do any magic regarding this, I only mean we
>> should split the amarok lib we have now, so stuff can depend only on
>> what they really need, so we don't relink everything whenever
>> something that doesn't matter changes.
Get faster machine :). Another option might be to use the OpenSuse
build service.

>We have a few classes which are used that much that a change to the header
>file basically requires recompiling all of amarok. How about adding
>d-pointers to classes like EngineController, CollectionDB or Playlist ( or
>their replacements) so that we can add members without having to change the
>header files?
Just make sure you don't a bloat just for the sake of convenience.

>> 4) Reorganise source files?
>> Right now we have almost all source files in the src folder, shouldn't
>> we take this chance to organise it in a better way?
>>
>> 5) Smaller methods.
>> Let's avoid 5000 line methods this time, shall we? :-)

>I don't think we have 5000 line methods,  but 500 line methods and 5000 line
>classes for sure. And neither is a good idea:)

Nice looking code lead to less bugs.

Stecchino