[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [kspread] alternative to DocInfo/DocBase
From:       "Ariya Hidayat" <ariya () kde ! org>
Date:       2005-03-31 10:19:24
Message-ID: 1908776089 () web ! de
[Download RAW message or body]

> Well ... I agree that the same effect could be achieved with this
> solution. Problem is, that I find this solution to be more complex
> than it should be. Hence the code will look less readable and
> whatnot... Also, we'll have to pass a document pointer to each such
> class (no problem here, as we do the same with DocInfo), and, in each
> class, have some means of storing the pointer -> unneeded duplication.

I don't agree that it is not readable. In fact, it is more understandable 
because the line of responsibility is pretty clear here. Look, it is normal 
for a cell to hold a pointer to its owner (KSpreadSheet), and from there 
indirectly you can trace back to KSpreadDoc and get all the locale information 
and such.

> Also, we'll have to modify almost everything that currently uses
> things like map(), locale(), ... to use doc->map(), doc->locale(), ...
> Quite a bit of work, just to end up with something that, if isn't
> worse (and I somehow think that it is), at least isn't any better...
> Doesn't really look like the very best things to do ...

Granted, the good code is sometimes not the shortest one.

> Never heard of that Herb. And, to the contrary, I find inheritance
> quite useful :-P

Inheritance is of course useful, but in the context of DocBase IMHO it is 
not used in a proper way.

> Besides, what "unrelated functionalities" are we talking about here ?
> The classes are all a part of the same document, so pointers to other
> classes within the same document look pretty relevant to me ...

KSpreadCell, Formula and KSpreadDoc are all totally different in term of 
functionalities and resposibilities.

> In the case that you are talking about a mapping from class diagrams,
> I agree that constructs like this would not appear there, but somehow,
> diagrams and implementations tend to end up looking a bit different at
> times - and in this situation, I believe that it does make sense... Or
> at least, I fail to see, what's wrong with my approach.

I don't say it is wrong, but rather it is prone to error. For new comers or 
whoever want to read/study the code, isn't strange to see that KSpreadCell, 
Formula, KSpreadDoc are all inherited from DocBase? Strictly speaking, DocBase 
does not have any real responsibility except as "anchor" or "wrapper" for 
some frequently used functions in its subclasses. That I wouldn't call 
an example of a use of class inheritance.

I have no doubt similar thing can be implemented with macro. But I do not 
favor macro if other solution exists. Hence, I am still researching which 
design pattern can be used to overcome this "theoritical vs practical" 
problem here.

> In addition, DocBase might serve other purposes as well - sharing most
> common methods, so that we don't have to #include lotsa stuff
> everywhere, when DocBase can shield us from that, thus allowing easier
> modifications of stuff (and to decrease compilation time significantly
> after such modifications :P) As of now, I've only added the
> begin/endOperation stuff there, mostly as a proof-of-concept, but it
> looks like other methods might find their way there aswell...

begin/endOperation should be removed and unnecessary when Doc/View
with damaged concept is in place. I have talked about this in the past.

Best regards,

Ariya Hidayat


__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]