The discussion on sealing is interesting. Following up on the remarks of
sergei I can see one benefit of sealing classes:
Suppose you have a C++ OOP framework, such as Qt, which one wishes to use
in Delphi. There are a number of ways to do this. So, suppose one goes for
the path in which the C++ is compiled in a dll with C bindings and on the
delphi side, a mirror hierarchy is created. This was the case with the
qt3clx port some time ago. It actually looks quite elegant, and obviously,
one cannot extend the functionality of the original Qt methods. So, even
if one assumes that the VMT layout is the same, there are slight, but
significant differences in the polymorphism semantics in Delphi/Java and
C++. Therefore, aggregation is the only option.
So, maybe one should "seal" entire units instead of classes, meaning they
provide import definitions of some other OOP framework to be used but not
abused. Maybe use "imported" instead of "sealed".
As for abuse of concepts - the richer a language becomes, the more paths
to abuse it. no way around that.
Peter Popov
On Fri, 16 Oct 2009 16:51:41 -0500, Sergei Gorelkin
<sergei_gorel...@mail.ru> wrote:
Graeme Geldenhuys пишет:
2009/10/16 Paul Ishenin <webpi...@mail.ru>:
Sealed class is a class which can't be derived by another class. This
one is
fully supported by delphi.
Would you mind explaining this - I never saw the benefit of a sealed
class. Using myself as an example. Say I develop some kick-ass OOP
framework. There is no way in hell I can forsee every possible use of
the classes I created. So why would I want to limit the usefulness of
a class - it goes totally against the OOP principles.
Sealing does not prevent reusing in form of aggregation (when the sealed
class is a member of your own class). Wishing/forcing users to use
aggregation instead of inheritance may be a valid point sometimes.
Imagine the TList class was a sealed classes. We would never have been
able to create a TObjectList, TInterfaceList, TStringList, etc... and
reusing the basic implementation from TList to save time and code
reuse.
These cases use precisely aggregation, so, in fact, the code of
TObjectList, etc. wouldn't change if TList was sealed.
Not to shoot down your efforts or anything, I just don't understand
the point of a sealed class. It sounds more like something Microsoft
would implement to stop developers from reusing their classes like
"Outlook Bar" and extend it to something much better than the standard
one included in MS Office.
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.
But as soon as a feature appears, it starts to be used (and abused, too)
here and there. Next come 'class helpers', the purpose of which is to
circumvent sealed classes, and so on...
Regards,
Sergei
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
|***********************************************|
| |
| Peter Popov, |
| |
| 608L Blocker Bldg. |
| Institute for Scientific Computation, |
| Texas A&M University |
| College Station, Texas 77843-3404 |
|-----------------------------------------------|
| Phone: +1 (979) 458-4644, |
| Fax: +1 (979) 845-5827 |
| |
|***********************************************|
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
