[squeak-dev] The Trunk: Graphics-mt.404.mcz

[c***@source.squeak.org]

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]

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]

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]

[karl ramberg]

+1
Stef

[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.

+1
S

[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

[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.

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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 -

[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

***@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]

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]

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]

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]

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]

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]

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!