[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 10:47:47
Message-ID: 492258b10503310247bb58730 () mail ! gmail ! com
[Download RAW message or body]

On Thu, 31 Mar 2005 12:18:43 +0100, Ariya Hidayat <ariya@kde.org> wrote:

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

Hrm, is d->m_pSheet->doc()->locale() really more readable than
locale() ? I think not :P

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

Hmm, I'm obviously less of a purist, or
he-who-writes-damn-strange-code, or however you want to call it ;)

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

Yeah, it's more of a *cough* implementation-wise thingie ;)

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

Heh, maybe not :P But then, other means look kinda ugly to me. And
when something looks ugly, it tends to be more difficult to maintain
it...

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

Well it's a bit similar to Mediator - only that we have no mediator object :PPP

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

Yes, I know. But for now, they are still there :P
But, oh well, if you really think that your solution is better, then
go ahead and change it to suit yours - I'll manage, but don't expect
me to get too excited about it ;)

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