Discussion:
The Trunk: Graphics-mt.404.mcz
(too old to reply)
c***@source.squeak.org
0000-12-03 10:50:20 UTC
Permalink
Marcel Taeumel uploaded a new version of Graphics to project The Trunk:
http://source.squeak.org/trunk/Graphics-mt.404.mcz

==================== Summary ====================

Name: Graphics-mt.404
Author: mt
Time: 2 December 2018, 11:49:55.694325 am
UUID: c61bf172-8ce2-2b42-9ded-3b10fa30cf8d
Ancestors: Graphics-pre.403

Adds an infix version for Rectangle >> #center:extent: for convenience.

The name #inflate: is subject to discussion. :-)

=============== Diff against Graphics-pre.403 ===============

Item was added:
+ ----- Method: Point>>inflate: (in category 'converting') -----
+ inflate: aPoint
+ "Answer a Rectangle whose center is the receiver and whose extent is
+ aPoint. This is one of the infix ways of expressing the creation of a
+ rectangle."
+
+ ^Rectangle center: sel
Stéphane Rollandin
2018-12-02 12:44:31 UTC
Permalink
Post by c***@source.squeak.org
Adds an infix version for Rectangle >> #center:extent: for convenience.
The name #inflate: is subject to di
Nicolas Cellier
2018-12-02 13:15:23 UTC
Permalink
Post by c***@source.squeak.org
Adds an infix version for Rectangle >> #center:extent: for convenience.
The name #inflate: is subject to discussion. :-)
#extendTo: ?
Stef
Stéphane Rollandin
2018-12-02 13:55:54 UTC
Permalink
karl ramberg
2018-12-02 15:05:01 UTC
Permalink
+1
Stef
Chris Muller
2018-12-02 20:58:40 UTC
Permalink
Karl's is the only one that doesn't sound like the Rectangle is
supposed to be bigger. The other names seem to assume an "expansion",
which is not made by the implementation.
+1
S
Stéphane Rollandin
2018-12-02 22:46:55 UTC
Permalink
Post by Chris Muller
Karl's is the only one that doesn't sound like the Rectangle is
supposed to be bigger. The other names seem to assume an "expansion",
which is not made by the implementation.
The receiver is not a rectangle, it is a point. It is rather natural to
think of going from a point to a rectangle centered at that point as an
expansion of
marcel.taeumel
2018-12-04 08:12:11 UTC
Permalink
Hi, there. :-)

I didn't put it into the inbox because 1) I wanted to speed up the
discussion and 2) thought this is a good name along Point >> #extent: and
#corner:. Whatever we choose to improve consistency here, those messages
should be considered, too.

<offtopic> Anyway, there is no such thing as "garbage version in the
ancestry". This is not George Orwell's 1984 where people dictate or rewrite
history. History becomes what has happened. If a database (back-end) or
algorithm gets confused with this kind of events, then that database has to
be fixed. Not the data. :-) Just my two cents. </offtopic>

Sorry for any inconveniences.

So, what do we have up to here:

- #inflate:, #extent:, #corner:
- #extendTo:, #extent:, #corner:
- #spreadTo:, #extent:, #corner:
- #spreadToExtent:, #extent:, #corner:
- #rectangleWithExtent:, #extent:, #corner:
- #centredRectangleWithExtent:, #extent:, #corner:
- #centredRectangleExtent:, #extent:, #corner:

Eliot suggests to maybe treat the point as extent, not position information:

- #asRectangleCentredAt:, (#asRectangleOriginAt:)

So far, I do not like any of the suggestions because I see the triple of
(?/#extent:/#corner:) as more important than the perfect wording for that
single new message that calls Rectangle class >> #center:extent:. It is no
option to rename (and deprecate) #extent: and #corner: because of existing
code.

Instead, we could introduce three (or four?) new messages that all improve
on the wording. Maybe:

#asRectangleOriginWithExtent:
#asRectangleCenterWithExtent:
#asRectangleOriginWithCorner:
#asRectangleCenterWithCorner:

Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.

Very interesting. :-) Thoughts?

