[swift-server-dev] Another way of designing server side

[Jean-Daniel]

> Le 7 nov. 2016 à 10:33, Anton Mironov via swift-server-dev <swift-server-dev at swift.org> a écrit :
> 
> Hi Micheal,
> 
> Thank you for expressing your opinion. It means that we do need some kind of design guidelines.
> 
> As for your thoughts about guidelines.
> - Protocol-oriented approach lets you build safe and flexible types. It has to be put into guidelines too. But it does not compete with a functional approach much.
> - I do not like callbacks too.  But functional does not mean callbacks. Callbacks oppose to purity principle.
> - there is a problem of memory leaks in asynchronously called lambdas. Using `weak` all over the place helps to solve this, but this approach is a very fragile. I've tried to solve this problem in a library of asynchronous primitives I make.

Using strong reference to self in lambda does not imply memory leak. It depends the life cycle of your lambda.

> - functional does not mean slow. You can actually make things faster incorporating lazy evaluation and etc.
> 
> A point about streams. I think that streams must usable both ways. Neither of those ways denies another.
> 
>> On Nov 7, 2016, at 9:50 AM, Michael Chiu <hatsuneyuji at icloud.com> wrote:
>> 
>> I would like to share some of my opinion as well.
>> 
>> I agree with you that we should have some design guidelines.
>> 
>> For me personally I would prefer protocol-orientated than functional approach for the following reasons, these are just thoughts:
>> 
>> - Life cycle of objects and call back hell.
>>    - in a networking environment it is hard to guarantee if the object still exist over and over different handlers, and since we can only store closures that are escaping, we really can’t guarantee what will happen, which can lead to callbacks hell.
>>    - Retains a lot of “middle men”
>>    - callbacks hells. (For example, Node.js)
>>    - more likely to cause memory leak (If some closure is retaining its owner).
>> 
>> - Fast
>> - No need to worry about class inheritance
>> - Much easily to schedule events.
>>     - for example, if we defines the way to read from the socket as socket.read(), it guarantees we only drain the socket when we need to, instead of letting the socket to make the decision since socket itself has no knowledge of our runtime at all.
>> - Much more readable
>> - Clear separation between roles of objects
>> 
>> I think the reactive and functional approach is still necessary, but for higher level api, which I think it’s stakeholder’s job to do with their own web frameworks. Since developer will expect a callback orientated API since it is more expressive to code with. 
>> 
>> But sometimes, you might not necessarily want to drain data from the socket immediately (It never happen on me), a reactive model is easy and expressive but not necessarily powerful when we simply don’t want things to happen immediately. I think making functional programming can be danger as a guideline for building building blocks.
>> 
>> I think stick with a model with less callbacks will be much easier and safer. Nevertheless, protocol is much more powerful since we can access the methods and also the properties of an object without worry about an object retaining itself in closures.
>> 
>> I believe I’m might be a little bit off topic here and lot of thing I write can be false as well, but these are just some thoughts I have in my mind. 
>> 
>> Thanks,
>> Michael
>> 
>> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev