Re: Type-free Circles and Ellipses [T]

On Wed, 29 Aug 2001 19:32:50 GMT, topmind_at_technologist.com (Topmind) wrote:

>> The problem is that there are different classes of spline segments one
>> would like to use. Depending on the segment class one may implement
>> some geometric operations very [in-/]efficient. Consider,
>> approximation of a circle using multiple linear segments against one
>> elliptic segment.
>
>Well, that is where the "templates" come in. You offer the user
>templates of "standard" shapes that are built with the segments
>or splines or whatever we end up calling them. This is
>consistent with the "short-cut" philosophy that I described in other
>threads. (Example: "stack" is a set of specific DB settings, rather
>than a dedicated class or engine.)

How do I write a class-wide program that works for all possible shapes consisting of the segments which implementations are not yet defined? Run-time dispatch is a natural mechanism for this. Templates are not.

>> So you naturally come to the situation where the segment type is an
>> abstract type with dispatching methods, and there are various concrete
>> segment types derived from it. In other words segment should be
>> polymorphic.
 

>I would call them "segment strategies" and not "types". It would
>fit a strategy pattern rather than subclassing.

Unlike "type", "pattern" is not a language term. If the type system does the work, why should I search for some kludges? It is ridiculous to simulate types using patterns.

>> >I will just say that it is situational. I don't beleive in
>> >one-paradigm-fits-all-projects.
>>
>> ADT is not a paradigm, it is the paradigm. You cannot have a typeless
>> system.
>
>I say you can. Anything that is "sub-typed" can be turned into
>feature-selection (and visa versa).

Yes, but I want compiler support [I mean statically checked types].

>They are more or less
>interchangable. The advantage of the feature approach
>is that you can get lots of combinations without
>building a complex, often poorly-factored, tree. Adding
>a new feature can require adding jillions of nodes
>in a tree.

If you are arguing against the limitations of the subtype relations usual to the modern OO languages, I am with you. There is nothing fundamental that requires the subtype relation be a tree.

>> The most near approximation of that would be a system where
>> there is exactly one type. You can say, OK for my project I need only
>> one type, but you cannot get rid of types. If you agree with that,
>> then why not to have an ability to create new types out of existing
>> ones? Note that even such simple things like records and arrays
>> require notion of user defined types [if you do not prefer FORTRAN-IV,
>> of course (:-))].
>
>Access to collection systems are via API's, and not dedicated
>systems, similar to smalltalk's approach of not hard-wiring
>arrays into the language syntax. (Associative arrays
>are used for interfacing and not for bulk data storage in
>my pet lang.)

Sounds like a definition of an abstract type that looks like an array. It is pretty ADT. Could you imagine that different implementation of the array type would be required depending on the type used to index it? Can an array be an index of another array? Can an array be an index of itself. Can it be an element of itself?  

Regards,
Dmitry Kazakov Received on Thu Aug 30 2001 - 12:05:31 CEST