Add RealmConfiguration / RLMConfiguration

[segiddins]

Closes #1584

[jpsim]

Configuration not migration.

[jpsim]

This is moving in a great direction! Well done. Although I'd much prefer we deprecate the older APIs now rather than later. This will need tests and a few changelog entries too.

[kishikawakatsumi]

Would you like to support NSFileProtection attributes and NSURLIsExcludedFromBackupKey?

[jpsim]

@kishikawakatsumi this PR is just a first step meant to move our current API and functionality to this new interface. Adding new functionality is out of scope for this PR, but should be pretty simple to add afterwards.

[segiddins]

@jpsim I explicitly didn't deprecate the existing APIs because the tests rely on them so heavily

[segiddins]

@jpsim would you also like me to deprecate the existing apis for setting encryption keys and schema versions per path?

[jpsim]

would you also like me to deprecate the existing apis for setting encryption keys and schema versions per path?

Yes, it seems logical to me to minimize the number of ways to do the same thing, and I believe we're better off doing so sooner rather than later.

[segiddins]

OK. Marking those as deprecated (and cleaning up the tests) will take a bit of work.

[tgoyne]

whitespace

[tgoyne]

I don't understand what the goal of RLMConfigurator is. It's not a pattern that our users will be familiar with, and AFAICT the only benefit we get from is having to make a copy of the configuration object when setting the default one. If we do actually need an immutable version, RLMConfiguration/RLMMutableConfiguration would be much more normal and would be a similar amount of code both in the implementation and the code using it.

[segiddins]

@tgoyne the reason I went with that pattern is that it's the closest way possible of mimicking structs in Objective-C

[tgoyne]

The equivalent of a struct in obj-c is a class with mutable data members that you explicitly copy rather than implicitly copy.

[segiddins]

OK, changed to just be mutable. I'll add some tests if this design looks better?

[tgoyne]

There's a few things here that talk about the "default configuration", but nothing ever says what that is or what it's used for.

Realm needs to be capitalized.

[segiddins]

Done

[segiddins]

I believe I've now addressed all of the outstanding comments?

[segiddins]

Would like to get this merged soon, since I've started work on adding some features based on this PR

[segiddins]

@bdash could you please remind me what you see as the inconsistency?

[bdash]

This is still relevant after the move from RealmConfiguration to Realm.Configuration:

You haven't elaborated on why Configuration is too generic in the Swift API only, nor on why it is special in that regard. Is Configuration too generic because it's possible we'll want to make some other object in RealmSwift configurable in the future? If so, why wouldn't we also give the Objective-C class a name that indicates that it is a configuration for a Realm (e.g., RLMRealmConfiguration). Is there something I'm missing that makes the need to qualify the typename specific to the Swift API? My impression is that either both should have the extra Realm qualification, or neither should.

[segiddins]

Realm.Configuration is not nearly as generic as just Configuration -- the type shows that it's something that configures Realm (as a framework). The RLM prefix also signifies this.

[bdash]

Being a generic term doesn't seem like a strong argument for special treatment given that we declare types with names like Object and List. Why is Configuration different from those other types?

Your description of the Realm prefix sounds like it's duplicating the namespacing that's already provided by Swift's modules.

[segiddins]

I personally dislike that we have things called Object and List, but at least they're incredibly common parts of our API that will basically be used wherever Realm is used in a user's app. The configuration will probably only be created once, and it is an ancillary, supporting class, not something crucial to using Realm.

[tgoyne]

I suggested Realm.Configuration on the grounds that it exists only to be passed to Realm's initializer (and setDefaultRealm), and so it feels natural to reduce its scope as much as possible and nest it within Realm. We can't do the same thing in obj-c, but I wouldn't be opposed to RLMRealmConfiguration.

[segiddins]

Renamed.

[bdash]

👍

[segiddins]

CHANGELOG added

[segiddins]

Test failures all look unrelated (open() failed or testNotificationForChangesWhileSuspended)