Re: Type-free Circles and Ellipses [T]

From: Dmitry Kazakov <dmitry_at_elros.cbb-automation.de>
Date: Wed, 29 Aug 2001 08:24:02 GMT
Message-ID: <3b8c9e67.1291125_at_news.cis.dfn.de>


On Mon, 27 Aug 2001 20:34:31 GMT, topmind_at_technologist.com (Topmind) wrote:

>> BTW. How would you calculate the perimeter of a shape?
>
>Add the perimeters of the segments. How the actual calculation
>is done per segment (or node)? I don't know. I forgot
>all that stuff since my dorm-days.
>
>> How many
>> segments should have the shape built from the modified Bessel
>> function?
>
>I don't understand this question. Note that I did not
>specify how the smoothing was acheived. (The smoothing
>algorithm used could be an attribute. This may get
>a bit sticky in that some smoothing algorithms
>can involve many nodes. Thus, I suggest a
>"bleedPercent" kind of attribute to affect
>how much nearby nodes/segments are allowed to affect
>the current one.)

So your shape is some kind of spline. This is a usual representation for some sort of curves, however there are also other cases and possibilities.

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.

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.

Then, of course, the same old
circle/ellipse-square/rectangle-int/float-etc problem re-appears. If we want to reuse some code written for a segment type A in the segment type B, then B should be a subtype of A with all so exciting possibilities to discuss whether B is A, what is subtype, what is property and what Bill has to do with Monica. (:-))

Ergo, you did not get rid of the C-E problem, you just moved it into another place.

>> I know that you are aginst OO. It seems that you are against ADT too.
>> Right?
>
>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. 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 (:-))].

Regards,
Dmitry Kazakov Received on Wed Aug 29 2001 - 10:24:02 CEST

Original text of this message