[cad-linux-dev] Re: square

  • From: Massimiliano Mirra <mmirra@xxxxxxxxx>
  • To: cad-linux-dev@xxxxxxxxxxxxx
  • Date: Sat, 20 Dec 2003 18:43:55 +0100

Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx> writes:

>>> Same case again.  There is no such thing as a square as far as storage is
>>> concerned.
>>Is storage alone concerned?
> Data structure is my main concern because given a good data structure, 
> programming is easy.

I'm not sure about what you mean by data structure.

>>What happens when one creates a square, rotates it, and later wants to
>>change its size by just modifying the length of its side?  How are those
>>four points going to handle it if they don't know the rule by which
>>they're laid out?  Will the square have to be created from scratch and
>>rotated again?
> Now you want the square to be modifiable as a *regular polygon*.  But this is 
> just a scaling operation with a basepoint.

Absolutely not.  One thing is the user wanting that rotate square get
a side three inches long whereas it was two inches long a minute ago.
A totally different thing is having the user calculate where the base
point should be and what the scale factor should be so that that
rotated square will have a side three inches long after the operation.

> The difference between having this check ask the 
> entity if it is a square and having it simply compare the length of all of 
> the sides seems obvious to me:
> for( i = -1; i < n; i++) {
>   i2 = i+1;
>   len[i] = dist(points[i], points[i2]);
>   }
> these_are_equal(len) or croak("not a regular polygon");
> compared to:
> switch(type) {
>   case TRIANGLE
>     ok();
>     break;
>   case SQUARE
>     ok();
>     break;
>   case PENTAGON
>     ok();
>     break;
>   case HEXAGON
> ad infinitum

Since you seem to generalize in a good direction:

    if (type == REGULAR_POLYGON) {

And yes, the difference between doing shape detection with `n'
calculations with a possibly large `n' and a possibly complicate
shape, and checking a tag, seems obvious to me too, especially
performance-wise.  What good there is in going through a pile of
photos to associate a name with a person, when you have the person
right there and could ask his name?

> So, what if we just have a Polygon::Regular class and bless any N-sided 
> polygon into it?  This is a better solution, but not as simple as having a 
> Polygon class and just using that.  

You are mistaking my concept for my sample implementation.  The sample
implementation is that of a square vs. a bunch of points, it might be
a regular polygons vs. a bunch of points as well, that's not the, er,
point.  The concept is that an object with knowledge of its internal
rules lets you do more and better than just a bunch of points.

Other related posts: