+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 <patrick.rein at hpi.uni-potsdam.de> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190122/9fb0febc/attachment.html>