> On Dec 7, 2017, at 12:38 AM, Letanyan Arumugam via swift-evolution > <swift-evolution@swift.org> wrote: > > My fear is that a design pattern around dynamic members and calls arise that > is used to bypass the perceived initial annoyance of Swifts type system from > new developers that come over to Swift and are now starting to try and go > native. They have no reason to think about their conforming types as > something that might fail because they’re using it to model behaviour that > they’re used to (good or bad). I don’t see why it’s so bad to remind people > that these conformances should be failing and only in rare cases should you > ever have a dynamic member lookup that is fine to ignore all failing lookups. > > People coming from JavaScript could perceivably make dictionaries conform. > And later JSON, database, file and basically all resource API’s would follow. > > Why would all of this happen rather than people behaving the way current > Swift community members behave? > Because I worry that by bringing in people from other languages that a new > learning path is created. One where you start by learning your language > interoperating with Swift. And then pick up other Swift features as you go > along using your Python API for example. This would create a disparate Swift > community.
When I began writing Python, I initially named all my variables in camel case. And when I used the Subprocess module, I was passing return codes throughout my code base like it was bash. Even though I didn't know what was idiomatic in Python at that time, I could still sense a code smell in what I was writing. I soon learned that snake case was the standard, so I updated my code. And eventually I learned how to use exceptions and I refactored my code to use them instead of return codes. I doubt that this is unusual when coming to a new language with previous experience in other languages. It seems inevitable, and a normal process for becoming familiar with the idioms of a certain language community. I don't think we need to be so fearful of the community fracturing if people from a dynamic language background come to Swift and initially use those idioms. It will always be more burdensome to do things in a non-idiomatic way, and over time people will learn how to write idiomatic Swift. Also, since this is an expert-level feature, I highly doubt that newcomers to Swift will be writing their own types that adopt the DynamicMemberLookup or DynamicCallable protocols. They'll simply be using existing bridges to the dynamic language they want to interact with. And if expert Swift users find a legitimate use case for this beyond dynamic language interop, I don't think that's necessarily a bad thing if it helps them solve their problem.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
