I’d +1 this proposal for extensions existing in the same module as the class
declaration. However, creating new properties for classes defined in other
modules would likely involve side-table lookups, and my understanding is that
it has some performance implications.
In cases where you want to extend the storage of a class, consider if maybe a
subclass is all you need.
Dan
> On Dec 18, 2015, at 11:42 AM, Nutchaphon Rewik via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I only see the benefits on this.
> We don't have to store all states in one file. States can be stored
> separately. So, we can write code in more composition style.
> We can add new states to the existing type. Not just NSObject subclass with
> associated object.
>
> protocol Incrementer{
> func increase()
> }
>
> extension Incrementer{
>
> var count = 1 // allows stored properties
>
> func increase(){
> print(count)
> count = count + 1
> }
>
> }
>
>
> > On Dec 8, 2015, at 10:51 AM, Kevin Kachikian via swift-evolution
> > <swift-evolution at swift.org
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
> >
> > I’d like to proposal to the Swift community and discuss the advantages and
> > disadvantages of adding modifiable properties to extensions (in addition to
> > the already existing computed properties, instance methods, subscripts,
> > etc.):
> >
> > extension SomeType {
> >
> > var aNewProperty: Int
> > var anotherVariable: String
> > var aThirdOne: MyStruct
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
