> On Nov 3, 2017, at 10:05 AM, Mike Kluev <mike.kl...@gmail.com> wrote:
>
> On 3 November 2017 at 16:42, Adam Kemp <adam_k...@apple.com
> <mailto:adam_k...@apple.com>> wrote:
>
> If that’s the case then this wouldn’t solve one of the major use cases I
> listed for this: splitting up cross-platform classes into platform-specific
> files. The idea is that each target contains a different subset of the files.
> Consider a case where two platforms are similar enough to share some code but
> not all code. For instance:
>
>
> i think we need a better real-world example, as in this one it's probably
> easier to have "View" defined as a type alias to either UIView or NSView
> depending upon a platform and similarly define currentGraphicsContext() to be
> either UIGraphicsGetCurrentContext() or
> NSGraphicsContext.currentContext()?.CGContext depending upon a platform and
> have a single code base afterwords:
When you actually try to use that technique in a fuller example it becomes
impractical. I know because some people working on the same code base tried
that, and it was much worse. Partial classes make for a much cleaner
implementation, and they avoid conditional compilation.
I will concede that there are other techniques for cross-platform code that
might be considered even cleaner. This isn’t the only technique, and I won’t
claim that it’s the best technique, but it is a very useful technique that I
have seen used very effectively. It would be nice to be able to have it as an
option.
> having said that, yes, i can see your point. my fear is that it will be (1)
> too fragile (e.g. you have "TableViewDelegate" in the ledger and just forgot
> to include the relevant file in the target - the app compiles but then
> misbehaves,
My argument is that there should be no ledger in the first place. IMO you
haven’t made the case for that requirement.
If you forget to implement a protocol then your build will fail because either
1) you claimed to implement it and didn’t or 2) you didn’t claim to implement
it and then tried to use that class somewhere that expects an object conforming
to the protocol. This was never a problem. We have a type safe language. Even
if you come up with some corner case where this could actually happen it falls
squarely into the realm of bugs that would never ship (i.e., it will be obvious
very quickly that something is wrong).
> and (2) open for abuse.
Again, we have to trust our developers to some extent. I worked in a large
codebase with a large team of developers and not once did anyone abuse this.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
