> On Nov 3, 2017, at 10:55 AM, Mike Kluev <mike.kl...@gmail.com> wrote:
>
> On 3 November 2017 at 17:23, Adam Kemp <adam_k...@apple.com
> <mailto:adam_k...@apple.com>> wrote:
>
>
> 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.
>
> please provide more details on this. i was and still using such a technique,
> so want to be prepared for those pitfalls before i actually encounter them.
1. You end up with a whole section of type aliases at the top of the file, and
as you read the file it’s hard to understand what those types actually
represent. Which methods are you actually allowed to use? What should code
completion show you? Nothing is as it seems.
2. The type alias is only useful when the naming of the methods/properties is
identical and the sequence of calls you have to make is identical, which very
often isn’t the case. You end up needing conditional compilation anyway for
cases where you only need to make a call on one platform, or where the method
you have to call is named slightly different or takes different arguments.
Out of the strategies I’ve seen used for cross-platform code this one was the
most frustrating to work with in my experience.
> 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 ...
>
> i mean this:
>
> class MyView: UIView {
> optional part Drawing
> }
>
> part Drawing of MyView { // **** forgot to include this into target
> override func drawRect(...) {
> .....
> }
> }
>
> the app compiles but doesn't work correctly.
That example doesn’t make any sense. You wouldn’t override a drawRect function
in the shared file because that function is overriding a platform-specific
function. This is exactly the use case I gave an example for. What you would do
instead is override the platform-specific draw function in a platform-specific
file and then redirect to a shared implementation that has a cross-platform
interface.
In general I would say you shouldn’t implement a protocol method for a protocol
not declared in the same file or override a method of a superclass not
explicitly mentioned in that file. That’s just a bad practice. Instead you
would put that function in the same file as the protocol or superclass is
mentioned and then, if needed, redirect to another function in another file.
Then if you leave out that file it won’t compile because you’ll be missing a
function.
Trust me, this works very well in practice. I never once ran into a bug like
that over several years of doing things this way._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
