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.

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

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

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

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

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

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.

> Can an array be an index of another array? Can an array be an
> index of itself. Can it be an element of itself?

As a reference, in a relational sense.

>
> Regards,
> Dmitry Kazakov
>
>

-T- Received on Thu Aug 30 2001 - 20:15:18 CEST