[swift-users] It seems like we really need an #include preprocessor directive?

Rien Rien at Balancingrock.nl
Sun Mar 12 01:09:55 CST 2017


> On 11 Mar 2017, at 21:12, Edward Connell via swift-users <swift-users at swift.org> wrote:
> 
> Observations about difining an object
> 	• Structs can't inherit and classes shouldn't inherit, final concrete types should be flat

Why?
I always default to the position that we should do what works. Get the project done.
Sure sometimes we do become language lawyers, but don’t let that force you into a corner.
If you need inheritance, use it. AFAIIC OOP is a first class citizen in Swift.



> 	• Protocols need to be adopted by the final concrete type, otherwise constraint specializations aren't correctly applied
> This creates a really ugly code duplication situation when you have multiple object variants that adopt the same protocols.
> 
> The storage declaration, common initialization, common didSet, etc... for protocol member variables must be duplicated for every instance. 
> If I have 20 objects that have the same base set of 15 vars, this turns into a maintenance/bug nightmare.


What about mimicking inheritance?:

struct FooBar {
  var foo: Int
  var bar: Int
}

protocol FooBarManipulation {
  var fooBar: FooBar { get set }
  func doSomethingWithFooBar()
}


extension FooBarManipulation {
   func doSomthingWithFooBar() { … }
}


class SomeClass: FooBarManipulation {
  var fooBar: FooBar?
}

struct SomeStruct: FooBarManipulation {
  var fooBar = FooBar(...)
}


Regards,
Rien.

> 
> I noticed the use of GYB in the swift source code. 
> I don't want to involve python in anything I do, and I don't want to mess up my code/build with all that stuff.
> 
> It seems that an easy workaround would be an #include statement. 
> The boiler plate can be put in a separate file and included wherever it's needed. 
> One piece of code, one tool, one set of bugs.
> 
> Has this been considered? Or is there a better way to handle this problem.
> 
> Thanks, Ed
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users



More information about the swift-users mailing list