[swift-evolution] Proposal: Extend CG(Rect)Geometry with center methods

Marc Knaup marc at knaup.koeln
Sun Dec 13 16:06:27 CST 2015


I'm fine with them having no setters.
I'm not fine with that we cannot add them through extensions.

For example I'd love to add a setter for the properties .width and .height.
But for now Swift does not allow adding a setter to an existing read-only
property through extension.

We can shadow the whole property be redefining it in an extension.
Unfortunately this breaks when using the (public) extension from another
module due to ambiguity. Swift doesn't know what property it should use:
the original one or the one from the extension.
https://github.com/fluidsonic/JetPack/blob/a3c321770854e35e886f1e06915ae86f782164b9/Sources/extensions/CoreGraphics/CGRect.swift#L215



On Sun, Dec 13, 2015 at 10:55 PM, Jacob Bandes-Storch via swift-evolution <
swift-evolution at swift.org> 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
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/a5e02672/attachment.html>


More information about the swift-evolution mailing list