[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
Benjamin G
benjamin.garrigues at gmail.com
Thu Dec 7 06:59:24 CST 2017
On Thu, Dec 7, 2017 at 1:45 PM, Gwendal Roué <gwendal.roue at gmail.com> wrote:
>
> Le 7 déc. 2017 à 11:00, Benjamin G via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> Until, and if, the “resistance” presents some conceptual explanation of
>> how this could cause harm (I’m not asking for anything concrete, just a
>> logical series of events that causes a plausible problem in practice), my
>> belief is that the Swift community will see this as unwarranted fear.
>>
>
> On the server side :
> automatically generate an administration api for your model based on
> introspection. Since swift doesn't provide anything convenient, and people
> may simply try to "port" approach from python framework (like django),
> they'll resort on recreating some kind of BaseDynamicObject that you'll
> have to extend for all your base classe, using some "properties()" and
> "methods()" functions to define your properties and methods for your model.
>
> Or :
> Automatically generate a database schema based on your model. Same idea.
>
>
> The explicit harm that Chris is looking for is yet to be shown.
>
The harm isn't in generating the database schema, or the administration
api. it's in abandonning all kind of compile-time safety in your model
layer (and such by extension in almost every part of your stack) in order
to accomplish this. Dynamic language obviously don't have this concern, but
thankfully Swift isn't a dynamic language.
>
> You should not assume that everybody feels an horror thrill by reading
> such applications of dynamism. As a matter of fact, users of dynamic
> languages *live* and *enjoy* this. Python and Ruby users, obviously (Rails
> + Django), but also ours close cousins, the Objective-C developers, who
> rely on Key-Value coding or validation methods. Those use cases are, I'm
> sorry to say it, *compelling* use cases for dynamism.
>
Not sure what field you're working in, but at least on the server the
general trend toward more compile-time safety has been pretty obvious for
some time now.
>
> Ironically, "Explicit is better than implicit" is a... Python motto ;-)
>
It's also a community that used to rely on writing types annotation and
signatures in comments above functions as a best practice, before
annotations became a thing. Not sure we should take it as an example.
>
> Gwendal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/681aa1e6/attachment.html>
More information about the swift-evolution
mailing list