[swift-evolution] Proposal: Namespaces

[Marc Knaup]

No, an object declaration is a type and an instance at the same time.

Whatever the syntax is, something like `object NotificationNames {}` can be
referred to as type and as instance. It's initialized on first access.
So it's just `NotificationNames.userDataChanged` to access a property and
you can even omit the `static` for all variables.

On Mon, Dec 14, 2015 at 2:19 AM, Cole Kurkowski <crk at fastmail.com> wrote:

> Wouldn't that require a global variable to retain the object? I'm not sure
> that sounds ideal, since the whole point here is to stay away from having
> global variables flying around. (Though obviously one instead of N isn't
> too bad)
>
> I must admit I like your ideal better than namespace as a keyword, though
> I'm still not completely sold on bringing in anonymous objects to Swift.
>
> On Dec 13, 2015, at 17:49, Marc Knaup <marc at knaup.koeln> wrote:
>
> Sounds like a potential use case for object declarations:
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001837.html
>
> Same feature-set as structs but users cannot instantiate it since
> namespaces are basically singletons anyway.
> Bonus is that you can pass them around and make them conform to protocols.
>
>
> On Mon, Dec 14, 2015 at 12:44 AM, Cole Kurkowski via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> IMO using  an enum is non-intuitive. A struct is a "bucket of values"
>> and so makes fits with the usage here. If the ability to instantiate the
>> NotificationNames struct is a problem, adding a
>>
>> private init()
>> {
>>
>> }
>>
>> seems more intuitive than co-opting an enum, which has a fairly
>> established use case.
>>
>> Your proposal would essentially be adding a keyword that is transformed
>> back into "enum" during compilation. I don't think that a relatively minor
>> improvement in clarity for a fairly small use case is worth adding a
>> language feature.
>>
>> Allowing structs to be declared as static would be another way of
>> simplifying this kind of declaration, i.e.
>>
>> static struct NotificationNames {
>>      let userDataChanged = ...
>>      let recievedAlert = ...
>> }
>>
>> This would allow dropping the private init declaration and dropping the
>> static from each property. I'm not sure I think this shortcut is necessary
>> or even if it's a good idea, but I do think it fits with the language a
>> little better than your current proposal.
>>
>> On Dec 11, 2015, at 04:39, T.J. Usiyan via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Namespaces
>> Author(s): TJ Usiyan
>>
>> Introduction
>>
>> A `namespace` keyword for swift hold related global variables.
>>
>> Motivation
>>
>> We often want to collect related variables which do not, for whatever
>> reason, fit neatly into a type provided by Swift. Importing Objective C
>> 'magic strings' as Joshua Sullivan does [here] is one such example. The
>> solution he arrives at is a `struct` type with many type variables and no
>> fields.
>> struct NotificationNames {
>>  static let userDataChanged = "UserDataChangedNotificationName"
>>  static let receivedAlert = "ReceivedAlertNotificationName"
>>  static let peanutButterJellyTime =
>> "ItsPeanutButterJellyTimeNotificationName"
>> }
>>
>> Users of this API are not meant to create instances of this type, yet it
>> is still possible. A solution to this is to use an `enum` without cases.
>>
>> enum NotificationNames {
>>  static let userDataChanged = "UserDataChangedNotificationName"
>>  static let receivedAlert = "ReceivedAlertNotificationName"
>>  static let peanutButterJellyTime =
>> "ItsPeanutButterJellyTimeNotificationName"
>> }
>>
>> No instances of the `enum` can be made. That this inability to create an
>> instance is intentional is only conveyed via the type system.
>>
>> Proposed solution
>>
>> Clarity would be greatly improved if we could use `namespace` as a
>> synonym for an enum with no cases. This would allow us to avoid repetition
>> of `static` as well.
>>
>> namespace NotificationNames {
>>  let userDataChanged = "UserDataChangedNotificationName"
>>  let receivedAlert = "ReceivedAlertNotificationName"
>>  let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"
>> }
>>
>> Detailed design
>>
>> Namespaces can be represented in the type system as enums. All variables
>> declared in a namespace's scope would be type variables.
>>
>> Impact on existing code
>>
>> This is an additive change and, as such, should not break any existing
>> code. Though it doesn't matter, this addition could possibly attain ABI
>> compatibility if namespaces are represented as enums without cases.
>>
>> Alternatives considered
>>
>> Don't implement namespaces. Developers could continue(begin?) using an
>> empty enum to hold type variables.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/dbf0a25f/attachment.html>