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

Tue Dec 5 15:43:16 CST 2017

> I tried to recreate a dynamic BaseDynamicObject based on dictionaries and your new protocols, but it's pretty hard without the finished implementation (i will try to recompile swift using your pull request wheneve i got the time, if i feel people are sincerely interested).

Not sure how relevant it is for the conversation but for cases like
this it maybe would be interesting to provide a swift toolchain from
the branch that can be easily used in Xcode to play around with it?
Now that an implementation is required for proposals this doesn't seem
that far fetched and it would allow the community to play a little
before deciding :)

For the rest of the conversation, I also have concerns on this being
misused and polluting our beloved language. And yeha, we have +, array
subscripting and fatalErrors that can be as bad but for some reason
(and yeha, we're just talking about feelings not real data so this is
noise, sorry for that) it's not really an issue in the real world. For
the AnyObject part I really don't see the argument there as I think I
don't really see it on App development and is just to interoperate
with a language available in Apple platforms, so it a really special
case that a lot of the community doesn't even use, specially when
people uses Swift in more platforms.

That said, for the ones that mention that we need to add special
syntax to make the possible failure of this calls I would argue that
the proposal already gives you a way to do it. When implementing a
bridge you can simply make your subscript throw or return optionals,
up to you. Also by not allowing conformance in extensions we avoid
weird issues (but i don't see a reason to use a superclass for that).

So yeha, in summary, I really like the proposal, specially with all
the changes that have been happening in the past few days. I'm still a
little afraid that this endsup resulting in a bad movement, but I
haven't agreed with others things accepted in evolution and nothing
has happened yet ¯\_(ツ)_/¯ Also, I love to see Swift getting more and
more powerful, and this is definitely a big deal.

these are my thoughts, thanks Chris for the proposal and the rest for
the great conversation ^^

On Tue, Dec 5, 2017 at 11:48 AM, Benjamin G via swift-evolution
<swift-evolution at swift.org> wrote:
>
>
> On Tue, Dec 5, 2017 at 4:30 AM, Chris Lattner via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> > On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution
>> > <swift-evolution at swift.org> wrote:
>> >> The first one, has no static type info, no compile time checking, it's
>> >> not self documenting, no type inference so people will be forced to use a
>> >> dynamic reference at the call site to store the result, leading to more type
>> >> loss, and all this spirals down.
>> >> I'm already starting to fear dynamic.
>> >> Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused
>> >> after all, no need to down vote me after 3 years :)
>> >
>> > From what I can gather, `dynamic` is used when declaring types, but
>> > there's no indication at call sites that what is being invoked is dynamic.
>> > And it even allows for casting basically anything to the `dynamic` type.
>> >
>> >
>> > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/dynamic
>> >
>> > So here we have a language community that was (is?) very vocal about
>> > caution when it comes to type inference with `var`, but seems to have
>> > accepted the validity of `dynamic`. This seems to show that at least one
>> > community has absorbed this sort of change (arguably a more "dangerous"
>> > version than what is being proposed here) with no real issues.
>>
>> Right.  dynamic in C# is far broader (and more “dangerous”) than what I’m
>> proposing.  That said, because there have been absolutely zero specific
>> examples of the sorts of harm DynamicMemberLookup could cause, it is
>> difficult to speculate about exactly which boogieman people are afraid of.
>>
>> > So I have a few questions:
>> >
>> > - Would it be enough to require annotation of the dynamic nature of a
>> > type at the declaration sites, if that still means the call sites aren't
>> > explicitly annotated?
>>
>> It is impossible to solve a problem if it cannot be explained in enough
>> detail to provide examples.  Personally, I don’t see the problem at all.
>>
>> > - Why do some think the Swift community would be more at risk of abuse
>> > of this feature than the C# community seems to have been?
>>
>>
>> People are making bizarre claims about what the spirit of Swift is,
>> informing me of things which are obviously not true, and ignoring the
>> evidence I present to them.  This is doubly humorous given that I have a
>> fairly good sense for the design balance and tradeoffs of existing features
>> in Swift today, along with detailed rationale for why they were added, when,
>> and all of the discussion that backed them.  I chalk this up to the fear of
>> the unknown or perhaps a mistrust for the peers these people work with.
>
>
> For what i'm concerned, let's be very clear : i do not consider my personal
> opinion to matter AT ALL compared to what people like you, who code
> compilers for a living, think. And i feel even more embarrassed
> participating in that conversation since it's about a language you invented.
> I've only done it because people in the core team said it would be
> interesting.
> Now, the only area where I may have more experience than people like you, is
> working with the average programmer, in the industry. And my personal
> experience shows that what a language doesn't enable is as important as what
> it enables (because every feature that can be abused will be, eventually and
> in ways nobody can expects).
>
> Regarding your proposal regarding the impact it could have on pure swift, i
> think it comes down to letting the developer masquerade dictionaries into
> proper structs or classes. I tried to recreate a dynamic BaseDynamicObject
> based on dictionaries and your new protocols, but it's pretty hard without
> the finished implementation (i will try to recompile swift using your pull
> request wheneve i got the time, if i feel people are sincerely interested).
> The "benevolent" purpose for doing that would be anything regarding mocking,
> proxying, mixins objects and their properties. There are various examples of
> those patterns in every dynamic languages.
>
> About C#, in which i did program a few years ago (but before dynamic was in
> the language), it already had powerful metaprogramming and introspection
> capabilities, as well as very convenient  generics and interfaces ( easier
> to work with than what swift offers today, but that was a long time ago so
> my memory may be wrong). So, in some way, the potential for abusing dynamic
> or "stringly typed" programming was a lot lower.
>
>
>
>>
>>
>> My goal is to make the design and proposal writeup as good as possible,
>> and the fear mongering about abuse has led me to add several options for
>> further narrowing the potential for abuse, including to the point of
>> requiring every new adoptee to go through the Swift evolution process for
>> review.  During the review period for DynamicMemberLookup, people who carry
>> these concerns are welcome to +1 one or more of those.
>>
>> I personally am far more interested in getting to the bottom of Doug’s
>> concerns - it isn’t clear to me what exactly his preferred direction
>> actually is, but that discussion is based on engineering tradeoffs and may
>> well lead to a change to the proposal or a complete change in direction.
>>
>> -Chris
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Alejandro Martinez
http://alejandromp.com