Squeal should use non-generic class name

[endash]

I'm just going to throw this out there but I kinda cringed when I saw that the main Squeal interface was just called "Database." Keep in mind that I'm new to Swift (and most of my background is Ruby, which has a more-than-healthy obsession with namespacing) so there might be things I can do to namespace/locally rename the Squeal Database class or whatnot, so please correct me if I'm making a mountain out of a molehill (In ESCMAScript 6, for instance, any imported module can be opaquely aliased in the client code). That said, I believe there are a couple problems with this naming:

(1) It's just not descriptive. When I inject a Squeal instance into my repository class at runtime, and a mock in-memory instance into the class for tests, they're both "Database" from the perspective of what they do in relation to the code that is using them, but they need easily distinguishable names. I'd much rather be dealing with instances of Squeal() (or Squeal::Database() would be ideal, but my understanding is that swift namespacing is way too clever to allow that), and MemoryStore() or whatever, simply for readability.

(2) Other than the testing case, one could conceivably have multiple database interfaces, with Squeal being but one. No one library should assume that it is used in a vacuum.

(3) Collisions with app code are not impossible by any means. Another (not iOS related) project I'm working on deals with databases and all the associated rigmarole as data objects, not code. Think a control panel or whatnot. Now my Database model class and my internal SQL connection library are at best very similarly named.

Other than the naming thing, I have no complaints :)

[nerdyc]

Hey Christopher!

Swift types are namespaced by their module names. The full name of the class is actually Squeal.Database, but the compiler only requires the namespace when there is a conflict.

But if you really hate the name, you can always create a typealias:

typealias SquealDB = Squeal.Database
var db = SquealDB()

Does this calm your cringes? After years of having to prefix classes with XYZ (due to the lack of namespaces), I'm pretty happy to not have the name of my project in my class names anymore.

[endash]

The things I was reading about the automatic namespacing behaviour seemed to indicate that it was a minefield, but if I can personally just use Squeal.Database where others might conceivably just use Database I suppose that'll be just fine.

It seems obvious now that the problem isn't that your class isn't namespaced, it's that the namespacing is, depending on your perspective, either all loosey goosey or groovily transparent. From my Ruby background I'm definitely going with the former :-D

Thanks for the quick feedback!

[nerdyc]

No problem!

Out of curiosity, where have you been reading about issues with automatic namespacing? I know that at the LLVM layer, modules don't deal with collisions. Objective-C modules, for example, don't prevent collisions. But I thought that the Swift compiler does force authors to deal with collisions.

[endash]

I personally haven't had problems, simply because I'm so very very very new to Swift. My thought process was as follows: (1) I want to use SQLIte (2) Few minutes of googling later, I find Squeal. Awesome. (3) Bang my head against the wall for a few hours trying to write the most basic of classe and most trivial of tests (4) Take a break to look at the Squeal API (5) See that the entry point is just a "Database" class. (6) Google around for swift and namespacing, find only woe and gnashing of teeth (7) Complain about class name (8) Discover that explicit namespacing is optional, and curse the language gods

[endash]

I must be dumber than a two year old because I'm getting "No such module 'Squeal'" if I import Squeal and "Use of undeclared type 'Squeal'" if I don't. I'm starting to regret giving iPhone dev another try.

[nerdyc]

I think you're running into the same issue in #14. The long and short: you need to ensure your app is linked against the Squeal framework. I should've updated the docs sooner :/

iOS development definitely has a steeper initial learning curve, especially if you're coming from a completely different toolset. But once you get yourself oriented there's a lot of great things to build and enjoy.

[endash]

I did iOS dev for a year back in 2011/2012 and as long as I could stay in the code and the APIs I was golden. The moment I had to do anything in xcode... oy.

Hallelujiah adding the framework did the trick. Well, for that problem at least :P