Best,
Marcel
Post by Stéphane Rollandin
Post by Chris Muller
Karl's is the only one that doesn't sound like the Rectangle is
supposed to be bigger. The other names seem to assume an "expansion",
which is not made by the implementation.
The receiver is not a rectangle, it is a point. It is rather natural to
think of going from a point to a rectangle centered at that point as an
expansion of sort.
Stef
--
Sent from: http://forum.world.st/
Chris Muller
2018-12-04 23:44:29 UTC
Permalink
Hey Marcel,
Post by marcel.taeumel
<offtopic> Anyway, there is no such thing as "garbage version in the
ancestry". This is not George Orwell's 1984 where people dictate or rewrite
history. History becomes what has happened. If a database (back-end) or
algorithm gets confused with this kind of events, then that database has to
be fixed. Not the data. :-) Just my two cents. </offtopic>
There is a such thing as "quality data" and "log data", and neither
are Orwellian (I don't find such accusation a very productive
argument).

Please be cognizant of the impacts of junk commits. Trying to turn
the trunk ancestry into a tape-recorder of our entire dev history is a
huge mistake. My backend db can handle it fine, it's everywhere else
that it taxes people (their disk, RAM, CPU, and network).

Best,
Chr
David T. Lewis
2018-12-05 03:29:23 UTC
Permalink
Post by marcel.taeumel
Hi, there. :-)
I didn't put it into the inbox because 1) I wanted to speed up the
discussion and 2) thought this is a good name along Point >> #extent: and
#corner:. Whatever we choose to improve consistency here, those messages
should be considered, too.
<offtopic> Anyway, there is no such thing as "garbage version in the
ancestry". This is not George Orwell's 1984 where people dictate or rewrite
history. History becomes what has happened. If a database (back-end) or
algorithm gets confused with this kind of events, then that database has to
be fixed. Not the data. :-) Just my two cents. </offtopic>
Sorry for any inconveniences.
- #asRectangleCentredAt:, (#asRectangleOriginAt:)
So far, I do not like any of the suggestions because I see the triple of
(?/#extent:/#corner:) as more important than the perfect wording for that
single new message that calls Rectangle class >> #center:extent:. It is no
option to rename (and deprecate) #extent: and #corner: because of existing
code.
Instead, we could introduce three (or four?) new messages that all improve
Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.
Very interesting. :-) Thoughts?
When I look at it in a browser, as opposed to email discussion, I am happy
with #inflate: because it is consistent with #corner: and #extent: all of
which are in method category 'converting'.

Each of these answers a Rectangle with an extent defined by the argument.
The receiver is a position, the argument is an extent, and the result
is a rectangle.

I don't think that a different selector is needed, but if I were to
suggest one it would be Point>>center: instead of Point>>inflate:.

This would be a change from this:

Point>>inflate: aPoint
"Answer a Rectangle whose center is the receiver and whose extent is
aPoint. This is one of the infix ways of expressing the creation of a
rectangle."

^Rectangle center: self extent: aPoint

To this:

Point>>>center: extent
"Answer a Rectangle whose center is the receiver and whose extent is
extent. This is one of the infix ways of expressing the creation of a
rectangle."

^Rectangle center: self extent: extent


But #inflate: is good, and it is supported by unit tests, so I am happy
Tm Jhnsn
2018-12-05 15:59:41 UTC
Permalink
Post by marcel.taeumel
Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.
Very interesting. :-) Thoughts?
Balloons inflate, and Smalltalk is quite associated with bal
Nicolas Cellier
2018-12-05 21:31:34 UTC
Permalink
Post by marcel.taeumel
Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.
Very interesting. :-) Thoughts?
Balloons inflate, and Smalltalk is quite associated with balloons... :)
Tim J
But in this case, should deflate return the center ? (***@100 inflate: ***@30)
deflate.
I like spread because there is a kind of isotropic notion, we extend in all
directions...

The lexical field of symmetry may fit: we construct a rectangle by taking
those two vertices:
- image of aPoint by symmetry around myself,
- and aPoint.
So it's somehow a mirroring action:

centerPoint mirror: cornerPoint.
centerPoint reflect: cornerPoint.

We could also think of pivoting or unfolding in the 3rd dimension...
But I find the intention very hard to grasp... It's not obvious that the
message should answer a Rectangle rather than a Point.
And the meaning of argument slipped from extent to corner which is a
different action...

