On Sat, Oct 17, 2009 at 08:51, Sergei Gorelkin <sergei_gorel...@mail.ru> wrote: > Guess its primary target are classes like Java/.NET String. These are value > classes, they do not contain other pointers, garbage collection is therefore > easier and the whole framework speeds up. If you inherit from it and add > your own member, this mechanism could be disrupted system-wide.
Yes, this is one ot the reasons. Another is that classes implementing class attributes are apparently very inefficient in CLR unless they are sealed. This, btw, might say that we should imlpement sealed for FPR value classes (aka type T = object ...) > But as soon as a feature appears, it starts to be used (and abused, too) > here and there. Agree, this is to me the strongest argument against sealed classes -- the feature _can_ be used correctly, but will be usually used wrongly by clueless programmers. -- Alexander S. Klenin _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
