On Jan 24, 2018, at 4:17 PM, Ben Kennedy <[email protected]<mailto:[email protected]>> wrote:
On Jan 24, 2018, at 3:54 PM, Jens Alfke <[email protected]<mailto:[email protected]>> wrote: When there are a lot of optional properties for creating an object, it gets awkward to stuff all of them into one constructor/initializer method, so you create an object to hold the properties and then pass that to the constructor. I agree with the principle, and am on board with the notion of a configuration object. But having to chain together a pile of methods to populate it, rather than simply exposing properties, feels needlessly unwieldy in my opinion. Perhaps it's is a known issue, but the examples currently shown at https://url.emailprotection.link/?at5deUC_Tu3W-ZIIVdGCs1A9ZdNafh6GrLbBKCNkHC1UWV3cfBQQuBy5ij3LUHc8FHg9yCo7duB-SdiX7LE3Bw13CZ3bLtk5fKuoK72Kq2hc5sfLXWlme5hQmRQq8NcGb don't work. For example, to set up a replicator, it seems I'm forced either to use the method-chaining builder pattern previously discussed, or else use the "CBL-" named counterparts: let config = ReplicatorConfiguration(database: cblDatabase, target: URLEndpoint(url: url)) // fails; no initializer available for ReplicatorConfiguration let config = CBLReplicatorConfiguration(database: cblDatabase, target: CBLURLEndpoint(url: url)) // works I'm a little confused as to why the CBL-named classes and the non-CBL (Swift-named) classes are even available. (It's a Swift-only project so far, and I've imported CouchbaseLiteSwift via CocoaPods. I would have though that bridging would have removed a layer of the redundancy, but admittedly I'm not too expert in ObjC/Swift bridging.) Currently when using the Swift API, please do use the CBL-named classes as those are the objective-c API. This is a known issue<https://github.com/couchbase/couchbase-lite-ios/issues/1646> that the Objective-C headers are also visible when using Swift API. We have written the Swift API on top of the Objective-C API and to make the Objective-C API visible to Swift, we need to make them public as well. It is something that we need to solve before the final 2.0 release. Yeah, it was like this recently. But some developers would modify the configuration after creating the Database from it, and then asking why their configuration wasn’t applied. But DatabaseConfiguration is a struct, and in Swift, structs have "value" semantics. Therefore it is incorrect to expect that modifying a struct -- a copy of which was previously handed to another object -- should have any future effect. Accordingly, it seems unreasonable to penalize the programmer at init time in order to protect against such a mistake. -ben -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://url.emailprotection.link/?acI2QHOlLUu5r3fIWsg0FuhkF2e47DmK1vgOYPYmLg0Klkq3k-e350TEq7W8IuGwl2Uo3eLQjo_Bu_eHXSFq5WAqW_ZZY2NVnZnHzf9gzBrXoE5TNDGd2D4Nbt75Gs8T956kZ8E4OVauY4jPiTaR3yfnfa4WMcd1y-bqqb_mL7J0~. For more options, visit https://url.emailprotection.link/?acI2QHOlLUu5r3fIWsg0FukefuYIqVJU2gt8_envaf_7bRGVAePvclKgGlI5iD7VjZEtCv8mJsYVLH4A0CyroQQ~~. -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/8D660392-B929-495A-AE61-631C838B5920%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
