Re: Type-free Circles and Ellipses [T]

On Thu, 30 Aug 2001 18:15:18 GMT, topmind_at_technologist.com (Topmind) wrote:

>> >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.
>
>I am not sure what you mean. I am *not* talking about C++ "templates",
>but prototype shape data. Once the template is copied, the user
>can change it.

I.e. the single difference between compiler-supported code patching (=templates) and your approach is that the burden of copy-and-paste lies on the programmer. Never mind, I do not want "templates" in any form.

>Thus, they can warp a circle into a blob if needed. It
>does not have to "change class" to warp. (That is another
>flaw of "types": hard to change from one type to another.)

Why should we change from one type to another? It is like to change the type of a dog to "cow" and then to milk it. Fortunately God spoke in a strong typed language. (:-))

>> >> 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.
>
>Why you say such? For one, changing the smoothing algorithm
>can be done without changing instance type (see above).

Surely. But the problem is to have an arbitrary number of smoothing algorithms selected by the context (=the type of the argument). There is no static solution for that.

>> >> >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].
>
>Well, if compiler checking is important to the way you
>think and work, then I cannot argue against that, other
>than say that what works best for you may not work
>for others. Strong-typing clutters up code with
>too many declarations and casts IMO. IOW, the
>airbag blocks my view of the road.

Well if there is no types, then there is no problem whether they should be checked statically or not. (:-)) BTW declarations are not about static vs. dynamic, but rather about manifested vs. not. Casts are solely about C/C++. (:-))

>> >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.
>
>Usually it turns into a de-facto tree as it grows.

Which means only that a tree is adequate in that cases.

>> >> 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?
>
>I am not sure what you mean here.

Sparse matrices, lists, trees etc. Could you argee that arrays indexed by numbers, tuples and strings should be implemented by different ways? Actually it is the goal of ADT to hide the implementation behind the interface. Then just to distinguish such cases, one needs types.

>The engine which impliments
>it is *also* an attribute in my approach. Example:
>
>handle = collection(engine=HP)
>
>....
>
>handle = collection(engine=Sun)
>
>(Please don't claim that handles are "OO". They pre-date
>Simula-67 I beleive.)

Handle is an instance of some access type. It seems that your language has one untyped access type. I.e. a handle may point to everything. It is not very exciting. Similarly your collection may contain everything: apples, oranges, credit cards and bicycles. However it is not an array. How do I index your collection? You have no types, then any index should be valid [for the compiler] causing a nice debugger's dialog box at run-time, right?

>The interface does not change (except possible
>references to features that aren't implimented.)
>
>The OO approach often couples the implementation
>engine to the interface, if you think about it:
>
>c = new SunSystemsCollection(....)
>
>c = new HPCollection(....)
>
>I thot OO was supposed to *hide* implementation
>information from the interface user.

Dispatch on the result solves this. C++ is not all OO. Take a look at Ada 95. An alternative is a collection factory:

Collection * Create (const CollectionName);

Regards,
Dmitry Kazakov Received on Fri Aug 31 2001 - 17:50:56 CEST