[feedhenry-dev] Let's talk about Swift: async completion closure

Corinne Krych corinnekrych at gmail.com
Fri Feb 26 14:00:54 UTC 2016


On 26 February 2016 at 12:23, Máté Rácz <mracz at redhat.com> wrote:

> Hi Corinne,
>
> Somewhat unrelated, I always wondered why the ObjC API followed the JS API
> so closely with blocks, instead of a more idiomatic syntax based on
> protocols and delegates could possibly be more obvious for the end-users,
> similar to how NSURLConnection is used. (I see there is an
> FHResponseDelegate already, but it is only used internally by FHAct.)
>

As FHAct as been deprecated for quite a while, this would be out of Swift
SDK 4.x and therefore there will be no Delegate any more.
Indeed it will narrow down the usage.


> If we changed the ObjC API that way, would it narrow down the choices for
> the best syntax for the Swift API? The client code would look very much
> like Summers' Java example, and a few indentation levels could be spared,
> compared to using blocks.
>
> Kind regards,
> Máté
>
> On Thu, Feb 25, 2016 at 5:00 PM, <feedhenry-dev-request at redhat.com> wrote:
>
>>
>> @summers That would go even deeper in FRP.
>> We should list it as:
>> S4: More reactive way
>> I don't have code snippet for it but i'll do some.
>> btw all the other code snippets comes have an "trial" implementation [1].
>> pro:
>> Rx way fits for asynch data stream
>> con:
>> A bit far from the other Java/JS/C# existing syntax
>>
>> For the initial Swift SDK, I'd stick to S1 to be in sync with other
>> language SDK.
>> But I see where you're coming from Summers and I like the discussion. Let
>> me come back to you with some Swifty code snippets.
>> ++
>> Corinne
>>
>>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20160226/2968c535/attachment.htm>


More information about the feedhenry-dev mailing list