|
Plorkyeran posted:I think the C API currently just exposes the IDE support functionality, which is basically just "tokenize this string" and "tell me about whatever's at this offset". For an AST you'd have to access the guts of the implementation (for Swift Jazzy just tokenizes the file then does the equivalent of alt-clicking each token and then reconstructing the structure). Yeah, jazzy/SourceKitten is basically all I've found as reference for people using SourceKit. Mostly, as someone who worked on an Xcode alternative for most of the last year, I somehow wasn't expecting an even more uphill battle than dealing with python-lldb. edit: And obviously this is coming from someone wanting to skim the AST of a language nobody knew about 18 months ago, so take my complaints lightly, rjmccall. ultramiraculous fucked around with this message at 07:44 on Jan 5, 2016 |
# ? Jan 5, 2016 07:40 |
|
|
# ? May 14, 2024 09:26 |
|
Well there's a few other projects built on sourcekitten, but obviously they'll all just use the same bit of SourceKit functionality so they aren't very interesting.
|
# ? Jan 5, 2016 16:56 |
|
If you just want to explore the AST yourself and don't care about doing it programmatically, there are secret compiler command line flags like -print-ast. Otherwise, SourceKit patches welcome.
|
# ? Jan 5, 2016 18:10 |
|
I'm playing around with dead stripping and Swift since I'm working on something where I might be generating a large amount of code for a library but want the linker to be able to kill anything that the user doesn't actually call. Here's my problem: -dead_strip doesn't seem to work if things are declared public. I created a two-file test case to whittle it down. strip.swift has two functions: code:
code:
Here's my swiftc invocation: code:
Adding -whole-module-optimization doesn't have any effect, either. Flobbster fucked around with this message at 23:35 on Jan 11, 2016 |
# ? Jan 11, 2016 23:25 |
|
Flobbster posted:It kind of makes sense that public things wouldn't get stripped since they might be needed elsewhere in the general case, but this case is surprising since it's linking into an executable so it's not going to be linked into something else that would try to use that function. Should I expect this behavior? Is this even a Swift problem, or a limitation in the linker? I think Swift might be forcing the symbol to be emitted if it's public in a way that suppresses linker dead-stripping, as if the function was marked with __attribute__((used)). I agree that that's unfortunate in this case.
|
# ? Jan 12, 2016 02:03 |
|
Flobbster posted:It kind of makes sense that public things wouldn't get stripped since they might be needed elsewhere in the general case, but this case is surprising since it's linking into an executable so it's not going to be linked into something else that would try to use that function.
|
# ? Jan 12, 2016 04:44 |
|
rjmccall posted:I think Swift might be forcing the symbol to be emitted if it's public in a way that suppresses linker dead-stripping, as if the function was marked with __attribute__((used)). I agree that that's unfortunate in this case. Bummer, thanks. I filed SR-521 just to see if there's any chance of improving this, since it might cause code bloat problems for my use case. Plorkyeran posted:This isn't strictly true, as with great care it's possible to dlopen() mach-o executables. People who do that are jerks! (I've done this )
|
# ? Jan 12, 2016 04:52 |
|
Are you supposed to be able to override final methods that are implemented in protocol extensions? A coworker and I were playing around with a mixin-y deal and were surprised that the compiler would let a class override something finalized in a protocol extension. For example something like this seems like it shouldn't work: code:
|
# ? Jan 26, 2016 01:38 |
|
I don't know why we let you write final on things in protocol extensions.
|
# ? Jan 26, 2016 01:55 |
|
Really? It seems an at least semi-legit thing to do...?
|
# ? Jan 26, 2016 02:07 |
|
They're really not mix-ins, although I will admit they're being used that way.
|
# ? Jan 26, 2016 05:41 |
|
I have to update to 10.11 to get the latest, hopefully-non-segfaulting version of the Swift compiler? *whines*
|
# ? Jan 30, 2016 01:58 |
|
Doctor w-rw-rw- posted:hopefully-non-segfaulting Well, don't get your hopes up.
|
# ? Jan 30, 2016 03:55 |
|
rjmccall posted:Well, don't get your hopes up. Can you go over to dev tools and smack whoever broke the SourceKit notification banner? I've been getting massive numbers of crashes (especially when it involves generics and type inference) which wouldn't be so bad... except now Xcode has a ~40% chance of crashing when SourceKit crashes. I'm back to restarting Xcode multiple times per hour. Not directed at you: There also appears to be a huge impedance mismatch between SourceKit as Xcode uses it and the real compiler because I get no autocomplete in my framework unit test target (all types from the framework itself import as <<error type>> but everything compiles and runs just fine). Unfortunately trying to replicate this in a sample project failed - everything works - so there is something about larger projects or more complex dependencies that I haven't been able to diagnose. Funny enough the main app and it's unit test target don't have this problem. I haven't filed a radar because I don't have anything useful to provide besides "hurrrr broken".
|
# ? Jan 30, 2016 05:48 |
|
https://swift.org/blog/swift-api-transformation/ posted:
Good lord, this is awful. Is addLine(toPoint:) not clearly better than deleting the context outright? rjmccall, please find whoever thought the 'after' is an improvement and slap them (not a serious suggestion). I honestly cannot figure out why someone would go "oh hey, I have a good amount of context on exactly what this method should do. What a shame; we should get rid of that."
|
# ? Jan 30, 2016 19:24 |
|
Doctor w-rw-rw- posted:I honestly cannot figure out why someone would go "oh hey, I have a good amount of context on exactly what this method should do. What a shame; we should get rid of that." I agree. One of the things I actually love about Cocoa is the verbosity of the APIs, and how the method names make it completely obvious what they do and how to use them. It makes reading other people's code, or my own old code, so much less painful. This just seems like brevity for brevity's sake. I don't like it at all.
|
# ? Jan 30, 2016 20:14 |
|
well how often is it just gonna end up like path.addLineTo(nextPoint) e: counterpoint Echo Video fucked around with this message at 20:21 on Jan 30, 2016 |
# ? Jan 30, 2016 20:19 |
|
I'll be honest... I don't see the point either. I guess it removes some verbosity but I'd rather people spent time on concurrency or improved reflection support but whatever.
|
# ? Jan 30, 2016 20:41 |
|
I assume that tweaking the automatic method name conversion is not being pursued to the exclusion of things we really care about. That said, "The Great Swift API Transformation" implies much more significant things than "we changed the names of methods." I was expecting that the post would reveal something like "Cocoa methods that used to consume selectors can now consume closures" and things of that nature. The API taking full advantage of the language features.
|
# ? Jan 30, 2016 20:47 |
|
So, separate question - what's the best way for me to do SSL in a cross-platform way? I'm writing async network stuff using GCD dispatch sources + sockets directly, and I want to layer SSL atop it. GnuTLS? NSS? I know Secure Transport and Common Crypto are open-source, but I don't know whether they've gotten Swifty, so to speak. Are they candidates for either inclusion with or porting to Swift, or would export restrictions restrain that?
|
# ? Jan 30, 2016 21:18 |
|
The effort this year is to nail down a lot of things about the existing language to the point where source and binary compatibility become something we're willing to seriously discuss. That doesn't preclude language features; for example, part of why we're taking on property behaviors is specifically to figure out where we want go with that feature space and how much language/runtime support it needs. But it does mean that we have to treat these naming issues with the attention they deserve. There are things I dislike about the Great Renaming, but dropping generic, redundant labels like "object" and "point" isn't really one of them. As a meta point, I'm happy to report things like "Some developers have very strong negative reactions to removing nouns that restate argument types from method names" at the core team meetings, and I'm definitely happy to talk things through with you all here, we are an open source project now. Posting to swift-evolution and commenting on proposals are much more effective ways to shape things.
|
# ? Jan 30, 2016 22:53 |
|
rjmccall posted:There are things I dislike about the Great Renaming, but dropping generic, redundant labels like "object" and "point" isn't really one of them. rjmccall posted:As a meta point, I'm happy to report things like "Some developers have very strong negative reactions to removing nouns that restate argument types from method names" at the core team meetings, and I'm definitely happy to talk things through with you all here, we are an open source project now. Posting to swift-evolution and commenting on proposals are much more effective ways to shape things. For me, it's less about restating the types and more about losing the preposition. Take -convertPoint:toLayer:, -convertPoint:fromLayer, and -convertRect:toLayer:, for example. Sure, you could overload it so you have convert(_:, to:) and convert(_:, from:), but now you're not just removing redundancy, you're killing vital context. Using let allows you to not have to restate obvious type information, but let a = someThingThatReturnsACGPoint followed by convert(a, someLayer) is now stupidly ambiguous. convert(a, to:someLayer) is less stupidly ambiguous, but it's still ambiguous, because now there's no hint (my obtuse naming aside) that it's converting a point and not a rect. So, again, two parts make it suck: a) apparent loss of useful prepositions, and b) loss of any hint because 'let'/'var' eliminates most of the actual bad redundancy. The method names are good redundancy because they're there for context-independent readability. EDIT: and I may also be missing the point that prepositions wouldn't be removed, simply moved outside to the method name rather than being left in the parameter. I don't like this because for one thing, moving it to the method name can only really accommodate a single parameter name, and second, I value that the method names with different parameters create a much more natural grouping of similar methods. I can see the obvious counterargument, though. Doctor w-rw-rw- fucked around with this message at 23:25 on Jan 30, 2016 |
# ? Jan 30, 2016 23:21 |
|
cocoa's explicit method names were useful in a more dynamic language and time, where messaging was rarely or barely type-checked. if xcode's completion and overlays for swift have finally stabilised, the types in the function signatures will be a better guide than verbose naming ever was, and the names become redundant. this is kind of an extreme version of the anti-comment argument - names shouldn't repeat or attempt to informally specify information which can be *verifiably* encoded as types.
|
# ? Jan 30, 2016 23:34 |
|
I would certainly agree that an API that's significantly overloaded by type, particularly a conversion API, should be an exception to the general rule. I don't think it makes sense to generalize from that, though.
|
# ? Jan 30, 2016 23:42 |
|
Gul Banana posted:cocoa's explicit method names were useful in a more dynamic language and time, where messaging was rarely or barely type-checked. if xcode's completion and overlays for swift have finally stabilised, the types in the function signatures will be a better guide than verbose naming ever was, and the names become redundant. Losing the visual information takes away a tangible part of Swift's appeal to me, because it's just making it hard for me to quickly correlate things.
|
# ? Jan 30, 2016 23:43 |
|
fillWith()
|
# ? Jan 31, 2016 00:12 |
|
Doctor w-rw-rw- posted:I'l take the redundancy, because it's information I'd otherwise have to expend effort to view anyhow
|
# ? Jan 31, 2016 00:14 |
|
rjmccall posted:The effort this year is to nail down a lot of things about the existing language to the point where source and binary compatibility become something we're willing to seriously discuss. That doesn't preclude language features; for example, part of why we're taking on property behaviors is specifically to figure out where we want go with that feature space and how much language/runtime support it needs. But it does mean that we have to treat these naming issues with the attention they deserve. I don't have much to add aside from what I posted earlier, and what Doctor w-rw-rw- and Lord Funk are saying above (which I strongly agree with), but I did want to say thanks for the constructive reply, and for being super cool in this thread.
|
# ? Jan 31, 2016 00:16 |
|
I just discovered something weird, completely by accident. Apparently like class/struct properties, regular ol' local variables can have getters/setters. So you can do stupid poo poo like this:code:
code:
|
# ? Jan 31, 2016 00:34 |
|
Flobbster posted:Is this intentional? I wonder if there are any obscure and unwise tricks you can do with this. The answer is always yes. No one expects
|
# ? Jan 31, 2016 01:36 |
|
tbh going "full java"/.net is what i like about the change. i suppose reaction is going to vary by direction of entry to the language (though i was an objc programmer once in days of yore)
|
# ? Jan 31, 2016 01:47 |
|
squidgee posted:I agree. One of the things I actually love about Cocoa is the verbosity of the APIs, and how the method names make it completely obvious what they do and how to use them. It makes reading other people's code, or my own old code, so much less painful. As an opposing view, I'm burned out from the verbosity of Objective-C APIs and find it a real chore at times.
|
# ? Jan 31, 2016 03:32 |
|
Flobbster posted:Is this intentional? Yep. Other than property-behavior treatments like lazy, it's probably not the most useful/well-advised thing, but it does pretty much just fall out of the language.
|
# ? Jan 31, 2016 04:14 |
|
Toady posted:As an opposing view, I'm burned out from the verbosity of Objective-C APIs and find it a real chore at times. Agreed. I'm happy not to feel the need to add a bunch of newlines in my method calls and line up the precious colons. Most Swift calls fit nicely on one line.
|
# ? Jan 31, 2016 04:23 |
|
While on the topic of Swift language features, what is your opinion on language support for inline composition of object hierarchies? Specifically, I mean JSX-like syntax, but without necessarily implying support for XML – perhaps just something that would make a library to implement a DSL like that possible. Easy inline composition of object hierarchies is very useful for inline markup of UI components / views. Android's UI format is literally XML, but not inline whereas React's is a simple XML-like syntax. (I ask because Swift doesn't strike me as the kind of language where third party support for it would be particularly tractable, whereas an interpreted language with sourcemaps like JS does.)
|
# ? Jan 31, 2016 08:04 |
|
Doctor w-rw-rw- posted:
Scrolling through these shows 95% of uses have inline CGPoint constructor, and the remainder are generally variables with an obvious name (point, origin, etc). The proposed API changes look great.
|
# ? Jan 31, 2016 12:31 |
|
jawbroken posted:Scrolling through these shows 95% of uses have inline CGPoint constructor, and the remainder are generally variables with an obvious name (point, origin, etc). The proposed API changes look great. It sounds like the argument you're making (and what the changes are banking on) is using variable names to supply method context. What a terrible idea. fillWith(.Add) Just gonna fill this thing with some Add.
|
# ? Jan 31, 2016 15:50 |
|
I also think the point examples are a little too simplistic as lord funk shows. We're told to remove as much redundant type info and rely on inference as much as possible. string.writeTo(filePath, atomically: ...) Scanning that code 6 moths from now I am definitely not going to remember if filePath was a URI or String. If I have to fall back to hungarian notation-ish I think readability/scannability has suffered. This proposal asks more from callers in terms variable length/descriptiveness (stuff we write) in order to trim API verbosity: stuff xcode and or auto completes writes for us. If we are going to apply some linguistic tools to support interop, might as well be consistent about parameter requirement rules. Maybe there are too many edge cases for this naming? string.writeTo(URL: filePath, atomically: ...) //string.write(URL: <#url#>, automically:..) from auto complete
|
# ? Jan 31, 2016 17:00 |
|
Kallikrates posted:If we are going to apply some linguistic tools to support interop, might as well be consistent about parameter requirement rules. Maybe there are too many edge cases for this naming? I'm 100% for requiring external parameter names all of the time, if the alternative is the new brevity model.
|
# ? Jan 31, 2016 17:15 |
|
|
# ? May 14, 2024 09:26 |
|
Kallikrates posted:I also think the point examples are a little too simplistic as lord funk shows. We're told to remove as much redundant type info and rely on inference as much as possible. Right - this change just trades one kind of verbosity for another. Instead of writeToURL(filePath), I'll have code that looks like writeTo(filePathString) or writeTo(filePathURL) or whatever. Then, because this naming pattern is totally optional, I'll inevitably forget to use it at some point and write stuff that's confusing to re-read later. The existing verbose method names save me from myself, and make unfamiliar APIs and codebases easier to navigate, even if they can be annoying at times. nah thanks fucked around with this message at 17:32 on Jan 31, 2016 |
# ? Jan 31, 2016 17:26 |