From koffice-devel Thu Mar 31 10:47:47 2005 From: Tomas Mecir Date: Thu, 31 Mar 2005 10:47:47 +0000 To: koffice-devel Subject: Re: [kspread] alternative to DocInfo/DocBase Message-Id: <492258b10503310247bb58730 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=koffice-devel&m=111226610401768 On Thu, 31 Mar 2005 12:18:43 +0100, Ariya Hidayat 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