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

[Benjamin G]

On Mon, Dec 4, 2017 at 1:45 PM, Nick Keets via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> Some people are big fans of dynamic behavior and this feature will make
>> it much easier to write code in that style.  They will do it without
>> feeling malicious or considering this to be abusive, considering it to be a
>> legitimate style preference.  I wouldn’t be surprised to see people develop
>> mixins that implement the subscript using mirror and other future
>> reflection capabilities without considering that to be abusive (I would
>> almost be surprised if this *didn’t* happen).  Requiring some kind of
>> usage site annotation would both discourage this and help anyone who walks
>> into a such a code base to understand what is going on.
>>
>
>
> I really don't understand this fear of metamorphosis. People could also be
> using emoji for all their variables. So what? Let them do it!
>
> Are you afraid that this kind of code will eventually become idomatic
> Swift and soon all the good 3rd party libraries will be written like this?
> If yes, that means that Swift has failed as a language, people really
> wanted another Javascript. If not, what's the harm? Maybe eventually people
> doing this will realize that "proper" Swift is better. Or not.
>

Unless DynamicLookup is used to circumvent every compiler warning or errors
thrown at you by the language because your design is unsound. Something
like "ho, yeah swift generics and protocols aren't really working fine
together for your case, but just make everything DynamicLookupable and
you'll be all set". Or "This JSON document has a really complex schema.
Let's just not specify anything, and call the fields like this, you won't
even feel any difference anyway".

The more i think about this proposal, the less i actually understand its
purpose.

1_ From what i understood from this discussion (please correct me if i'm
wrong) python code is already callable from swift right now, without any
modification to the compiler, but then the syntax to *some* very generic
python function would just not be really pretty. If it's just library
calls, we could just wrap those calls into pretty functions for our needs,
but then :
2_ There are some python developers that hate python and would like to jump
ship and start developing in Swift because of ? ( here, i suppose things
like code completion, or anything "compile time", because that's the only
part where swift would have an edge against python regarding data libs,
since python is just glue code around high performance C). And we want to
make it pretty for them.
3_ So let's make swift more dynamic and disable compile-time checks for
what those guys are going to use ??

Which means we're adding dynamic , runtime checks to a compile-time checked
language, to help people moving out of a dynamic language...  There's
something in that logic that i fail to understand. Once again, if i can
only bring one useful personal experience, people in my field (regular
server-side development) are moving away from python to go. And believe me
the reason has very little to do with syntax or power in the type system
and more with good concurrency, fantastic compile time, fantastic stdlib,
and "good enough" syntax for the general cases.




>
> Right now there are a lot of people writting Swift in an Objective-C
> style. e.g. using classes when they should have used structs, using
> inheritance when they should have used protocols. Should we add some
> language feature to stop them?
>







>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171204/dc303da3/attachment.html>