Smalltalk › Squeak › Squeak - Dev

Proposal: Geometry Classes

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

patrick.rein

Proposal: Geometry Classes

Hi everyone,

during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion.

In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on.

Bests
Patrick

# Squeak Change Proposal - Geometry Package

## Why?
Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more).

## Scope
The proposed package should cover basic 2D geometric objects and their operations represented by the following classes:
- Point
- Line
- LineSegment
- Polygon
- Rectangle (as an optimization as it could be represented as a special Polygon already)

Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package.

### Affected classes:
- All classes in ST80-Paths
- LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
- Rectangle, Quadrangle, Point (Graphics-Primitives)
- LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection)

## Open questions
- Should this become a single new package or a subcategory in the Graphics package?
- Should the package contain an Ellipses class?
- Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc?

## Risks
- This would potentially deprecate the existing ST80 geometry classes (ST80-Paths)
- Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

Karl Ramberg

Re: Proposal: Geometry Classes

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,

Karl

On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:

Hi everyone,

during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion.

In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on.

Bests
Patrick

# Squeak Change Proposal - Geometry Package

## Why?
Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more).

## Scope
The proposed package should cover basic 2D geometric objects and their operations represented by the following classes:
- Point
- Line
- LineSegment
- Polygon
- Rectangle (as an optimization as it could be represented as a special Polygon already)

Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package.

### Affected classes:
- All classes in ST80-Paths
- LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
- Rectangle, Quadrangle, Point (Graphics-Primitives)
- LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection)

## Open questions
- Should this become a single new package or a subcategory in the Graphics package?
- Should the package contain an Ellipses class?
- Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc?

## Risks
- This would potentially deprecate the existing ST80 geometry classes (ST80-Paths)
- Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

Nicolas Cellier

Re: Proposal: Geometry Classes

I wonder if this is really for drawing?

For drawing, we might need some additional attributes, like a line width, a color, end drawing policy (rounded, square, arrow...)... unless all these attributes are held into/provided by some graphics engine states?

Also a polygon might be a specification of outline or interior. If interior, different composition rules may apply if ever the edges intersect (like in bitblt or/xor/whatever...).

My understanding is that geometric objects would handle intersection, perimeter, area, and that we could provide generic affine transforms applying on these objects. They might serve as some sort of drawing spec, maybe via a visitor pattern driven by the effective drawer (which would thus hold the states) but it's not their primary responsibility.

Le mar. 22 janv. 2019 à 19:58, karl ramberg <[hidden email]> a écrit :

+1

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,
Karl

On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:
Hi everyone,

during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion.

In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on.

Bests
Patrick

# Squeak Change Proposal - Geometry Package

## Why?
Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more).

## Scope
The proposed package should cover basic 2D geometric objects and their operations represented by the following classes:
- Point
- Line
- LineSegment
- Polygon
- Rectangle (as an optimization as it could be represented as a special Polygon already)

Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package.

### Affected classes:
- All classes in ST80-Paths
- LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
- Rectangle, Quadrangle, Point (Graphics-Primitives)
- LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection)

## Open questions
- Should this become a single new package or a subcategory in the Graphics package?
- Should the package contain an Ellipses class?
- Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc?

## Risks
- This would potentially deprecate the existing ST80 geometry classes (ST80-Paths)
- Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

Kjell Godo

Re: Proposal: Geometry Classes

On Tue, Jan 22, 2019 at 12:08 Nicolas Cellier <[hidden email]> wrote:

I wonder if this is really for drawing?
For drawing, we might need some additional attributes, like a line width, a color, end drawing policy (rounded, square, arrow...)... unless all these attributes are held into/provided by some graphics engine states?
Also a polygon might be a specification of outline or interior. If interior, different composition rules may apply if ever the edges intersect (like in bitblt or/xor/whatever...).
My understanding is that geometric objects would handle intersection, perimeter, area, and that we could provide generic affine transforms applying on these objects. They might serve as some sort of drawing spec, maybe via a visitor pattern driven by the effective drawer (which would thus hold the states) but it's not their primary responsibility.

Le mar. 22 janv. 2019 à 19:58, karl ramberg <[hidden email]> a écrit :
+1

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,
Karl

On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:
Hi everyone,

during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion.

In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on.

Bests
Patrick

# Squeak Change Proposal - Geometry Package

## Why?
Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more).

## Scope
The proposed package should cover basic 2D geometric objects and their operations represented by the following classes:
- Point
- Line
- LineSegment
- Polygon
- Rectangle (as an optimization as it could be represented as a special Polygon already)

Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package.

### Affected classes:
- All classes in ST80-Paths
- LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
- Rectangle, Quadrangle, Point (Graphics-Primitives)
- LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection)

## Open questions
- Should this become a single new package or a subcategory in the Graphics package?
- Should the package contain an Ellipses class?
- Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc?

