The Trunk: Graphics-mt.404.mcz
Locked
12
12
 
|
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! |
Re: The Trunk: Graphics-mt.404.mcz
|
|
> Adds an infix version for Rectangle >> #center:extent: for convenience.
> > The name #inflate: is subject to discussion. :-) #extendTo: ? Stef |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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. |
Re: The Trunk: Graphics-mt.404.mcz
|
|
spreadToExtent:
+1 Stef |
Re: The Trunk: Graphics-mt.404.mcz
|
|
rectangleWithExtent:
On Sun, 2 Dec 2018 at 14:55, Stéphane Rollandin <[hidden email]> wrote: spreadToExtent: |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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! > > |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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 >> > |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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: 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:
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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 |
Re: The Trunk: Graphics-mt.404.mcz
|
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 |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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 |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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 |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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 |
Re: The Trunk: Graphics-mt.404.mcz
|
|
Le mer. 5 déc. 2018 à 16:59, Tm Jhnsn <[hidden email]> a écrit :
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... |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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. (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]>:
|
Re: The Trunk: Graphics-mt.404.mcz
|
|
In reply to this post by Nicolas Cellier
Hi Nicolas, On Wed, Dec 5, 2018 at 1:31 PM Nicolas Cellier <[hidden email]> wrote:
Ah, that's a good point.
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)
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: Graphics-mt.404.mcz
|
|
In reply to this post by Jakob Reschke
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. |
Re: The Trunk: Graphics-mt.404.mcz
|
|
In reply to this post by Jakob Reschke
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:
|
Re: The Trunk: Graphics-mt.404.mcz
|
|
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 < > digit@ > > 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 |
Re: The Trunk: Graphics-mt.404.mcz
|
|
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 +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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |