-1
I love the desire for consistency in this proposal, but it brings up two issues:
1. Swift’s take on standalone functions vs member functions: As Swift has progressed, it seems to have adopted a preference (which I like) in favor of members over functions that just take arguments. I think that having “dynamicType” as a property is more consistent with this direction. I like the direction because the flow of the computation is from left-to-right. (I also have adopted the pipe operator “|>” in my programming style for the same reason.) I love this aspect of a more functional style. In fact, I would rather move “sizeof” to be a property, maybe call it “bytesize”.
2. Stratification: But there’s a deeper issue. What direction should Swift be taking for reflection? For example, there might be a useful subset of Swift for very performance-critical applications in which there is no dynamic type information. In that case, would it make sense to put “dynamicType” in a separate box? If so, the syntax could be something like “Mirror(reflecting: <someExpression>).dynamicType” where this dynamicType returned a “mirror” on the type information. I’m not advocating this alternative, but this direction has significant both pros and cons. If this is something that the Swift team wants to consider in the future, it might be better to leave “dynamicType” alone for now. (For more info, see http://bracha.org/mirrors.pdf and http://bracha.org/mirrors-oopsla04.pdf\.\)
Thank you,
- David Ungar
Agreed, dynamicType feels more like a property than a keyword and obj.dynamicType is more expressive than dynamicType(obj).
If it were to become a keyword matching sizeof, I'd suggest using "typeof" instead which is more consistent.
For me -1.
Charlie
···
On May 25, 2016, at 12:11 AM, David Ungar via swift-evolution <swift-evolution@swift.org> wrote:
-1
I love the desire for consistency in this proposal, but it brings up two issues:
1. Swift’s take on standalone functions vs member functions: As Swift has progressed, it seems to have adopted a preference (which I like) in favor of members over functions that just take arguments. I think that having “dynamicType” as a property is more consistent with this direction. I like the direction because the flow of the computation is from left-to-right. (I also have adopted the pipe operator “|>” in my programming style for the same reason.) I love this aspect of a more functional style. In fact, I would rather move “sizeof” to be a property, maybe call it “bytesize”.
2. Stratification: But there’s a deeper issue. What direction should Swift be taking for reflection? For example, there might be a useful subset of Swift for very performance-critical applications in which there is no dynamic type information. In that case, would it make sense to put “dynamicType” in a separate box? If so, the syntax could be something like “Mirror(reflecting: <someExpression>).dynamicType” where this dynamicType returned a “mirror” on the type information. I’m not advocating this alternative, but this direction has significant both pros and cons. If this is something that the Swift team wants to consider in the future, it might be better to leave “dynamicType” alone for now. (For more info, see http://bracha.org/mirrors.pdf and http://bracha.org/mirrors-oopsla04.pdf\.\)
Thank you,
- David Ungar
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution