[squeak-dev] Proposal: Geometry Classes

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Jan 22 20:07:55 UTC 2019


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 <karlramberg at gmail.com> 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 <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/0fb726c9/attachment-0001.html>


More information about the Squeak-dev mailing list