Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic Swift

mjtsai.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Dynamic Swift

#41

Post by phink »

ebbv wrote: post #16

I don't want to call someone I don't know a bad developer, but as a general rule if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences. Not that the decisions being made are bad. Swift is not a perfect language, there's a lot of low hanging fruit (some of which is being dealt with in Swift 3), but it's lack of suppo…

Swift is not even safer than Objective C since you can pepper your code with ? and ! and get the same runtime problems.

I would even say that it is less safe as time pressure and having to spend time on such trivial things combine to make you lazy about it and just add them to keep the compiler happy.

Re: Dynamic Swift

#42

Post by [deleted] »

drewcrawford wrote: post #26
refulgentis wrote: post #8

Earlier quoted context omitted.

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the unders…

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature. From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious. One concrete example I can offer you is NSCoding, which is being…

[deleted]

Re: Dynamic Swift

#43

Post by eridius »

drewcrawford wrote: post #35
mikeash wrote: post #32

Earlier quoted context omitted.

Regarding XCTest, could you extend Mirror to provide methods as well as fields? That seems to me like it would be a more natural solution.

For what it's worth, that's my preferred solution in the long-term too. Speaking narrowly about the XCTest case: * It doesn't actually require runtime dynamism (since you have a finite number of tests that can be statically enumerated). Following the principle of least power, don't do it if you don't have to. * A runtime-dynamism-based solution would require `dynamic` sprinkled on function definitions which would be…

Honestly, determining that all methods that start with "test" are your unit tests is pretty bad. We do this because this was the most obvious solution in obj-c. A much better Swift solution is to instead use an attribute, such as `@test`, to mark test functions. This requires compiler support for now, but the long-term goal could then be to come up with a generic way of declaring and handling attributes.

Re: Dynamic Swift

#45

Post by batgar »

What's stopping Swift from using the C# dynamic keyword scheme as a starting point?

https://msdn.microsoft.com/en-us/library/dd264741.aspx

C# does an excellent job of bridging dynamism and hard types.

The use of the dynamic keyword ensures that you know you are bridging to an area where the "." is not type checked, and is strictly evaluated at runtime.

There may be too many hooks into the reflection area of C# / .NET, however that can be mitigated in other ways within the confines of Swift.

Could even have an 'if ... let' Swift scheme that attempts to conform an object to a specific dynamic protocol. Example: Define an expected interface as a protocol, then do a 'dynamic if..let cast' which will ensure that all members from the protocol are present on the Swift object.

Re: Dynamic Swift

#46

Post by Tloewald »

kylnew wrote: post #7

I think ObjC has left us with some dynamic habits we don't actually always need, particularly in all non-UI layers. I appreciate the way using Swift has me questioning just how much dynamism and mutability my programs really need. Overuse of things like setValue:forKey: and performSelector: have a bit of code smell anyway and there's no reason you can't replicate these kinds of behaviors, if you really need to, with…

It seems that (a) we need Dynamic features (introspection, dynamic dispatch) and (b) we need to use it sparingly. In short, it's a _cultural_ problem, not a technical one.

I suspect the solution is something as simple as a "DangerouslyCallMethodByName" method.

Re: Dynamic Swift

#47

Post by mahyarm »

Tloewald wrote: post #46
kylnew wrote: post #7

I think ObjC has left us with some dynamic habits we don't actually always need, particularly in all non-UI layers. I appreciate the way using Swift has me questioning just how much dynamism and mutability my programs really need. Overuse of things like setValue:forKey: and performSelector: have a bit of code smell anyway and there's no reason you can't replicate these kinds of behaviors, if you really need to, with…

It seems that (a) we need Dynamic features (introspection, dynamic dispatch) and (b) we need to use it sparingly. In short, it's a _cultural_ problem, not a technical one. I suspect the solution is something as simple as a "DangerouslyCallMethodByName" method.

you could do

  if let method = classInstance.methods[methodKey] {
    //Put some ugly method argument checker thing here
    method.execute()
  }
It would be typesafe, not dangerous, and statically typed.

Re: Dynamic Swift

#48

Post by mamcx »

ebbv wrote: post #16

I don't want to call someone I don't know a bad developer, but as a general rule if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences. Not that the decisions being made are bad. Swift is not a perfect language, there's a lot of low hanging fruit (some of which is being dealt with in Swift 3), but it's lack of suppo…

I love static typing and stronger type systems, but I'm also mainly a data dev guy (that do CRUDs and data manipulation, plus app/web development).

The big trouble with inflexibles types is that work against data manipulation. Data using maybe not, but is a mile easier to do database development in python than in F#.

My ideal setup is a strict-types first and dynamic optional, so I can do:

  row = MakeRow()
  row?first_name = "Jhon"
  row?last_name = "Doe"
  row?fullName = fun row:Row -> row?first_name + " " + row?last_name
and stuff like that...

But still keep the type system everywhere!

  fun sum(a, b:Int):Int -> a + b
Mainly, because readability. I think that is better when you can stare at a fragment of code and extract as much info as posible. Type annotations help that.

That infuriate me about F#. I do python, and in both basic code "look the same". But I hate that F# know the types of things but do not tell me! (without a IDE!) and I still need to track down the flow of code to figure out things.

Type inference must be local, imho. Or not at all...

Re: Dynamic Swift

#49

Post by jonhohle »

comex wrote: post #21
catnaroek wrote: post #19

Earlier quoted context omitted.

> It's certainly slower. That's the least of problems, since nowadays we have smart runtime systems that dynamically optimize running programs. It's not elegant, but it works. A more fundamental problem is that this approach to programming leads to brittle code, and when it breaks, it doesn't warn you until it's too late.

Actually, I feel a bit silly and maybe confused, as the 'setProperty' I mentioned at the end of my last post is... just reflection. Which Swift already has, in the form of Mirror. The only reason the Objective-C runtime is needed for that example is that Mirror apparently only allows you to get the values of properties, not set them, but that just sounds like an implementation limitation that could easily be lifted -…

A JIT for what? Both Swift and Objective-C are AOT. Objective-C offers runtime dispatch into native code, no different than calling a function pointer in C (just with a more convenient method of looking them up at runtime).

Re: Dynamic Swift

#50

Post by phink »

eridius wrote: post #43
drewcrawford wrote: post #35

Earlier quoted context omitted.

For what it's worth, that's my preferred solution in the long-term too. Speaking narrowly about the XCTest case: * It doesn't actually require runtime dynamism (since you have a finite number of tests that can be statically enumerated). Following the principle of least power, don't do it if you don't have to. * A runtime-dynamism-based solution would require `dynamic` sprinkled on function definitions which would be…

Honestly, determining that all methods that start with "test" are your unit tests is pretty bad. We do this because this was the most obvious solution in obj-c. A much better Swift solution is to instead use an attribute, such as `@test`, to mark test functions. This requires compiler support for now, but the long-term goal could then be to come up with a generic way of declaring and handling attributes.

It's not just methods starting with test, it's methods starting with test in a subclass of Test. It's a simple, working convention. Conventions are good, not pretty bad.

Adding more stuff to the language only makes it more complex and requires more effort. I don't see this as a much better solution but as an over engineered one, as much of what Apple is doing these days.

Post reply on HN