On Mar 1, 2010, at 5:09 AM, bulia byak wrote:
On Mon, Mar 1, 2010 at 12:21 AM, Jon Cruz <jon@...18...> wrote:
(general note: SP_OBJECT_ID() should have been dropped with the change to C++)
No it shouldn't - you can change the underlying definition if you want but I see no reason to remove the convenient macro.
Instead, we need more macros like this. For example if we had preference calls in macros, that would have saved a good deal of the pain of moving to the new prefs class.
No, we really need to get rid of all macros.
Instead we need to use C++ features. That is much of the point of the language.
Yes, we should encapsulate things. But no, we should not use macros to do so.
You do hit on a good point about the preferences. If we have things properly *encapsualted* then the move would be easier. Of course, I think some of the move there was done improperly which caused some of the pain. However, that is a separate discussion.
To take a look at this specific macro, it fetches the ID string of a given SP Object or SP Object subclass. The cleaner way to approach that is to add an accessor to SPObject itself:
public gchar const* getID() const;
Among other things, C++ inheritance and such will help us out. It will also make it easier for an IDE to assist the programmer. A macro will block an IDE from doing as much.
Using code goes from
SPItem* item; ... str += SP_OBJECT_ID(item);
to become
SPItem item; ... str += item->getID();
Just as that macro, the getID() method is declared in the sp-object.h file. And since it is an accessor method, it hides the actual member being used (it encapsulates it). Now we are free to change the underlying implementation without touching any of the using code. We can also change the implementation in just one specific subclass without affecting any others. It's extremely difficult to do that with a macro. Additionally, the compiler and IDE will be able to perform more checks, promote type safety, and make the code generally more legible. Legible code is maintainable code.