> On Jul 19, 2016, at 11:37 AM, L. Mihalkovic via swift-evolution
> <[email protected]> wrote:
>
>
>
> Regards
> (From mobile)
>
> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>>
>> Sent from my iPhone
>>
>>> <off-topic>
>>> Cocoa currently hides the boilerplate for all of these wonderful constructs
>>> behind amazingly effective runtime acrobatics. This fits perfectly into
>>> Objective-C, and it also works very well in Swift. But such features could
>>> be in better harmony with Swift's unique set of language constructs if
>>> their boilerplate was hidden behind amazingly effective **compile-time**
>>> acrobatics instead.
>>>
>>> Such compile-time acrobatics are hard to perform today, and it is possible
>>> that the ability to create such systems will forever remain an advanced
>>> skill, just like forging runtime magic requires advanced skills in
>>> Objective-C.
>>
>> ... rantish...
>>
>> I am still not convinced that even the best compiler can fully replace what
>> a powerful runtime can provide no matter the acrobatics you put in in terms
>> of compiler introduced utility code/constructs or the code analysis efforts
>> you can put in at compile time
>
> That is a fact back by some interesting papers. By it is also true that one
> cannot always be used in place of the other.
While it is true that the compiler cannot fully replace everything, it can help
with many types of errors that are hard to catch at runtime.
I’ll reiterate this again: this proposal does *not* prevent Swift from building
language mechanism to allow for this type of behavior though. The fact is,
Swift APIs are heavily value or value semantics so the lack of inheritance on
classes is not going to be the primary reason you cannot monkey patch something.
What this proposal does say is this: there is no “safe” way to achieve this
type of behavior that the API authors either intentionally left out or left out
because of an omission.
If you are subclassing a class in Swift, under this proposal, you can be sure
of one thing: the author explicitly made it so you’d be able to. We can argue
if they did so with diligence, but that’s mostly immaterial to the discussion.
The fact is, in order to allow monkey patching, Swift is going to need to
answer many questions that it still has yet to answer, such as how reflection
is really going to work. However, with these more restrictive defaults, it’s
possible to extend the language to provide runtime monkey patching that can be
more easily audited both in source code and at runtime. Instead of API authors
just seeing crashes in their libraries and not realizing that someone swizzled
a method, we would now be able to mark who did the swizzling and which
functions were actually swizzled.
An example of how this *could* look would be something like this:
struct Person { /* This is defined in module A */
// a bunch of fields
var birthDate: Date { get set }
func calculateAge() -> Int { return 12; }
}
Obviously there is a bug in `calculateAge`. How could we fix it? Well, in your
app framework (or some other target as needed) as we don’t have the ability to
fix module A directly:
extension Person {
@replaceMethodImplementation func calculateAge() -> Int { /* better
implementation */ }
}
This would require support within the Swift language and tooling. For one, we’d
need the non-optimized code to be distributed so that code within module A used
this new implementation of `calculateAge`. However, this is the direction I’d
much rather see Swift go. The ability to annotate code properly as monkey
patches so we can audit them, track them, version them, and identify them
clearly both at compile time and runtime.
I’m all for Swift getting the right underlying model. After that, we can
address a better way to provide the necessary means to monkey patch and change
behavior, but first the fundamentals need to be nailed properly.
-David_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
