The Inbox: Graphics-cbc.372.mcz
Locked
 
|
A new version of Graphics was added to project The Inbox:
http://source.squeak.org/inbox/Graphics-cbc.372.mcz ==================== Summary ==================== Name: Graphics-cbc.372 Author: cbc Time: 28 March 2017, 5:18:09.019402 pm UUID: 7b9783b1-87c5-3549-ac32-42acd6abcb12 Ancestors: Graphics-eem.371 Added method to allow creating a rectangle based on teh center of the rectangle. =============== Diff against Graphics-eem.371 =============== Item was added: + ----- Method: Rectangle class>>exactCenter:extent: (in category 'instance creation') ----- + exactCenter: centerPoint extent: extentPoint + "Answer an instance of me whose center is centerPoint and width + by height is extentPoint. " + ^ self origin: centerPoint - (extentPoint / 2) extent: extentPoint + ! |
Re: The Inbox: Graphics-cbc.372.mcz
|
|
What is the difference to the existing method ?
center: centerPoint extent: extentPoint "Answer an instance of me whose center is centerPoint and width by height is extentPoint. " ^self origin: centerPoint - (extentPoint//2) extent: extentPoint Is / vs // worth the effort? On Wed, 29 Mar 2017 00:18:24 0000, [hidden email] <[hidden email]> wrote: > A new version of Graphics was added to project The Inbox: > http://source.squeak.org/inbox/Graphics-cbc.372.mcz > > ==================== Summary ==================== > > Name: Graphics-cbc.372 > Author: cbc > Time: 28 March 2017, 5:18:09.019402 pm > UUID: 7b9783b1-87c5-3549-ac32-42acd6abcb12 > Ancestors: Graphics-eem.371 > > Added method to allow creating a rectangle based on teh center of the > rectangle. > > =============== Diff against Graphics-eem.371 =============== > > Item was added: > + ----- Method: Rectangle class>>exactCenter:extent: (in category 'instance > creation') ----- > + exactCenter: centerPoint extent: extentPoint > + "Answer an instance of me whose center is centerPoint and width > + by height is extentPoint. " > + ^ self origin: centerPoint - (extentPoint / 2) extent: extentPoint > + ! > > > |
|
|
Hi, yes, / vs // is definitely worth the effort. For this use case, I am utilizing Rectangle to represent rectangles that I want to place in a Visio drawing, and that representation uses fractional measurements (inches, say) instead of pixels. A better question is should I be using Rectangle for this. Maybe we should create a 'TrueRectangle' class or something similar so that we can actually talk about and share what can really be done with rectangles, instead of the 'ScreenRectangle' that we have today called Rectangle. That said, this change does let me work with rectangle for this purpose, but it does move the class away from our pixel based rectangle. -cbc On Wed, Mar 29, 2017 at 6:21 AM, H. Hirzel <[hidden email]> wrote: What is the difference to the existing method ? |
Re: The Inbox: Graphics-cbc.372.mcz
|
|
Hi Chris,
On 3/29/17, Chris Cunningham <[hidden email]> wrote: > Hi, > > yes, / vs // is definitely worth the effort. For this use case, I am > utilizing Rectangle to represent rectangles that I want to place in a Visio > drawing, and that representation uses fractional measurements (inches, say) > instead of pixels. In the context of pixel based Rectangles it makes no sense. If we talk about measurements in inches and centimeters than it is fine. But the class Rectangle is not about that. > A better question is should I be using Rectangle for this. Maybe we should > create a 'TrueRectangle' class or something similar so that we can actually > talk about and share what can really be done with rectangles, instead of > the 'ScreenRectangle' that we have today called Rectangle. I prefer this. Actually I need such a class as well. At the moment I work with RectangleMorph. > That said, this change does let me work with rectangle for this purpose, > but it does move the class away from our pixel based rectangle. I do not understand how this change helps you with that .... --Hannes > -cbc > > On Wed, Mar 29, 2017 at 6:21 AM, H. Hirzel <[hidden email]> wrote: > >> What is the difference to the existing method ? >> >> center: centerPoint extent: extentPoint >> "Answer an instance of me whose center is centerPoint and width >> by height is extentPoint. " >> >> ^self origin: centerPoint - (extentPoint//2) extent: extentPoint >> >> Is / vs // worth the effort? >> >> On Wed, 29 Mar 2017 00:18:24 0000, [hidden email] >> <[hidden email]> wrote: >> > A new version of Graphics was added to project The Inbox: >> > http://source.squeak.org/inbox/Graphics-cbc.372.mcz >> > >> > ==================== Summary ==================== >> > >> > Name: Graphics-cbc.372 >> > Author: cbc >> > Time: 28 March 2017, 5:18:09.019402 pm >> > UUID: 7b9783b1-87c5-3549-ac32-42acd6abcb12 >> > Ancestors: Graphics-eem.371 >> > >> > Added method to allow creating a rectangle based on teh center of the >> > rectangle. >> > >> > =============== Diff against Graphics-eem.371 =============== >> > >> > Item was added: >> > + ----- Method: Rectangle class>>exactCenter:extent: (in category >> 'instance >> > creation') ----- >> > + exactCenter: centerPoint extent: extentPoint >> > + "Answer an instance of me whose center is centerPoint and width >> > + by height is extentPoint. " >> > + ^ self origin: centerPoint - (extentPoint / 2) extent: >> > extentPoint >> > + ! >> > >> > >> > >> >> > |
Re: The Inbox: Graphics-cbc.372.mcz
|
|
Hi Hannes,
On Wed, Mar 29, 2017 at 8:45 AM, H. Hirzel <[hidden email]> wrote: Hi Chris, How do you know? Just because Rectangle and Point are used in the graphics subsystem does not mean that their use is limited only to that domain. There is nothing that prevents one from creating, for example, 0.25 asPoint extent: 1 => 0.25@0.25 corner: 1.25@1.25 I think Chris' method makes perfect sense. This is a polymorphic system; the abstractions within it are broadly applicable. The kind of thinking which restricts the system, such as adding methods that logically belong to SequenceableCollection to, say, String, simply because the programmer wanted a String method and didn't think about generality, is at best regrettable. > A better question is should I be using Rectangle for this. Maybe we should Why not the other way around? Add IntegralRectangle and have it specialize Rectangle.
_,,,^..^,,,_ best, Eliot |
|
|
Hi. On Wed, Mar 29, 2017 at 12:58 PM, Eliot Miranda <[hidden email]> wrote:
<snip>
I've been guilty of this in the past, and probably will in the future, but I try not to be.
Let me re-state what I think you are saying, and please correct me if I am wrong. Make Rectangle more generic, and for instance, have the method #center:extent: use #/ instead of #//. Then, have a new class, IntegralRectangle, that re-implements that method and sends #// to ensure that the extents are integral. (and in general do whatever else is needed to relax Rectangle, and tighten up IntegralRectangle). Right? If so, the main reason not to do proceed is that Rectangle is used extensively in the system for today, and we'd have to replace those uses with IntegralRectangle, not to mention all of the indirect uses (such as #corner: that you used above, and make variants creating IntegralRectangle and generic Rectangle, or otherwise resolve those ambiguities). That said, I'm all for it. I'd like a less strict Rectangle for, well, Rectangle uses. As a side note, if you look up Integral Rectangle in Google, you'll fine lots of discussions that have nothing to do with this question. But Integral (integer) and Rectangle make perfect sense here in any case. -cbc |
Re: The Inbox: Graphics-cbc.372.mcz
|
|
Hi
Eliot's argument is convincing for me and I suggest that the change should be added to the trunk as is. Adding another subclass just because of one method does not make sense though. --Hannes --------------------------------------------------------------------------------------------------------------------------------- Name: Graphics-cbc.372 Author: cbc Time: 28 March 2017, 5:18:09.019402 pm UUID: 7b9783b1-87c5-3549-ac32-42acd6abcb12 Ancestors: Graphics-eem.371 Added method to allow creating a rectangle based on teh center of the rectangle. =============== Diff against Graphics-eem.371 =============== Item was added: + ----- Method: Rectangle class>>exactCenter:extent: (in category 'instance creation') ----- + exactCenter: centerPoint extent: extentPoint + "Answer an instance of me whose center is centerPoint and width + by height is extentPoint. " + ^ self origin: centerPoint - (extentPoint / 2) extent: extentPoint + ! On 3/29/17, Chris Cunningham <[hidden email]> wrote: > Hi. > > On Wed, Mar 29, 2017 at 12:58 PM, Eliot Miranda <[hidden email]> > wrote: > >> Hi Hannes, >> >> On Wed, Mar 29, 2017 at 8:45 AM, H. Hirzel <[hidden email]> >> wrote: >> >>> Hi Chris, >>> >>> On 3/29/17, Chris Cunningham <[hidden email]> wrote: >>> > Hi, >> >> <snip> > > >> The kind of thinking which restricts the system, such as adding methods >>> that logically belong to SequenceableCollection to, say, String, simply >>> because the programmer wanted a String method and didn't think about >>> generality, is at best regrettable. >> >> I've been guilty of this in the past, and probably will in the future, >> but > I try not to be. > >> >> >> >> > A better question is should I be using Rectangle for this. Maybe we >>> should >>> > create a 'TrueRectangle' class or something similar so that we can >>> actually >>> > talk about and share what can really be done with rectangles, instead >>> > of >>> > the 'ScreenRectangle' that we have today called Rectangle. >>> >> >> Why not the other way around? Add IntegralRectangle and have it >> specialize >> Rectangle. >> >> > Let me re-state what I think you are saying, and please correct me if I am > wrong. > > Make Rectangle more generic, and for instance, have the method > #center:extent: use #/ instead of #//. > Then, have a new class, IntegralRectangle, that re-implements that method > and sends #// to ensure that the extents are integral. > (and in general do whatever else is needed to relax Rectangle, and tighten > up IntegralRectangle). > > Right? > > If so, the main reason not to do proceed is that Rectangle is used > extensively in the system for today, and we'd have to replace those uses > with IntegralRectangle, not to mention all of the indirect uses (such as > #corner: that you used above, and make variants creating IntegralRectangle > and generic Rectangle, or otherwise resolve those ambiguities). > > That said, I'm all for it. I'd like a less strict Rectangle for, well, > Rectangle uses. > > As a side note, if you look up Integral Rectangle in Google, you'll fine > lots of discussions that have nothing to do with this question. But > Integral (integer) and Rectangle make perfect sense here in any case. > > -cbc > |
Re: The Inbox: Graphics-cbc.372.mcz
|
|
+1
It makes sense to me also. I'll move it from inbox to trunk. Dave On Thu, Mar 30, 2017 at 06:51:08AM +0200, H. Hirzel wrote: > Hi > > Eliot's argument is convincing for me and I suggest that the change > should be added to the trunk as is. > > Adding another subclass just because of one method does not make sense though. > > --Hannes > > --------------------------------------------------------------------------------------------------------------------------------- > > Name: Graphics-cbc.372 > Author: cbc > Time: 28 March 2017, 5:18:09.019402 pm > UUID: 7b9783b1-87c5-3549-ac32-42acd6abcb12 > Ancestors: Graphics-eem.371 > > Added method to allow creating a rectangle based on teh center of the rectangle. > > =============== Diff against Graphics-eem.371 =============== > > Item was added: > + ----- Method: Rectangle class>>exactCenter:extent: (in category > 'instance creation') ----- > + exactCenter: centerPoint extent: extentPoint > + "Answer an instance of me whose center is centerPoint and width > + by height is extentPoint. " > + ^ self origin: centerPoint - (extentPoint / 2) extent: extentPoint > + ! > > On 3/29/17, Chris Cunningham <[hidden email]> wrote: > > Hi. > > > > On Wed, Mar 29, 2017 at 12:58 PM, Eliot Miranda <[hidden email]> > > wrote: > > > >> Hi Hannes, > >> > >> On Wed, Mar 29, 2017 at 8:45 AM, H. Hirzel <[hidden email]> > >> wrote: > >> > >>> Hi Chris, > >>> > >>> On 3/29/17, Chris Cunningham <[hidden email]> wrote: > >>> > Hi, > >> > >> <snip> > > > > > >> The kind of thinking which restricts the system, such as adding methods > >>> that logically belong to SequenceableCollection to, say, String, simply > >>> because the programmer wanted a String method and didn't think about > >>> generality, is at best regrettable. > >> > >> I've been guilty of this in the past, and probably will in the future, > >> but > > I try not to be. > > > >> > >> > >> > >> > A better question is should I be using Rectangle for this. Maybe we > >>> should > >>> > create a 'TrueRectangle' class or something similar so that we can > >>> actually > >>> > talk about and share what can really be done with rectangles, instead > >>> > of > >>> > the 'ScreenRectangle' that we have today called Rectangle. > >>> > >> > >> Why not the other way around? Add IntegralRectangle and have it > >> specialize > >> Rectangle. > >> > >> > > Let me re-state what I think you are saying, and please correct me if I am > > wrong. > > > > Make Rectangle more generic, and for instance, have the method > > #center:extent: use #/ instead of #//. > > Then, have a new class, IntegralRectangle, that re-implements that method > > and sends #// to ensure that the extents are integral. > > (and in general do whatever else is needed to relax Rectangle, and tighten > > up IntegralRectangle). > > > > Right? > > > > If so, the main reason not to do proceed is that Rectangle is used > > extensively in the system for today, and we'd have to replace those uses > > with IntegralRectangle, not to mention all of the indirect uses (such as > > #corner: that you used above, and make variants creating IntegralRectangle > > and generic Rectangle, or otherwise resolve those ambiguities). > > > > That said, I'm all for it. I'd like a less strict Rectangle for, well, > > Rectangle uses. > > > > As a side note, if you look up Integral Rectangle in Google, you'll fine > > lots of discussions that have nothing to do with this question. But > > Integral (integer) and Rectangle make perfect sense here in any case. > > > > -cbc > > > |
Re: The Inbox: Graphics-cbc.372.mcz
|
|
In reply to this post by cbc
It strikes me that a more generic Rectangle would - not necessarily have a position - not necessarily be orthogonal to Cartesian
axes On 3/29/17 5:54 PM, Chris Cunningham
wrote:
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |