[swift-evolution] Proposal: Extend CG(Rect)Geometry with center methods
D. Felipe Torres
warorface at gmail.com
Tue Dec 15 05:11:04 CST 2015
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>
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>
> 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>
>> 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> 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
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> 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
>>
>
>
--
++++++++++++++++++++++++++
Diego Torres.
Phone (Mobile Germany): +49 157 30070985
Phone (Landline Chile): +56 2 29790978
Web: dtorres.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/00acef4d/attachment.html>
More information about the swift-evolution
mailing list