I note that inflate, spread, etc... are verbs, while corner: and extent:
are nouns...
We understand corner: and extent: because we may think of them as
attributes of a Rectangle... (or just because we're used to them?)
In this case, diagonal: may fit too, but the difference with extent: is
thin, and I don't find the notion of isotropic spread in it.
In fact, diagonal: might be to vertex:vertex: what corner: is to
origin:corner: because we can define a rectangle by any of its diagonals...

Geometrically, we may also see self and extentPoint as defining the
diagonal by a center and a diameter of circumscribing circle...
So its a kind of circumExtent: that we pass to the center... Not very clear
that it will answer a Rectangle...
Jakob Reschke
2018-12-05 22:44:31 UTC
Permalink
With #extent: and #corner: we "just know" that these are for creating
Rectangles. Just like we have learned that the symbol + is not about two
things crossing, but about adding things together, especially when it is
surrounded by numbers. Creating a new "well-known" word from the very
beginning is harder and you suddenly realize that all of the selectors
without "rectangle" in their name only make sense when you assume a 2D
graphics environment as the context, as opposed to, well, banking software,
maybe? But since the class Point is for 2D coordinates in such an
environment anyway, this can be justified.

Maybe you should ask yourself how you would like the expression to read if
it were the printString of the Rectangle. And when you think about it,
switch on and off in your mind the assumption that you already know you are
creating a rectangle when you evaluate the result. For #extent:, you have
to assume that, don't you? Otherwise ***@5 extent: ***@10 could also be a
circle... interestingly, then I would assume it to be centered at ***@5
already. ***@5 corner: ***@10 seems less ambiguous to me. After all, circles
don't have corners...

(***@0 extent: ***@10) printString
==> '***@5 inflate: ***@10' ? Does not seem natural to me. This relates to
Nicolas's verb vs. noun argument.
==> '***@5 surroundedBy: ***@10'
==> '***@5 inTheMiddleOf: ***@10' (well, misleading example... think of '***@50
inTheMiddleOf: ***@10' instead)
==> '***@5 amidst: ***@10'
==> '***@10 around: ***@5'
==> '***@10 withCenter: ***@5'
==> '***@10 centeredAt: ***@5'
(repeating other's suggestions now, purposely uncommented)
==> '***@5 extendTo: ***@10'
==> '***@5 spreadTo: ***@10'
==> '***@5 spreadToExtent: ***@10'
==> '***@5 rectangleWithExtent: ***@10'
==> '***@10 asRectangleCentredAt: ***@5'
==> '***@5 centredRectangleWithExtent: ***@10'
==> '***@5 centredRectangleExtent: ***@10'

Am Mi., 5. Dez. 2018 um 22:32 Uhr schrieb Nicolas Cellier <
Post by Nicolas Cellier
Post by marcel.taeumel
Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.
Very interesting. :-) Thoughts?
Balloons inflate, and Smalltalk is quite associated with balloons... :)
Tim J
I like spread because there is a kind of isotropic notion, we extend in
all directions...
The lexical field of symmetry may fit: we construct a rectangle by taking
- image of aPoint by symmetry around myself,
- and aPoint.
centerPoint mirror: cornerPoint.
centerPoint reflect: cornerPoint.
We could also think of pivoting or unfolding in the 3rd dimension...
But I find the intention very hard to grasp... It's not obvious that the
message should answer a Rectangle rather than a Point.
And the meaning of argument slipped from extent to corner which is a
different action...
are nouns...
We understand corner: and extent: because we may think of them as
attributes of a Rectangle... (or just because we're used to them?)
In this case, diagonal: may fit too, but the difference with extent: is
thin, and I don't find the notion of isotropic spread in it.
In fact, diagonal: might be to vertex:vertex: what corner: is to
origin:corner: because we can define a rectangle by any of its diagonals...
Geometrically, we may also see self and extentPoint as defining the
diagonal by a center and a diameter of circumscribing circle...
So its a kind of circumExtent: that we pass to the center... Not very
clear that it will answer a Rectangle...
tim Rowledge
2018-12-05 23:03:50 UTC
Permalink
Why not #expandBy: ? We already use it for Rectangles and it means what I think we've been discussing here (I admit this may be a misunderstanding in which case this email will evaporate and leave no egg). It works descriptively (at least in English!) without being too long winded.

So ***@5 expandBy: 2 would make ***@3 corner: ***@7, ***@5 expandBy: ***@4 would make ***@1 corner: ***@9, and ***@5 expandBy: (***@3 corner: ***@5) would make ***@2 corner: ***@10. Obviously insetBy: would follow the same pattern.

tim
--
tim Rowledge; ***@rowledge.org; http://www.rowledge.org/tim
Hard work
karl ramberg
2018-12-06 06:02:45 UTC
Permalink
Since the returned object is not known from the method name inflate, one
must read the method inflate: to get what is happening here.

That's my point of view. Pun intended. Ha ha

Fun discussion

Cheers,
Karl
Post by Jakob Reschke
With #extent: and #corner: we "just know" that these are for creating
Rectangles. Just like we have learned that the symbol + is not about two
things crossing, but about adding things together, especially when it is
surrounded by numbers. Creating a new "well-known" word from the very
beginning is harder and you suddenly realize that all of the selectors
without "rectangle" in their name only make sense when you assume a 2D
graphics environment as the context, as opposed to, well, banking software,
maybe? But since the class Point is for 2D coordinates in such an
environment anyway, this can be justified.
Maybe you should ask yourself how you would like the expression to read if
it were the printString of the Rectangle. And when you think about it,
switch on and off in your mind the assumption that you already know you are
creating a rectangle when you evaluate the result. For #extent:, you have
don't have corners...
Nicolas's verb vs. noun argument.
(repeating other's suggestions now, purposely uncommented)
Am Mi., 5. Dez. 2018 um 22:32 Uhr schrieb Nicolas Cellier <
Post by Nicolas Cellier
Post by marcel.taeumel
Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.
Very interesting. :-) Thoughts?
Balloons inflate, and Smalltalk is quite associated with balloons... :)
Tim J
I like spread because there is a kind of isotropic notion, we extend in
all directions...
The lexical field of symmetry may fit: we construct a rectangle by taking
- image of aPoint by symmetry around myself,
- and aPoint.
centerPoint mirror: cornerPoint.
centerPoint reflect: cornerPoint.
We could also think of pivoting or unfolding in the 3rd dimension...
But I find the intention very hard to grasp... It's not obvious that the
message should answer a Rectangle rather than a Point.
And the meaning of argument slipped from extent to corner which is a
different action...
are nouns...
We understand corner: and extent: because we may think of them as
attributes of a Rectangle... (or just because we're used to them?)
In this case, diagonal: may fit too, but the difference with extent: is
thin, and I don't find the notion of isotropic spread in it.
In fact, diagonal: might be to vertex:vertex: what corner: is to
origin:corner: because we can define a rectangle by any of its diagonals...
Geometrically, we may also see self and extentPoint as defining the
diagonal by a center and a diameter of circumscribing circle...
So its a kind of circumExtent: that we pass to the center... Not very
clear that it will answer a Rectangle...
Eliot Miranda
2018-12-05 22:59:56 UTC
Permalink
Hi Nicolas,

On Wed, Dec 5, 2018 at 1:31 PM Nicolas Cellier <
Post by Nicolas Cellier
Post by marcel.taeumel
Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.
Very interesting. :-) Thoughts?
Balloons inflate, and Smalltalk is quite associated with balloons... :)
Tim J
I like spread because there is a kind of isotropic notion, we extend in
all directions...
The lexical field of symmetry may fit: we construct a rectangle by taking
- image of aPoint by symmetry around myself,
- and aPoint.
centerPoint mirror: cornerPoint.
centerPoint reflect: cornerPoint.
We could also think of pivoting or unfolding in the 3rd dimension...
But I find the intention very hard to grasp... It's not obvious that the
message should answer a Rectangle rather than a Point.
And the meaning of argument slipped from extent to corner which is a
different action...
are nouns...
Ah, that's a good point.
Post by Nicolas Cellier
We understand corner: and extent: because we may think of them as
attributes of a Rectangle... (or just because we're used to them?)
So using center: or centre: would work, except that it's extentPoint
center: centrePoint, which is at odds with originPoint extent: extentPoint
& originPoint corner: cornerPoint. But I find center:/centre: far less
misleading than inflate:, which is also a verb, but one with no obvious
interpretation to me.

These two are also more understandable to me:

centrePoint atCenterExtent: extentPoint
centrePoint atCenterCorner: cornerPoint (and this would depend on whether
centrePoint <=: cornerPoint or centrePoint >=: cornerPoint, and an error
otherwise)
Post by Nicolas Cellier
In this case, diagonal: may fit too, but the difference with extent: is
thin, and I don't find the notion of isotropic spread in it.
In fact, diagonal: might be to vertex:vertex: what corner: is to
origin:corner: because we can define a rectangle by any of its diagonals...
Geometrically, we may also see self and extentPoint as defining the
diagonal by a center and a diameter of circumscribing circle...
So its a kind of circumExtent: that we pass to the center... Not very
clear that it will answer a Rectangle...
_,,,^..^,,,_
best, Eliot
marcel.taeumel
2018-12-06 07:35:19 UTC
Permalink
I think that we got used to seeing "***@0 corner: ***@10" as a rectangle. Like
"***@0 to: ***@10" might create a line (or an interval over points? The same?
:-). Yet, "***@0 extent: ***@10" could also be a line or a vector.

I like the verb-vs-noun argument. So, following Nicolas', Eliot's, and
David's thoughts, I vote for:

Point >> #center:

Best,
Marcel
Le mer. 5 déc. 2018 à 16:59, Tm Jhnsn &lt;
Post by marcel.taeumel
Yet, such an infix notation for rectangle creation would not be much of an
improvement over Rectangle class >> center:extent:.
Very interesting. :-) Thoughts?
Balloons inflate, and Smalltalk is quite associated with balloons... :)
Tim J
deflate.
I like spread because there is a kind of isotropic notion, we extend in all
directions...
The lexical field of symmetry may fit: we construct a rectangle by taking
- image of aPoint by symmetry around myself,
- and aPoint.
centerPoint mirror: cornerPoint.
centerPoint reflect: cornerPoint.
We could also think of pivoting or unfolding in the 3rd dimension...
But I find the intention very hard to grasp... It's not obvious that the
message should answer a Rectangle rather than a Point.
And the meaning of argument slipped from extent to corner which is a
different action...
are nouns...
We understand corner: and extent: because we may think of them as
attributes of a Rectangle... (or just because we're used to them?)
In this case, diagonal: may fit too, but the difference with extent: is
thin, and I don't find the notion of isotropic spread in it.
In fact, diagonal: might be to vertex:vertex: what corner: is to
origin:corner: because we can define a rectangle by any of its
diagonals...
Geometrically, we may also see self and extentPoint as defining the
diagonal by a center and a diameter of circumscribing circle...
So its a kind of circumExtent: that we pass to the center... Not very clear
that it will answer a Rectangle...
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.
Bert Freudenberg
2018-12-06 17:45:51 UTC
Permalink
Post by marcel.taeumel
I like the verb-vs-noun argument. So, following Nicolas', Eliot's, and
+1

(I do like Tim’s expandBy: reasoning too, but the argument would need to be
half the extent)

- Bert -
--
--
Dr. Bert Freudenberg
7275 Franklin Avenue #210
Los Angeles CA 90046
+1 (818) 482-3991
Chris Cunningham
2018-12-06 21:33:57 UTC
Permalink
Post by marcel.taeumel
I like the verb-vs-noun argument. So, following Nicolas', Eliot's, and
+1
It's decent, but I would assume that the ARGUMENT is the center, not the
receiver. As long as the callers name the variables well that might not be
a problem, but

***@10 center: ***@5

reading it without the discussion here, which would you assume the center
to be? ***@10 or ***@5?

Maybe #centerWithExtent:?
***@10 centerWithExtent: ***@5

-cbc
David T. Lewis
2018-12-07 00:29:49 UTC
Permalink
Post by Chris Cunningham
Post by marcel.taeumel
I like the verb-vs-noun argument. So, following Nicolas', Eliot's, and
+1
It's decent, but I would assume that the ARGUMENT is the center, not the
receiver. As long as the callers name the variables well that might not be
a problem, but
reading it without the discussion here, which would you assume the center
Maybe #centerWithExtent:?
+1

I think it may have been me who suggested #center: so I will say that
I think #centerWithExtent: is more readable, and remains consistent
with the existing #corner: and #extent: methods.

Dav
Tobias Pape
2018-12-07 07:43:14 UTC
Permalink
Post by David T. Lewis
Post by Chris Cunningham
Post by marcel.taeumel
I like the verb-vs-noun argument. So, following Nicolas', Eliot's, and
+1
It's decent, but I would assume that the ARGUMENT is the center, not the
receiver. As long as the callers name the variables well that might not be
a problem, but
reading it without the discussion here, which would you assume the center
Maybe #centerWithExtent:?
+1
I think it may have been me who suggested #center: so I will say that
I think #centerWithExtent: is more readable, and remains consistent
with the existing #corner: and #extent: methods.
Why not both?
#centerWithExtent: AND #centerWithCorner:

:)
-t
marcel.taeumel
2018-12-07 10:17:49 UTC
Permalink
We could tread the receiver as extent in this case and see how it works out?

