The Trunk: Graphics-mt.404.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The Trunk: Graphics-mt.404.mcz

commits-2
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: self extent: aPoint!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Stéphane Rollandin
> Adds an infix version for Rectangle >> #center:extent: for convenience.
>
> The name #inflate: is subject to discussion. :-)

#extendTo: ?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Nicolas Cellier
spreadTo: spreadToExtent:

Le dim. 2 déc. 2018 à 13:44, Stéphane Rollandin <[hidden email]> a écrit :
> Adds an infix version for Rectangle >> #center:extent: for convenience.
>
> The name #inflate: is subject to discussion. :-)

#extendTo: ?

Stef



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Stéphane Rollandin
spreadToExtent:

+1

Stef

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Karl Ramberg
rectangleWithExtent:

On Sun, 2 Dec 2018 at 14:55, Stéphane Rollandin <[hidden email]> wrote:
spreadToExtent:

+1

Stef



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Chris Muller-3
In reply to this post by commits-2
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
On Sun, Dec 2, 2018 at 4:50 AM <[hidden email]> wrote:

>
> 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: self extent: aPoint!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Chris Muller-3
In reply to this post by Karl Ramberg
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.
On Sun, Dec 2, 2018 at 9:05 AM karl ramberg <[hidden email]> wrote:

>
> rectangleWithExtent:
>
> On Sun, 2 Dec 2018 at 14:55, Stéphane Rollandin <[hidden email]> wrote:
>>
>> spreadToExtent:
>>
>> +1
>>
>> Stef
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Eliot Miranda-2
In reply to this post by commits-2


On Sun, Dec 2, 2018 at 2:50 AM <[hidden email]> wrote:
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. :-)

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

    centredRectangleWithExtent:  centredRectangleExtent:


=============== 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: self extent: aPoint!




--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Stéphane Rollandin
In reply to this post by Chris Muller-3
> 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



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

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


Stéphane Rollandin wrote

>> 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/Squeak-Dev-f45488.html

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Chris Muller-3
Hey Marcel,

> <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,
  Chris

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

David T. Lewis
In reply to this post by marcel.taeumel
On Tue, Dec 04, 2018 at 02:12:11AM -0600, marcel.taeumel wrote:

> 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?

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
with #inflate:.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Tim Johnson-2
In reply to this post by marcel.taeumel

On Dec 4, 2018, at 12:12 AM, marcel.taeumel wrote:

> 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



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Nicolas Cellier


Le mer. 5 déc. 2018 à 16:59, Tm Jhnsn <[hidden email]> a écrit :

On Dec 4, 2018, at 12:12 AM, marcel.taeumel wrote:

> 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@100 inflate: 50@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...






Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Jakob Reschke-2
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@5 extent: 10@10 could also be a circle... interestingly, then I would assume it to be centered at 5@5 already. 5@5 corner: 10@10 seems less ambiguous to me. After all, circles don't have corners...

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

Am Mi., 5. Dez. 2018 um 22:32 Uhr schrieb Nicolas Cellier <[hidden email]>:


Le mer. 5 déc. 2018 à 16:59, Tm Jhnsn <[hidden email]> a écrit :

On Dec 4, 2018, at 12:12 AM, marcel.taeumel wrote:

> 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@100 inflate: 50@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...







Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Eliot Miranda-2
In reply to this post by Nicolas Cellier
Hi Nicolas,

On Wed, Dec 5, 2018 at 1:31 PM Nicolas Cellier <[hidden email]> wrote:

Le mer. 5 déc. 2018 à 16:59, Tm Jhnsn <[hidden email]> a écrit :

On Dec 4, 2018, at 12:12 AM, marcel.taeumel wrote:

> 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@100 inflate: 50@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...

Ah, that's a good point.
 
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)
 
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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

timrowledge
In reply to this post by Jakob Reschke-2
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@5 expandBy: 2 would make 3@3 corner: 7@7, 5@5 expandBy: 3@4 would make 2@1 corner: 8@9, and 5@5 expandBy: (2@3 corner: 4@5) would make 3@2 corner: 9@10. Obviously insetBy: would follow the same pattern.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Hard work pays off in the future. Laziness pays off now.



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Karl Ramberg
In reply to this post by Jakob Reschke-2
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

On Wed, Dec 5, 2018 at 11:44 PM Jakob Reschke <[hidden email]> wrote:
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@5 extent: 10@10 could also be a circle... interestingly, then I would assume it to be centered at 5@5 already. 5@5 corner: 10@10 seems less ambiguous to me. After all, circles don't have corners...

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

Am Mi., 5. Dez. 2018 um 22:32 Uhr schrieb Nicolas Cellier <[hidden email]>:


Le mer. 5 déc. 2018 à 16:59, Tm Jhnsn <[hidden email]> a écrit :

On Dec 4, 2018, at 12:12 AM, marcel.taeumel wrote:

> 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@100 inflate: 50@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...








Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

marcel.taeumel
In reply to this post by Nicolas Cellier
I think that we got used to seeing "0@0 corner: 10@10" as a rectangle. Like
"0@0 to: 10@10" might create a line (or an interval over points? The same?
:-). Yet, "0@0 extent: 10@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


Nicolas Cellier wrote
> Le mer. 5 déc. 2018 à 16:59, Tm Jhnsn &lt;

> digit@

> &gt; a écrit :
>
>>
>> On Dec 4, 2018, at 12:12 AM, marcel.taeumel wrote:
>>
>> > 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@100 inflate:
> 50@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...





--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Graphics-mt.404.mcz

Bert Freudenberg
On Wed 5. Dec 2018 at 23:35, marcel.taeumel <[hidden email]> wrote:
I think that we got used to seeing "0@0 corner: 10@10" as a rectangle. Like
"0@0 to: 10@10" might create a line (or an interval over points? The same?
:-). Yet, "0@0 extent: 10@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:

+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
 


12