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

List:       koffice-devel
Subject:    Re: [kspread] alternative to DocInfo/DocBase
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2005-03-31 7:56:21
Message-ID: 492258b105033023563610f9f1 () mail ! gmail ! com
[Download RAW message or body]

On Thu, 31 Mar 2005 01:32:14 +0100, Ariya Hidayat <ariya@kde.org> wrote:
> This is a proposed alternative to DocInfo/DocBase. I don't know if this works or \
> not (perhaps I missed something, perhaps this does not even make sense at all), so \
> please comment on it.

Alternative to Doc* ... Hmm, and I found it to be such a neat idea :(

> Since the goal is to allow e.g. different ValueConverter and ValueParser for \
> different document's locale settings, why not instantiate these classes within \
> KSpreadDoc and provide the accessor, e.g. ValueParser* KSpreadDoc::parser()? Other \
> classes which want to make use of it directly or indirectly will have access to the \
> owning document anyway.

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.
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 ...

> If this works, I'd rather to choose this approach. Class inheritance to share \
> unrelated functionalities is a sort of practice I dislike since long time ago. I'm \
> sure Herb "GoTW" Sutter will concur with me :-P

Never heard of that Herb. And, to the contrary, I find inheritance
quite useful :-P
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 ...
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.

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...

/ Tomas
_______________________________________________
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]