(***@50 center: ***@5) = (Rectangle center: ***@5 extent: ***@50).

Best,
Marcel
Post by David T. Lewis
On Thu, Dec 6, 2018 at 9:46 AM Bert Freudenberg &lt;
&gt;
On Wed 5. Dec 2018 at 23:35, marcel.taeumel &lt;
Post by marcel.taeumel
I like the verb-vs-noun argument. So, following Nicolas', Eliot's, and
+1
It's decent, but I would assume that the ARGUMENT is the center, not
the
receiver. As long as the callers name the variables well that might not be
a problem, but
reading it without the discussion here, which would you assume the center
Maybe #centerWithExtent:?
+1
I think it may have been me who suggested #center: so I will say that
I think #centerWithExtent: is more readable, and remains consistent
with the existing #corner: and #extent: methods.
Dave
--
Sent from: http://forum.world.st/Sque
David T. Lewis
2018-12-07 15:16:38 UTC
Permalink
Post by marcel.taeumel
We could tread the receiver as extent in this case and see how it works out?
That definitely reads more clearly, but in Point>>corner: and Point>>center:
the receiver is used to establish the position of the new rectangle, and
the argument establishes the size. It m

Chris Muller
2018-12-02 20:55:04 UTC
Permalink
Welcome back Marcel!