## Risks
- This would potentially deprecate the existing ST80 geometry classes (ST80-Paths)
- Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

Karl Ramberg

Re: Proposal: Geometry Classes

In reply to this post by Nicolas Cellier

You are right, of course :-)

But it will help with grasping the geometric classes, and much of that is used for drawing.

Best,

Karl

On Tue, Jan 22, 2019 at 9:08 PM Nicolas Cellier <[hidden email]> wrote:

I wonder if this is really for drawing?
For drawing, we might need some additional attributes, like a line width, a color, end drawing policy (rounded, square, arrow...)... unless all these attributes are held into/provided by some graphics engine states?
Also a polygon might be a specification of outline or interior. If interior, different composition rules may apply if ever the edges intersect (like in bitblt or/xor/whatever...).
My understanding is that geometric objects would handle intersection, perimeter, area, and that we could provide generic affine transforms applying on these objects. They might serve as some sort of drawing spec, maybe via a visitor pattern driven by the effective drawer (which would thus hold the states) but it's not their primary responsibility.

Le mar. 22 janv. 2019 à 19:58, karl ramberg <[hidden email]> a écrit :
+1

It's quite hard to get a grasp over how to draw stuff so this sound like a step in the right direction.

Best,
Karl

On Tue, Jan 22, 2019 at 6:32 PM <[hidden email]> wrote:
Hi everyone,

during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion.

In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on.

Bests
Patrick

# Squeak Change Proposal - Geometry Package

## Why?
Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more).

## Scope
The proposed package should cover basic 2D geometric objects and their operations represented by the following classes:
- Point
- Line
- LineSegment
- Polygon
- Rectangle (as an optimization as it could be represented as a special Polygon already)

Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package.

### Affected classes:
- All classes in ST80-Paths
- LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
- Rectangle, Quadrangle, Point (Graphics-Primitives)
- LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection)

## Open questions
- Should this become a single new package or a subcategory in the Graphics package?
- Should the package contain an Ellipses class?
- Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc?

## Risks
- This would potentially deprecate the existing ST80 geometry classes (ST80-Paths)
- Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

marcel.taeumel

About a new "Math" package ... (was: Proposal: Geometry Classes)

In reply to this post by patrick.rein

Hi all!

I think that we would rather need a "Math" package with "Math-Geometry" being one of multiple categories.

Please take a look at the following proposed classification:

Kernel-Objects (= not Kernel-Numbers)

Magnitude

Number

Math-Quantity

Integer (+ subclasses)

Fraction

ScaledDecimal

Math-Analysis

Complex

Float (+ subclasses)

Quaternion

Math-Geometry

Point

Line

Rectangle

Polygon

Path

Math-Collections

Vector2 (from 3DTransform, CroquetGL, etc.)

Vector3

Vector4

Matrix2x3

Matrix4x4

VectorArray

...

It would involve some effort, especially to untangle "ST80-Paths" from graphics :-) Eventually, I would like to see Nicolas' efforts for "Complex" and "Quaternion" in Trunk. And I would like to add that "number crunching" part around fancy graphics (e.g. OpenGL through FFI) to "Math-Collections" or maybe "MathExtras-Collections", looking at all the subclasses of RawBitsArray.

May I add "Math" and "MathExtras" packages so that we can slowly get started? :-)

Best,

Marcel

Am 22.01.2019 18:32:10 schrieb [hidden email] <[hidden email]>:
Hi everyone,

during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion.

In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on.

Bests
Patrick

# Squeak Change Proposal - Geometry Package

## Why?
Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more).

## Scope
The proposed package should cover basic 2D geometric objects and their operations represented by the following classes:
- Point
- Line
- LineSegment
- Polygon
- Rectangle (as an optimization as it could be represented as a special Polygon already)

Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package.

### Affected classes:
- All classes in ST80-Paths
- LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
- Rectangle, Quadrangle, Point (Graphics-Primitives)
- LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection)

## Open questions
- Should this become a single new package or a subcategory in the Graphics package?
- Should the package contain an Ellipses class?
- Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc?

## Risks
- This would potentially deprecate the existing ST80 geometry classes (ST80-Paths)
- Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

Christoph Thiede

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

Hi Marcel,

sounds interesting! I have a few thoughts regarding package dependencies.

As far as I understand, the dependency structure would look kind like this:

