[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Benjamin G benjamin.garrigues at gmail.com
Thu Dec 7 08:11:18 CST 2017


On Thu, Dec 7, 2017 at 2:37 PM, Gwendal Roué <gwendal.roue at gmail.com> wrote:

>
> Le 7 déc. 2017 à 13:59, Benjamin G <benjamin.garrigues at gmail.com> a écrit
> :
>
>
>
> 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.
>
>
> Yes, yes, but this has been said dozens of time already in this thread.
> Chris's question is *how*, not *what*. It's much harder to answer, I agree.
>

I think i answered that question many times as well (by masquerading
dictionaries as regular classes), but if what i'm saying is simply
impossible because of Swift type system even with the new proposal, i'd
rather people tell it to me than ask the same question over and over..


>
>  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.
>
>
> I'm not sure you really care about my answer.
>
> Gwendal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/390e2f4f/attachment.html>


More information about the swift-evolution mailing list