[fpc-devel] class abstract, class sealed implementation. please review.

[Peter Popov]

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_gorelkin at mail.ru> wrote:

> Graeme Geldenhuys пишет:
>> 2009/10/16 Paul Ishenin <webpirat at 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 at 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                       |
|                                               |
|***********************************************|