> > > 4) Or maybe subclass ScStringCell to create ScRubyStringCell, and use an > > > instance of that class to store the ruby text information when needed ? > > > Just a wild idea, but could this work (maybe) ? > > > > I think this is not a good idea. It would make String type cell have > > 4 different classes, ScStringCell, ScRubyStringCell, ScEditCell, > > ScRubyEditCell. > > If ruby was implemented at EditEngine we would end up with just 3: > ScStringCell, ScRubyStringCell, ScEditCell. > > > 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. 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. -- Japanese Native-Language project Good-Day Inc. Takashi Nakamoto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
