I agree that partial classes would be a handy way to help split up an implementation, and perhaps also of assistance if you want really tight/clean access control within a class, using fileprivate. But this does not replace the need for stored properties in extensions.
For example (I have done this in Obj-C) if you want to add drag+drop functionality to UIView in such a way that all its subclasses automatically support it. You could add the functions and the state, such as isDraggable and dragFromParent and isDropTarget etc. Note this is just an example of a use-case, extending a class from an external library. The implementation previously discussed would use a side-allocation table pointed at from the refcount portion of the object header and the flag set to indicate the refcounts were moved inside the table (the same table would also be needed for instances with weak refs anyway). Thus only instances that actually made use of the extension stored-properties would bear the cost of additional storage. On Sat, 10 Dec 2016 at 21:48 Andrey Volodin via swift-evolution < swift-evolution@swift.org> wrote: > There is a lot of talk about stored properties in extensions. But do we > really need them? > > Instead I think we can introduce something like partial classes from C#. > It is an often case our classes go hell of a big and we have to move some > methods to dedicated extensions to increase readability. It is also an > often case that those methods have some stored properties they work with. > This is often leads to a pattern where we have all stored properties > declared in Class.swift and then we implement extensions in > Class+Something.swift files. > > I bet partial classes should only be available within one module, so you > can’t extend class from library, etc and work close to text-wide level, > just to ease the code navigation. That is also will allow some code > generation tricks, making it easy to create UI/Level designers for Swift. > (for example you can generate some methods and properties of a Scene class > in an editor and mix-in that in the user’s project.) > > Any thoughts? > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution