Re: Type-free Circles and Ellipses [T]

> 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.

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.)

>
> 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.

>
> 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.

I say you can. Anything that is "sub-typed" can be turned into feature-selection (and visa versa). 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.

> 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 (:-))].

That can be done without. My experimental pet language has only one variable type: associative-array.

x = 5

is identical to:

x.value = 5

(actually it more like "x.~sys_value" to distinquish from actual keys named "value".)

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.)

>
> Regards,
> Dmitry Kazakov
>

-T- Received on Wed Aug 29 2001 - 21:32:50 CEST