[swift-evolution] Proposal: Extend CG(Rect)Geometry with center methods
Dave Abrahams
dabrahams at apple.com
Wed Dec 16 11:31:31 CST 2015
I don't want to shut down a productive conversation, but since this is all about changing the CoreGraphics framework I think this whole discussion may be out-of-scope for swift-evolution. What does everybody else think?
> On Dec 16, 2015, at 6:41 AM, ilya via swift-evolution <swift-evolution at swift.org> wrote:
>
> -1 on scale. Basic scale() is not clear whether center or origin is a fixed point. Other scale(...) functions presented here seem too complicated.
>
> Ditto centerOn()
>
> aspect is a bad idea as it naturally leads one to comparing floats to each other. Which is very error prone.
>
> How about we define a getter and setter for center and leave it at that?
>
> On Wed, Dec 16, 2015 at 07:28 Kenny Leung via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I also think that keeping with non-mutable versions of these methods is a lot better at keeping you out of trouble. Here’s the set that I’ve been using for a while:
>
> extension CGRect {
> public var aspect :CGFloat {get{return width/height}}
> public var isPortrait :Bool {get{return aspect < 1}}
> public var isLandscape :Bool {get{return aspect > 1}}
> public var isSquare :Bool {get{return aspect == 1}}
> public var center :CGPoint {get{return CGPointMake(midX,midY)}}
>
> public init(size s:CGSize) {self=CGRectMake(0,0,s.width,s.height)}
> public init(size s:CGSize, centeredOn p:CGPoint) {self=CGRect(size:s).centerOn(p)}
> public init(square s:CGFloat, centeredOn p:CGPoint) {self=CGRectMake(p.x-s/2,p.y-s/2,s,s)}
>
> public func centerOn(p :CGPoint) -> CGRect {return CGRectMake(p.x-width/2,p.y-height/2,width,height)}
> public func centerOn(r :CGRect) -> CGRect {return centerOn(r.center)}
> public func scale(s :CGFloat) -> CGRect {return CGRectMake(origin.x,origin.y,width*s,height*s)}
> public func scaleAround(r :CGRect) -> CGFloat {return r.aspect<=self.aspect ? r.height/height : r.width/width}
> public func scaleAndCenterAround(r :CGRect) -> CGRect {return self.scale(self.scaleAround(r)).centerOn(r)}
> public func scaleIn(r :CGRect) -> CGFloat {return r.aspect<=self.aspect ? r.width/width : r.height/height}
> public func scaleAndCenterIn(r :CGRect) -> CGRect {return self.scale(self.scaleIn(r)).centerOn(r)}
> }
>
> -Kenny
>
>
> > On Dec 15, 2015, at 3:11 AM, D. Felipe Torres via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > The problem with making those settable is the ambiguity of it.
> >
> > Say you increase the value at maxY, should the length or origin.y be increased? should they share the modification and increase both buy half?
> >
> > It is not clear the intention here.
> >
> > And then, as David said, this is CoreGraphics API which has to be suggested through Radars and we all know how likely our chances are there.
> >
> > On Sun, Dec 13, 2015 at 10:55 PM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto:jtbandes at gmail.com>> wrote:
> > I still think it might be valuable to pursue setters for all of the currently-read-only convenience properties (minX, midX, maxX, minY, midY, maxY).
> >
> > Jacob
> >
> > On Fri, Dec 11, 2015 at 1:17 PM, D. Felipe Torres <warorface at gmail.com <mailto:warorface at gmail.com>> wrote:
> > Using the mid properties wouldn't help much as they are the middle of the bounds (origin + length/2) and because it's a derived value from two different structures, its not clear which structure you want to modify.
> >
> > Either way, after thinking more about it, there is too much ambiguity to the details of this. The intent is not always clear and looking into the other functions, they all stand on their own. A CGRect doesn't have any sense of hierarchy.
> >
> > It only appears when you have layers/views (and those do have a way of setting the center because the relationship/hierarchy is well defined).
> >
> > I don't see any more reason to pursue this proposal.
> >
> >
> > On Fri, Dec 11, 2015 at 7:29 AM, Jacob Bandes-Storch <jtbandes at gmail.com <mailto:jtbandes at gmail.com>> wrote:
> > Would it make sense to achieve the same thing by giving midX and midY setters (they currently only have getters)?
> >
> > I'm don't think I like the idea of tying down any CGRect extensions to a "parent" rect, but saying "rect.midX = parent.midX" is pretty simple & clear.
> >
> > Jacob
> >
> > On Thu, Dec 10, 2015 at 6:17 AM, D. Felipe Torres via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > One of the task that is performed often is center a frame with respect to it's parent.
> > The code for this is short and simple:
> >
> > rect.origin.x = (rect.width-parent.width)/2 // or...
> > rect.origin.y = (rect.height-parent.height)/2
> >
> > ## Current Problems
> >
> > - It is very easy to get it wrong and confuse X or Y and their length associations.
> > - Because this code is often found in a layout method, several other rect variables may be defined in the scope which makes it easier to mistake one variable with another if their names are close (and you are used to autocomplete)
> > - And finally but most importantly, while the equation here is simple, one must parse it and understand it and is not a very swifty approach.
> >
> > ##Proposed Additions
> >
> > 2 (actually 4) extensions in CGGeometry to CGRect:
> >
> > extension CGRect {
> > public func centerX(parentRect: CGRect) -> CGRect
> > public mutating func centerXInPlace(parentRect: CGRect)
> > public fun centerY(parentRect: CGRect) -> CGRect
> > public mutating func centerYInPlace(parentRect: CGRect)
> > }
> >
> > This extension allows very easily (and verbally) center a rect in respect to a parent.
> >
> > I'm pretty sure there are other pretty useful extensions that can be added to CGGeometry as well but this one I think is basic and pretty important.
> >
> > --
> > ++++++++++++++++++++++++++
> > Diego Torres.
> > Web: dtorres.me <http://dtorres.me/>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
> >
> >
> >
> >
> > --
> > ++++++++++++++++++++++++++
> > Diego Torres.
> > Phone (Mobile Germany): +49 157 30070985
> > Phone (Landline Chile): +56 2 29790978
> > Web: dtorres.me <http://dtorres.me/>
> >
> >
> >
> >
> > --
> > ++++++++++++++++++++++++++
> > Diego Torres.
> > Phone (Mobile Germany): +49 157 30070985
> > Phone (Landline Chile): +56 2 29790978
> > Web: dtorres.me <http://dtorres.me/>
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/aae3c2a8/attachment.html>
More information about the swift-evolution
mailing list