Switches versus the visitor pattern?

Hello,

Before I spend time creating patches, are there arguments against converting exhaustive switch statements to the visitor pattern in the Swift source base? In particular, I’m curious about switches that reason about the TypeKind enum.

Thanks,
– Dave

I’ve seen some switches over TypeKind more easily expressed as a series of if/else if statements also.

However unless you come across an ugly switch that you want to refactor while working on something else, I probably wouldn’t spend time actively seeking them out and changing them. I don’t think switching over the kind is considered a code smell in itself.

Slava

···

On Aug 11, 2017, at 2:48 PM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:

Hello,

Before I spend time creating patches, are there arguments against converting exhaustive switch statements to the visitor pattern in the Swift source base? In particular, I’m curious about switches that reason about the TypeKind enum.

Thanks,
– Dave
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Hi Slava,

Thanks. I’m not planning on seeking them out. I just want to minimize future merge conflicts with an experimental branch I’m working on. The visitor pattern helps people like me by minimizing the number of boilerplate updates a person needs to do after adding a new type to the type system.

Thanks again,
Dave

···

On Aug 11, 2017, at 18:27, Slava Pestov <spestov@apple.com> wrote:

I’ve seen some switches over TypeKind more easily expressed as a series of if/else if statements also.

However unless you come across an ugly switch that you want to refactor while working on something else, I probably wouldn’t spend time actively seeking them out and changing them. I don’t think switching over the kind is considered a code smell in itself.

Slava

On Aug 11, 2017, at 2:48 PM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:

Hello,

Before I spend time creating patches, are there arguments against converting exhaustive switch statements to the visitor pattern in the Swift source base? In particular, I’m curious about switches that reason about the TypeKind enum.

Thanks,
– Dave
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Unless you're splitting an existing type, most of the boilerplate updates are intentional — we want people to think about every case when doing the update.

John.

···

On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Hi Slava,

Thanks. I’m not planning on seeking them out. I just want to minimize future merge conflicts with an experimental branch I’m working on. The visitor pattern helps people like me by minimizing the number of boilerplate updates a person needs to do after adding a new type to the type system.

I understand. Rather than discuss this abstractly, let’s consider a concrete example: Type::transformRec() in lib/AST/Type.cpp seems like a clear candidate that could and should switch to the visitor pattern because both NominalType and ReferenceStorageType are being handled abstractly. To what extent to you agree or disagree?

Dave

···

On Aug 11, 2017, at 19:21, John McCall <rjmccall@apple.com> wrote:

On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Hi Slava,

Thanks. I’m not planning on seeking them out. I just want to minimize future merge conflicts with an experimental branch I’m working on. The visitor pattern helps people like me by minimizing the number of boilerplate updates a person needs to do after adding a new type to the type system.

Unless you’re splitting an existing type, most of the boilerplate updates are intentional — we want people to think about every case when doing the update.

I agree.

John.

···

On Aug 12, 2017, at 6:45 AM, David Zarzycki <zarzycki@icloud.com> wrote:

On Aug 11, 2017, at 19:21, John McCall <rjmccall@apple.com> wrote:

On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev <swift-dev@swift.org> wrote:
Hi Slava,

Thanks. I’m not planning on seeking them out. I just want to minimize future merge conflicts with an experimental branch I’m working on. The visitor pattern helps people like me by minimizing the number of boilerplate updates a person needs to do after adding a new type to the type system.

Unless you’re splitting an existing type, most of the boilerplate updates are intentional — we want people to think about every case when doing the update.

I understand. Rather than discuss this abstractly, let’s consider a concrete example: Type::transformRec() in lib/AST/Type.cpp seems like a clear candidate that could and should switch to the visitor pattern because both NominalType and ReferenceStorageType are being handled abstractly. To what extent to you agree or disagree?