Yes absolutely, the feature I was looking for was a Object Mapping like protocol.
Let’s take this
let jsonCallback: HttpContentResponseBlock<Sugar.Json.JsonDocument!>! = { response in
if response.Success {
var obj = response.Content.RootObject
}
}
Http.ExecuteRequestAsJson( Url(url), jsonCallback)
If I have my custom Object to be mapped to a JSON object let’s say something like (taken from ObjectMapper library)
class User: Mappable {
var username: String?
var age: Int?
var weight: Double!
var array: [AnyObject]?
var dictionary: [String : AnyObject] = [:]
var bestFriend: User? // Nested User object
var friends: [User]? // Array of Users
var birthday: NSDate?
required init?(_ map: Map) {
}
// Mappable
func mapping(map: Map) {
username <- map["username"]
age <- map["age"]
weight <- map["weight"]
array <- map["arr"]
dictionary <- map["dict"]
bestFriend <- map["best_friend"]
friends <- map["friends"]
birthday <- (map["birthday"], DateTransform())
}
}
I would like to serialize and deserialize this object starting from the response:
var obj = response.Content.RootObject
using Sugar.Json.JsonDocument
but - in this case - I have found no doc to handle this transformations.
In general, my question would be how to handle platforms data type like NSDictionary dependencies in pure Swift projects like those ones that do import Foundation.NSDictionary, etc.
yeah and it’s easy as well to move from a data type to another mapping:
var swiftDict : Dictionary<String,AnyObject!> = Dictionary<String,AnyObject!>()
for key : AnyObject in ocDictionary.allKeys {
let stringKey = key as String
if let keyValue = ocDictionary.valueForKey(stringKey){
swiftDict[stringKey] = keyValue
}
}
So I think one could change the NSDictionary to Swift.Dictionary definitively, since mapping is 1:1.
What about NSNumber and NSNull instead, they are wrapper of Number and nil?
@mh Another question is, Sugar.Json is not automatically converted into native platform supported objects or the more closer object data type?
If I declare a method like
@mh Considering that Apple has started to provide Foundation as a Swift code base, so platform agnostic for core utilities, internationalization, and OS independence, could this be imported in Silver as a library?
Once their ABI stabilizes and we support consuming Swift libraries, yes. Note that their version of the library will probably never compile in Silver because it uses too much of their compiler magic, so it would still not be available on the other platforms, though. Only on Cocoa. Since they won’t be providing a library for .NET or Android, any time soon. ;). So. It much gained, for now, over just using the Foundation we already have from Cocoa
@mh agreed, not sure about the dependencies, it should “provide a level of OS independence” according to Apple, but I understand that they are very far to this at this time. And according to them Foundation will run on Linux including NSString, NSDictionary, NSArray, and NSSet (that we discussed before in this thread) in order to have high level semantics in the language. The interesting thing can be synthesized here:
Why not make the existing Objective-C implementation of Foundation open source?
Foundation on Darwin is written primarily in Objective-C, and the Objective-C runtime is not part of the Swift open source project. CoreFoundation, however, is a portable C library and does not require the Objective-C runtime. It contains much of the behavior that is exposed via the Foundation API. Therefore, it is used on all platforms including Linux.
I’m pretty sure that Silver/RemObject contribution could be very important to make true portable libraries.
Yes, it’s OS independent in that it has re-implementartions of everything for each OS, where needed. So Apple provides a Foundation with #ifdefs for, say, Mac, iOS and Linux. But not for .NET and for Java/Android, so their Foundation can’t be sued on .NET and Java, for example. Also, their Foundation implementation (asm their Base Library) is very low-level and won’t compile in Silver, probably.
When compiled, and once we support swift libraries, Silver all be able to use it. But that requires a usable binary to exist to start with
Well, but that won’t give Silver any ground until Foundation and libdispatch will be ported to .NET and Java, and it does seem to happen anywhere soon. I mean, since Xamarin and RoboVM leverage existing .NET and Java ecosystem it is obviously way easier for them to serve their customer base. But since you guys are targeting Swift developers - the switching costs are very high, since Apple-Swift is 95% in-house yet and Silver doesn’t yet have a solid ecosystem, we need to port a lot of stuff to Sugar and implement many more core stuff our-selves, which arguably won’t decrease time-to-market comparing to having separate Java, Swift codebases. Code-sharing is the large benefit, but it is often seen through the prism of shorter time-to-market. I really appreciate what you guys did, Silver is really awesome and I love it but it needs strong community support to build a healthy-ecosystem so that it can fit enterprise requirements, which at least requires you guys to have some certain marketing strength in order to have more exposure, so that a force of community enthusiasts will at least know about how awesome your tools are.
Another thing that comes to mind is that it will be difficult to see any solid community-based development for Sugar since it written in Oxygen/Pascal and it cannot run on apple’s swift. The only chance I can see that swift community getting involved in building Silver ecosystem, if that base library would be different from Sugar and will be written in Swift/C++ that can run build on apple’s swift. Since the whole army of these hipsters will simply won’t switch from Apple’s Xcode. So you guys might consider this, I understand your intention to leverage Sugar, since it is proud baby of your Elements eco-system. I guess writing the base library that will run on apple’s swift might be a challenge since it will be way more troublesome fitting it to Java and .NET stuff that simply doesn’t exist in Swift, but this might be a necessary tradeoff to overcome, for example we recently saw great community support for https://github.com/PerfectlySoft/Perfect that does not have dependency on apple’s frameworks.
Few mobile development shops are going to give up XCode and native Apple swift on iOS & OSX, so interoperability with Apple Swift is really important.
Once the package manager has useful stuff in it, then a silver implementation of Foundation, libdispatch, and XCTest will be crucial.
Sugar is pretty much useless because you can’t use it in Apple Swift
Because of these points we invested in writing our own cross platform library, that works in both XCode & Fire/Silver/Android Studio. This doesn’t implement Foundation, but I’m beginning to think we should have.
I would love Silver to be the default Android impl of Swift, but it’s going to have to compete with the Android native port which is going on at the moment. That’s going to be super clunky to use as will compile to native code and be usable through JNI (ugh), but will be the default option for most people because it will be in the Apple swift code base, and it will have the linux ports of Foundation, libdispatch and XCTest to (partially) run on. https://github.com/SwiftAndroid
i agree. a criss-platform base library that works in both Xcode and Silve rwoiuld be great to have. i see two potential avenues here that we are thinking about/exploring.
One would be be to have Sugar (or something like Sugar), (re)written in a way that it can either be compiled in Xcode, or ate the very least be compile into a framework that can be used on Xcode — allowing to write code against the Sugar APIs and use that code in both compilers.
The other would be to have Foundation (i.e. the version coming in Swift 3.0) build in Silver (or have an equivalent version of the framework that does), so that instead of Sugar, Foundation APIs would be available cross-platform in Silver (and Oxygene/C#, as well).
How feasible the second portion is depends a lot on what “Swift 3.0 Foundation” will look, and how nasty the code will be on the inside (for comparison: getting Apple’s ow Swift Base Library to compile in Silver and cross-platform is a compete no-go, as there code is a mess of hacks specific to internal stuff in their compiler. Which is fine of course, for such a base library). We;'ll have to see if Foundation will be “clean”, to see whether we can compile it (opposed to duplicate it).
As for Sugar being written in Oxygene — currently it is, yes, as it predates Silver. That said, we’d very much welcome contributions written in Swift. This includes new functionality but also existing functionality rewritten/converted into Swift, and existing functionality rewritten to work in Apple Swift as well.
Jon, you mentioned writing your own library that works with both compilers. Any chance you would be willing to open this up as an open source/community project that we could build one and RO could get involved in with as well, so that everyone could benefit from it, long term (e it as replacement to alternative to Sugar)?
@mh Thanks for elaborating on this. I guess it might be a big challenge to compile the Foundation to Sliver, so maybe having a Foundation-close base library might be the most feasible option, especially in the lights when apple’s Swift Toolchain will be ported to Android. @jnermut made a good point - If Silver can provide a subtle alternative to Apple base libraries, only then it can really compete. But there is still a pretty long way I guess, maybe not even a year until Apple’s port will be usable.
So you might want to check out this - https://github.com/PureSwift/SwiftFoundation
This is a pure Swift Foundation that does not depend on CoreFoundation. It obviously doesn’t compile, apart from Darwin preprocessor directives, silver seems to not eating throws, Swift’s base types like RawRepresentable and many more stuff.
I am quite new to Silver (just discovered you guys last week), but it seems that the lib is not too fat still, so there wont be too much overhead porting it to Silver I hope. I will take some time to get around Silver and Sugar cuisine and try to elaborate on that. What do you think?
We’ll look at getting that too compile, at https://github.com/remobjects/SwiftFoundation/tree/develop. Already added RawRepresentable and more missing stuff to our SwiftBaseLibrary, and workarounds for “Darwin.C”, as well as an Elements project (just OS X for now). Several compiler fixes/changes will be needed tog et this working, and we’ll look at letting the help set priorities…
Feedback & contributions will be appreciated, obviously, once we get past the most obvious issues that need changes from our end.
Any chance you would be willing to open this up as an open source/community project
Unfortunately not as it’s current form, as it’s part of a big commercial project, but I would definitely contribute to an open source effort.
I think replicating Foundation is the way to go. It’s a big project though. It’s a very ugly API, but unfortunately it’s the current standard for Swift development. I’m including libdispatch in that category too, which is used in most non-trivial swift libraries/frameworks.
I had forgotten about the PureSwift effort. I think it was started assuming that Swift on Linux wouldn’t actually include Foundation, but in the end Apple open sourced an incomplete implementation for Linux. But maybe a fork of that PureSwift lib is a good place to start on a Silver Foundation library.
I’m not sure how compatible it is with Apple Foundation though? I think they are trying to cut out some of the cruft, which might mean that you couldnt actually use libs designed for Apple Foundation.
As I understand it, Foundation on Linux is a completely separate code base to the original iOS/OSX Foundation, which isn’t open source. And just about all of the Linux impl calls straight out to C APIs - either POSIX or GLIBC. Which makes both pretty much useless for Silver besides guidance (I would have thought).
Also, as I understand it, there won’t be any major API changes in Foundation in swift 3.0: it’s listed out of scope here:
Not sure if they are going forward with removing the NS* prefixes though.
@mh thank you for the effort and consideration. I will watch closely for the update on it, looking forward to it. I think I do not have access to the silver’s private betas.
Now that Swift 5 has finally ushered in ABI stability, perhaps this thread deserves to be resurrected…
Other than utilizing precompiled binary Swift libraries, support for pulling in dependencies utilizing Swift Package Manager (SPM) package files would be most gratifying to see on the roadmap.
this needs Module Stability, which is coming in 5.1 (but alas without ANY kind of formal spec or documentation ), but we are slowly working on it for Island/Darwin and ToffeeV2, yes.
Work in progress, but since there is absolutely zero documentation on the actual ABI, and the ABI is also a total shitshow, it’s very slow going. Another month or two, I’d expect, at least.
Also, expect the “stable” ABI to break for he next release, because the way this is designed, there’s close to no way this can actually be stable long term. Apple is aiming a bazooka-sized weapon at the foot fo their developer ecosystem with what they are doing here, and it’s gonna come back to blow up in their faces, if not soon, then edition the next five or so years.
), but we are slowly working on it for Island/Darwin and ToffeeV2, yes.