Kernel-Objects -> Math-Quantity (see senders of SmallInteger for example), Math-Analysis (see senders of #asFloat for example)

Math-Quantity -> Kernel (superclass), Math-Analysis (see senders of #asFloat)

Math-Analysis -> Kernel (superclass), Math-Quantity (maybe?)

Math-Geometry -> Kernel (of course), Math-Quantity (senders of SmallInteger), Math-Analysis (see senders of #asFloat)

Math-Collections would probably depend on all other packages?

The question is which of these dependencies can be eliminated and which are a problem at all.

What about Random? Do you want to keep it in Kernel, depending on Math?

What is about dependencies from Number (Kernel-Objects) to Float (Math-Analysis), for example, #asFloat, but also sophisticated things such as #sin? Do we want to create a bunch of extension methods for this?

In any case, I think the "math functions" protocol on Collection should become an extension protocol ("*Math-Analysis" or "*Math-Analysis-enumerating").

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 9. März 2021 10:50:09
An: squeak-dev
Betreff: [squeak-dev] About a new "Math" package ... (was: Proposal: Geometry Classes)

Hi all!

I think that we would rather need a "Math" package with "Math-Geometry" being one of multiple categories.

Please take a look at the following proposed classification:

Kernel-Objects (= not Kernel-Numbers)

Magnitude

Number

Math-Quantity

Integer (+ subclasses)

Fraction

ScaledDecimal

Math-Analysis

Complex

Float (+ subclasses)

Quaternion

Math-Geometry

Point

Line

Rectangle

Polygon

Path

Math-Collections

Vector2 (from 3DTransform, CroquetGL, etc.)

Vector3

Vector4

Matrix2x3

Matrix4x4

VectorArray

...

May I add "Math" and "MathExtras" packages so that we can slowly get started? :-)

Best,

Marcel

Am 22.01.2019 18:32:10 schrieb [hidden email] <[hidden email]>:

Hi everyone,

during some recent clean-up an issue with geometry objects came up. As a result the following idea came up which I thereby would like to put out for an initial discussion.

In case we find that this might be useful, I would continue by implementing a first prototype of the package as a foundation of a more in-depth discussion later on.

Bests
Patrick

# Squeak Change Proposal - Geometry Package

## Why?
Squeak implements basic geometry logic in too many different places. For example intersection of different kinds of geometric objects is implemented all over Morphic, ST80, Balloon, Graphics, and Etoys. Such extensive scattering across packages and classes impedes modularity, that is, readability and extensibility. An example for this recently came up when we discovered an issue with testing for graphical intersections between PolygonMorph and RectangleMorph. It was not possible to compute that overlapping area because the class Rectangle omits to provide an important method. A quick fix would entail unnecessary dependencies (here: Morphic -> Balloon) or duplicated code (see also http://bugs.squeak.org/view.php?id=7872). Consequently, we might want to modularize the geometry objects and operations. As a side effect, dependent packages such as Morphic can be simplified a little bit (more).

## Scope
The proposed package should cover basic 2D geometric objects and their operations represented by the following classes:
- Point
- Line
- LineSegment
- Polygon
- Rectangle (as an optimization as it could be represented as a special Polygon already)

Most classes could simply be moved from their previous packages. Afterwards the interfaces would need to be made consistent with each other to allow interoperability of all geometry classes within the new package.

### Affected classes:
- All classes in ST80-Paths
- LineSegement, Bezier2Segment, Bezier3Segment (Balloon-Geometry)
- Rectangle, Quadrangle, Point (Graphics-Primitives)
- LineIntersections, LineIntersectionSegment, LineIntersectionEvent (Etoys-Squeakland-Graphics-Tools-Intersection)

## Open questions
- Should this become a single new package or a subcategory in the Graphics package?
- Should the package contain an Ellipses class?
- Should we model curved line segments as BezierLineSegments, CurvedLineSegment, or Arc?

## Risks
- This would potentially deprecate the existing ST80 geometry classes (ST80-Paths)
- Some of the new classes will cause name clashes with existing classes. For example Line is currently in ST-80 and represents a line segment, and the class LineSegment is a line segment but not in the geometric sense as it also incorporates arcs. Both names might then be used by new classes with different meanings. This might be mitigated by introducing a pre-/postfix for the names of the new classes.

Carpe Squeak!

Christoph Thiede

Re: About a new "Math" package ... (was: Proposal: Geometry Classes)

Referring to the MathExtras proposal ... What is your general idea of an extra package? I know Morphic-Extras as a collection of non-necessary tools, helpers, and demos, but the general idea sounds kind of vague to me.

CollectionsExtras would be a place for Text enhancements such as attributes (so actually, we could also call it simply "TextSupport" or something like this), MathExtras would contain "math stuff that is not necessary" ...

Do you have any more precise idea of what classifies an extra package or would "MathSmorgasbord" be a franker name for the package? If yes, this would make me think about the coherency of such a package ... Just my 2 cents, of course. :)

Best,

Christoph

Von: Thiede, Christoph
Gesendet: Dienstag, 9. März 2021 12:56:04
An: squeak-dev
Betreff: AW: [squeak-dev] About a new "Math" package ... (was: Proposal: Geometry Classes)