Hi Takashi, On Tuesday, 2007-08-21 13:34:18 +0900, Takashi Nakamoto wrote:
> > > Switching routine that choose one class from the four
> > > classes for creating an instance of a cell would be complex.
> >
> > I don't think so. You need to distinguish anyway, and subclassing may
> > actually ease things because switching can be done internally using
> > factory patterns and RTTI.
>
> I've considered this point. However, I couldn't find any factory patterns
> in ongoing source codes related to cells. Instead, I found many
> statements like "new ScStringCell ()".
> This means we need to revise
> many lines related to the instantiation of Sc*Cell if we add
> ScRubyStringCell. Such revise results in complex code.
No, it results in complex code analysis. You will have to find the
places anyway where you want to add ruby to string cells. Once changed
to a factory pattern the resulting code will be not more complex than
changing calls of
ScStringCell* pCell = new ScStringCell(someText);
to calls of
ScStringCell* pCell = ScStringCell::createInstance(someText,maybeRuby);
that returns a new'd ScRubyStringCell if maybeRuby is not empty, and
ScStringCell otherwise. A ScRubyStringCell should still have the
eCellType member variable set to CELLTYPE_STRING so you wouldn't need to
adapt the zillion places where that is used, but should be
distinguishable by means of RTTI where needed.
> If Sc*Cell class group was designed to be added a new cell type to
> from the start, subclassing would be the most attractive and cleanest
> solution for this problem.
All cell types are derived from ScBaseCell so that shouldn't be a big
problem. We have CellType that so far was sufficient and efficient.
A real RTTI interface isn't available yet because most compilers didn't
know about RTTI back those days, which actually is the reason why the
ugly tools/rtti.hxx macros came to existence. We should strive for the
cleanest possible solution anyway, and if something is missing add the
missing pieces instead of fearing complex changes.
Eike
--
OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't send personal mail to this [EMAIL PROTECTED] account, which I use
for
mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED]
Thanks.
pgpuPImxk6qFb.pgp
Description: PGP signature