This is a good time for me to ask the community a favor again. To
think of and maintain Squeak's ancestry as an artifact we care about,
a representation of the community's list of hand-selected
improvements, *and nothing more*, whilst letting the Inbox be the
"infinite black hole" for proposals and discussions.

I'm only asking that we not deliberately pose questions or early
proposals directly in trunk, because it's pretty much 100% guaranteed
to end up as a garbage version in the ancestry. Dave Lewis recently
added a new button on the MC Repository browser to also help with this
called "Reparent". It's the same as Adopt, except it makes the
selection the *sole* parent. Since then we had a version go into
trunk that had a halt left in it, that is a case where that button
would be useful.

I sincerely appreciate your understanding, folks. The size and
quality of Squeak's ancestry is worth caring about.

Regards,
Chris
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-mt.404.mcz
==================== Summary ====================
Name: Graphics-mt.404
Author: mt
Time: 2 December 2018, 11:49:55.694325 am
UUID: c61bf172-8ce2-2b42-9ded-3b10fa30cf8d
Ancestors: Graphics-pre.403
Adds an infix version for Rectangle >> #center:extent: for convenience.
The name #inflate: is subject to discussion. :-)
=============== Diff against Graphics-pre.403 ===============
+ ----- Method: Point>>inflate: (in category 'converting') -----
+ inflate: aPoint
+ "Answer a Rectangle whose center is the receiver and whose extent is
+ aPoint. This is one of the infix ways of expressing the creation of a
+ rectangle."
+
+ ^Rectangle cente
Eliot Miranda
2018-12-02 21:51:43 UTC
Permalink
Post by c***@source.squeak.org
http://source.squeak.org/trunk/Graphics-mt.404.mcz
==================== Summary ====================
Name: Graphics-mt.404
Author: mt
Time: 2 December 2018, 11:49:55.694325 am
UUID: c61bf172-8ce2-2b42-9ded-3b10fa30cf8d
Ancestors: Graphics-pre.403
Adds an infix version for Rectangle >> #center:extent: for convenience.
The name #inflate: is subject to discussion. :-)
I don't like inflate: or any of the other suggestions. Why not have it the
other way round so that the extent is the receiver, then one could call it

asRectangleCentredAt:

or some such. inflate: makes me thing of division by zero because points
have no extent. If you insist on the inflate: way round then intension
revealing would be
Post by c***@source.squeak.org
=============== Diff against Graphics-pre.403 ===============
+ ----- Method: Point>>inflate: (in category 'converting') -----
+ inflate: aPoint
+ "Answer a Rectangle whose center is the receiver and whose extent
is
+ aPoint. This is one of the infix ways of expressing the creation
of a
+ rectangle."
+
+ ^Rectangle center: self extent: aPoint!
--
_,,,^..^,,,_
best, Eliot
Loading...