I agree the second is much nicer, and a lot clearer on what each of the options
does; fitImage: true is pretty clear, but fitImage: false is not, but the
ad-hoc enum is clear on both counts. That said, the questions of
interoperability are a big issue for ad-hoc enums, as either they’re too strict
which becomes inconvenient (a .Fit | .Fill working with one method but not
another) or too relaxed to be safe. Of course, in the latter case you’re
replacing a Bool, which couldn’t be more relaxed in terms of where it accepts
values from.
Still, I think in this case it would be better to fully-define an enum, as it
gives you total control over compatibility and reusability of the type, which
you can’t really with the ad-hoc form without making it overly complex.
The main type of ad-hoc enum I want to see is a union-type like so:
func someMethod(value:(Int | String)) { … }
This would basically be an ad-hoc enum where each case identifies one of the
possible types, and the value bound as that type. This works however because
there’s no ambiguity in the meaning; an (Int | String) is the same wherever you
use it, whereas a general-purpose ad-hoc enum is less clear, as an other method
might also take .Fit and .Fill values, but these may have a slightly different
meaning.
So yeah, I like the idea in principle, but I think in practice it has too many
headaches to overcome for it to be as simple as it first appears =(
> On 31 May 2016, at 17:16, Erica Sadun via swift-evolution
> <[email protected]> wrote:
>
> Here's a function signature from some code from today:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> fitImage: Bool = true
> ) -> UIImage {
>
>
> And here's what I want the function signature to actually look like:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: (.Fit | .Fill) = .Fit
> ) -> UIImage {
>
>
> where I don't have to establish a separate enumeration to include ad-hoc
> enumeration-like semantics for the call. A while back, Yong hee Lee
> introduced anonymous enumerations (and the possibility of anonymous option
> flags) but the discussion rather died.
>
> I'm bringing it up again to see whether there is any general interest in
> pursuing this further as I think the second example is more readable,
> appropriate, and Swifty than the first, provides better semantics, and is
> more self documenting.
>
> Thanks for your feedback,
>
> -- Erica
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
