> On Oct 24, 2014, at 19:55 , Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On Oct 24, 2014, at 18:38 , Rick Mann <rm...@latencyzero.com> wrote:
>>
>> Oh! I think I figured out what I'm doing wrong. The typealias doesn't
>> understand local names, and that makes some sense. I can just get rid of
>> those altogether and be find.
>
> I don’t understand what you’re saying here. What are “local names”, and what
> have they got to do with the type alias? As far as I can see, you’ve simply
> left out something required.
"local names" are the names a function implementation uses to refer to
parameters. In the case of the typealias, I had copied-and-pasted it from one
of my function declarations when things were getting too unwieldy. I didn't
realize at the time that the local names become external names in a function
type declaration.
>
>> typealias SendResponseFunc = (inResp: NSData?, inRespHeaders:
>> HTTPHeaders?) -> ();
>>
>>
>> func
>> waitForSweep(inSendResponse: SendResponseFunc)
>> {
>> inSendResponse(nil, nil); // Missing argument labels
>> 'inResp:inRespHeaders'
>> }
>>
>> I find this "expressiveness" to be overly verbose.
>
> Can you point to the expressiveness in “this” that you regard as verbose?
>
> It’s as if you’re complaining that you’re being forced to write something
> like this in Obj-C:
>
> [self sendWithResponse: nil responseHeaders: nil];
>
> when you’d much rather write this:
>
> [self send: nil : nil];
That's precisely it. I find Obj-C incredibly verbose, and Swift has a more
C-like function call syntax, and doesn't (necessarily) require naming all the
parameters at the call site.
> You *can* do the latter (with a suitable method declaration), of course, but
> it’s not a usual coding style. Still, I don’t recall you ever complaining
> that Obj-C “forces” you to write keywords in method signatures.
>
> Actually, Swift optimizes this from the opposite end. Corresponding to this
> declaration in Obj-C:
>
> - (void) sendWithResponse: (NSData*) response responseHeaders:
> (HTTPHeaders*) responseHeaders;
>
> which basically duplicates the keywords in the parameter variable names,
> Swift lets you eliminate the duplication:
>
> func send (response: NSData, responseHeaders: HTTPHeaders) … etc …
>
> If you want to write C-like functions without keywords, you *can* do that,
> using the “_” decoration. If you want to name your parameter variables
> something different from the keyword (“inResp” vs “response”), you can do
> that too, but both of these (slightly unusual) cases take more syntax.
That's only true in an actual function or method definition. But you can't do
that in a Tuple, even one that's part of a function typealias declaration (I
don't know if that's intentional or not). It sorta makes sense, since there's
nothing at the declaration that needs a local name. But it also means that you
can't just copy-and-paste as I did, and that the two declarations that are very
similar are actually different.
Anyway, once I realized what was going on, I was able to get the behavior I
wanted. It's not perfect, because now I have to declare my function types like
this to get some documentation in them. I want to document at the function
declaration, not at every call site.
typealias SyncRequestHandler = (/*request:*/ HTTPMessage) -> ResponseTuple;
typealias SendResponseFunc = (/*responseData:*/ NSData?,
/*responseHeaders:*/ HTTPHeaders?) -> ();
You can't prefix these names with "_" in the current compiler.
--
Rick Mann
rm...@latencyzero.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
