I am building a rather large library and I think it would be a lot cleaner if I could have the implementation for my methods and such hidden. For example, when you view the in-code documentation for standard Swift types, such as UInt64, you see things like:
With the actual implementation of the methods hidden, and only the declarations and headers shown. How can I do this with my own library?
You need to distribute your library as a precompiled binary, in which case only the public headers + documentation will be visible for consumers of your library.
For more information, you can watch the WWDC2019 video of about Binary frameworks in Swift.
There is a shortcut in Xcode to show only the interface: Control+Command+Up Arrow, but it is a little slow and doesn't hide the internal methods that not useful for the usage of the code (since only public and open interface in Swift Package can be used by outside module).
Related
Since dart is an open source language I was trying to get the implementations of dart abstract classes? for example I would like to see how dart team implemented String abstract class to see "trim()" method implementation, there is similar question here maybe but couldn't help me.
Navigating the Dart SDK repository require some experience before it gets easier. One reason is that it contains different implementation of some methods depending on the target platform (native vs JavaScript). Also, sometimes the native implementation is being done in C++ depending on if that makes more sense.
In your case, I have found the following two implementation of String.trim(). The first is used for native (Dart VM and AOT):
https://github.com/dart-lang/sdk/blob/1278bd5adb6a857580f137e47bc521976222f7b9/sdk/lib/_internal/vm/lib/string_patch.dart#L485
And the second is used when the target is JavaScript (sometimes, we can proxy methods directly to native JavaScript methods but in this case, the trim() in JS does have a different behavior from the String.trim() in Dart. This is documented above the method in the link):
https://github.com/dart-lang/sdk/blob/1278bd5adb6a857580f137e47bc521976222f7b9/sdk/lib/_internal/js_runtime/lib/js_string.dart#L263
Note about the annotations used in the first link
The internal Dart source code can often look a bit alien compared to the normal Dart code. E.g.:
#pragma("vm:recognized", "asm-intrinsic")
#pragma("vm:external-name", "String_charAt")
external String operator [](int index);
The #pragma is used tell the Dart compiler some additional information. It can e.g. be to enforce inlining of certain methods. Or as here, tell the compiler it should call a C++ method bound to an entry called String_charAt. If we make a search in the GitHub repo. we can find that method here:
https://github.com/dart-lang/sdk/blob/e995cb5f7cd67d39c1ee4bdbe95c8241db36725f/runtime/lib/string.cc#L443-L449
I am learning Swift by myself on MacOS. When following the tutorial and practicing the array function: <array_name>.sort(), I can get it executed but I always wonder how it works and what is the actual algorithm inside it.
So is there any way to check the certain function definitions?
If you want to check the declaration of the function/class, you can command-click on it. If you want the documentation, you can either option-click it or check it on the API reference page. If you want to see the implementation details of the Swift standard library, check the source code here at GitHub. If the implementation you are checking is in a non open-source APIs though, you can't quite check it.
Swift has portions of Darwin implemented, for instance, this works:
import Darwin
rand()
Where does XCode6 store the underlying include files for this? I wanted to add in scanf functionality the same way they added in rand().
If you type "rand()" in a Swift notebook, do Jump to Definition in Xcode (CMD-CTRL-J), it will take you to the Swift header for the C standard library.
I believe you can see there all the C standard library functions where Apple has provided a Swift API. But you can't see the Swift implementation, since I don't think that's supplied. I would guess it's compiled into the Swift framework.
But what you asked is where that header file is located. Here's how to find it:
Create a Swift command-line application, and use the rand() function.
Build it.
In the Report Navigator, expand all the underlying command-line build commands, to look for the paths that were passed to the compiler.
If you look at the paths in the link phase, you may find something at /Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx
.
But I don't think Swift is using a plaintext file format for the headers, and I think the headers only give you access to C's standard lib because there's also a compiled Swift wrapper layer in between, or some kind of bridging header, so it may not be easy to just add missing functions at this point.
I just created a new target for the Lite version of my app. The Lite app only uses part of a base class that I have in the main app, ie it won't need to use an option that requires it to import 4 or 5 files.
My question is, from a design perspective, what is the best way to handle this so that my Lite version can only use the part of the class that it needs? Obviously, one solution is I just import those 4 unnecessary files into Lite build phase, and just use the whole class (even the parts it doesn't need). This seems inefficient though. I know I can do an ifndef to block those files from being imported if the Lite version is running, but how do I block out the code in the class from also not being picked up by the compiler?
Would a better way just be to have my Lite version create a subclass of the Base class that only uses the options it needs? But then I believe, would I still need to import those unnecessary files?
Just a bit confused about this, first time I've ever created another target that utilizes code from the main target. Any help appreciate thanks.
Put the common/lite functionality in a super class. Heavy functionality in the sub-class.
As another answer points out, you can handle this by putting the lite functionality in a subclass and the full functionality in a superclass.
Another option is to use a single class, and add the full functionality in an Objective-C category. Essentially, you can define methods in the category to supplement – or replace – methods in the base implementation.
Unlike a subclass, however, methods defined in a category can't invoke super to get the base class's functionality. super still refers to the base class's superclass, whether that's NSObject, UIDocument, or what have you – not the implementation without the category.
The advantage is that you only have one class name, so the code which instantiates your class (or classes) doesn't need to use something like #ifdef to switch classes and #includes depending on whether you're building the lite or full version.
I read some info regarding getting .h files for undocumented API. Most of sources recommend class-dump (or class-dump-x and class-dump-z).
However it doesn't work with iPhone Security.framework. It doesn't contain Objective-C runtime information.
The only other way which I found is to use nm or otool. This will give the names of functions and disassembly for them.
Does anybody know some faster way to get undocumented functions signature than reading disassembly and trying to figure out what parameters go where and what could it be?
You mean this undocumented api, documented here..
Security.framework is not private or undocumented.
As far as headers go, installed on my harddrive in the 3.2 sdk i find:
/Security.framework/Headers/Security.h
/Security.framework/Headers/Secbase.h
/Security.framework/Headers/SecCertificate.h
/Security.framework/Headers/SecIdentitiy.h
/Security.framework/Headers/SecImportExport.h
/Security.framework/Headers/SecItem.h
/Security.framework/Headers/SecKey.h
/Security.framework/Headers/SecPolicy.h
/Security.framework/Headers/SecRandom.h
/Security.framework/Headers/SecTrust.h
As for a little reverse engineering 101, you should realise that a framework doesn't contain or in anyway have a use for header files, or function signatures. When provided they are solely for the benefit of the developer. There is no C or C++ or objective-c code in the compiled framework, only the raw machine code.
As you have seen, if objective-c was used Class-Dump can do a pretty good job of arranging objective-c symbols into something that looks like a header file, only missing type information that isn't used at runtime, so still not that useful.
If the source language was C then you are screwed. There may be a function name symbol but there is no info about arguments or return type.
There are bunch of additional undocumented API's which are not mentioned in official documentation. As example, part of them could be seen here:
http://www.opensource.apple.com/source/Security/Security-55163.44/sec/Security/