Re: Full view of a private partial view cannot be a subtype

[Shark8 <onewingedshark@gmail.com>]

On Monday, December 4, 2017 at 2:48:34 PM UTC-7, Jeffrey R. Carter wrote:
> On 12/04/2017 09:41 PM, Jere wrote:
> >>
> > I don't disagree in general per say, but that is a very subjective thing.  I
> > don't find composition nearly as readable as you do.  It has it's place and
> > can be more readable, but (maybe it's just how I read and visualize) I find
> > extension to be more readable in probably more cases than you typically do.
> > It's just a personal thing with how I read.  I've used and written both.
> 
> I've never seen a realistic problem that was as readable when implemented with 
> type extension as with composition.
> 
> Perhaps the best fit of any problem with type extension is a GUI framework, 
> since everything "is-a" widget. I have used 2 such frameworks implemented using 
> type extension, Claw and Gnoga, and both are very difficult to understand. The 
> derivation trees are very deep and there are a huge number of inherited 
> operations. It's effectively impossible to know all the operations for the most 
> commonly used types, which tend to be down at the leaves of the derivation tree. 

One of the best GUI frameworks I've seen is Delphi's VCL -- it is very good in this respect having several "base level" types where you'll look for common operations. (There's one for visual-components, one for nonvisual-components, and they both share an ancestor that is [IIRC] higher than TObject.)

Besides UIs, the one problem that springs immediately to mind is the internals of a compiler's IR/parse-tree. Another is linguistics (though I haven't actually seen this used) where you are modelling language on a abstract/general level: Types Verb & Noun, descending from Word. Phrases, sentences, etc.