Re: [swift-dev] switches versus the visitor pattern?
> On Aug 12, 2017, at 6:45 AM, David Zarzycki wrote: >> On Aug 11, 2017, at 19:21, John McCall wrote: >> >>> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev >>> 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? I agree. John. ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] switches versus the visitor pattern?
> On Aug 11, 2017, at 19:21, John McCall wrote: > >> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev >> 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? Dave ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] switches versus the visitor pattern?
> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev > 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. John. ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] switches versus the visitor pattern?
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 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 >> 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 > ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] switches versus the visitor pattern?
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 > 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 ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
