[squeak-dev] Proposal: Geometry Classes

karl ramberg karlramberg at gmail.com
Fri Jan 25 21:55:37 UTC 2019


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 <
nicolas.cellier.aka.nice at gmail.com> 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 <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/20190125/b821bd5c/attachment.html>


More information about the Squeak-dev mailing list