Swift: Things I really wanted that won’t make it
ericasadun.com
Swift: Things I really wanted that won’t make it
1–10 of 54 posts
Re: Swift: Things I really wanted that won’t make it
#2Re: Swift: Things I really wanted that won’t make it
#3Re: Swift: Things I really wanted that won’t make it
#4Re: Swift: Things I really wanted that won’t make it
#5All my work is client work. There have been a bunch of occasions where I've had to work around some weirdness of an Apple SDK by creating my own subclass. I could see Apple releasing an SDK and many of the classes being @final. Then I'm stuck in a situation where I can't provide a deliverable to the specifications a client wants due to a limitation in an SDK.
That's my only fear though really. Rarely do I personally do a lot of subclassing unless I absolutely have to or it really does make sense to.
Re: Swift: Things I really wanted that won’t make it
#6Example:
with obj {
.field = abc;
xyz = .foo(12);
.method();
}
This would have several advantages:* easy for syntax completion
* can access names that are not in the innermost with-scope
* can access names at outer with-scopes using .. and ... etc
Re: Swift: Things I really wanted that won’t make it
#7Sorry but final by default is not a good idea IMO. All my work is client work. There have been a bunch of occasions where I've had to work around some weirdness of an Apple SDK by creating my own subclass. I could see Apple releasing an SDK and many of the classes being @final. Then I'm stuck in a situation where I can't provide a deliverable to the specifications a client wants due to a limitation in an SDK. That's…
Re: Swift: Things I really wanted that won’t make it
#8Sorry but final by default is not a good idea IMO. All my work is client work. There have been a bunch of occasions where I've had to work around some weirdness of an Apple SDK by creating my own subclass. I could see Apple releasing an SDK and many of the classes being @final. Then I'm stuck in a situation where I can't provide a deliverable to the specifications a client wants due to a limitation in an SDK. That's…
Apple could (and should, I think) release future SDKs that use all-final classes and require composition instead of the incredibly fragile base classes that currently make up UIKit and Foundation - they'd just add the "final" keyword.
Since UIKit is inheritance-based currently, in a final-by-default Swift, it would be imported as "subclassable", "nonfinal", or whatever. Nothing would change other than the default for newly-written Swift code.
Re: Swift: Things I really wanted that won’t make it
#9Sorry but final by default is not a good idea IMO. All my work is client work. There have been a bunch of occasions where I've had to work around some weirdness of an Apple SDK by creating my own subclass. I could see Apple releasing an SDK and many of the classes being @final. Then I'm stuck in a situation where I can't provide a deliverable to the specifications a client wants due to a limitation in an SDK. That's…
Agreed. I don't even like the fact that you can turn off subclassing, that's very un-object-oriented IMHO.
But the main problem with subclassing is: https://en.wikipedia.org/wiki/Fragile_base_class
Re: Swift: Things I really wanted that won’t make it
#10Perl 6 did some work on this. I'm not sure if it's fully supported yet, but the design docs[1] go into detail on how it's supposed to work, so it may be worth looking at.
> Method Cascades I suspect you might find disambiguating your method/attribute access easier in your "with" syntax if you make it match what swift appears to do for anonymous variables, use $0. (pardon my unfamiliarity with Swift, I may be mistaken on some obvious things).
E.g. Instead of
with let task = NSTask() {
launchPath = "/usr/bin/mdfind"
arguments = ["kMDItemDisplayName == *.playground"]
standardOutput = pipe
launch()
waitUntilExit()
}
do with let task = NSTask() {
$0.launchPath = "/usr/bin/mdfind"
$0.arguments = ["kMDItemDisplayName == *.playground"]
$0.standardOutput = pipe
$0.launch()
$0.waitUntilExit()
}
That way if you want to use some non-related variabled within the block, or the output of an attribute or method as the input of some other attribute or method, it's not ambiguous.