[swift-evolution] Anoymous Enums (Updated)

[Erica Sadun]

I think we're seeing the world through two different eyes: big programming and little programming. 
In big programming, everything is well architected, meant for re-use, well-documented, and probably
developed within a highly structured environment. In little programming, someone writes a utility here
or there, or creates a quick library that some friends can use. 

A strong programming language supports both. Not everything in Swift needs to be fully structured, fully
organized, fully realized, although these are goals that should never be fully ignored. And yes, I see the 
same potential as you for architecting out these use-cases for big projects. I also see the convenience in
offering switch-cases for small ones.

-- E

> On Feb 22, 2016, at 8:31 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> A few more off the top of my head. Any of these better?
> 
> 
> Frankly, I don't think so.
> 
>> func startService(type: [ client | server ]) { ... }
> 
> Isn't this mixing two operations into one call which are either barely related, or probably need to be parameterized with the service type?
> 
>> func pushNewContext(colorModel: [ rgba | rgb | grayscale ] ) { ... }
> 
> The context doesn't have a colorModel property?
> 
>> func animateDrawer(toState: [ closed | open | hidden ] ) { ... }
> 
> There's no self.drawerState property?
> 
>> func startRecordingAudio(quality: [ q8k | q44k | q22k ] ) { ... }
> 
> You don't pass this through to your audio file model?
> 
>> func performAlert(type: [ slidein | pop | flip ] ) { ... }
> 
> The animation isn't performed by a method on the type?
> 
>> func createPath(style: [ closed | open ] ) { ... }
> 
> There's no style property on the path you created?
> 
>> func rectifyImage(standard: [ uikit | exif ]) { ... }
> 
> Why is this one method if it has two almost completely different code paths?
> 
> This is a clever feature, but the more examples I see, the more convinced I become that every use smells of poorly structured code.
> 
> (Plus, it doesn't support the one place where we genuinely *do* often have an ad-hoc group of cases which is different for every call: option sets.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
>