<div dir="ltr">No, an object declaration is a type and an instance at the same time.<div><br><div>Whatever the syntax is, something like <font face="monospace, monospace">`object NotificationNames {}`</font> can be referred to as type and as instance. It's initialized on first access.</div><div>So it's just <font face="monospace, monospace">`<span style="font-size:12.8px">NotificationNames.</span></font><span style="font-size:12.8px"><font face="monospace, monospace">userDataChanged`</font><font face="arial, helvetica, sans-serif"> to access a property</font> and you can even omit the <font face="monospace, monospace">`static`</font> for all variables.</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 2:19 AM, Cole Kurkowski <span dir="ltr"><<a href="mailto:crk@fastmail.com" target="_blank">crk@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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)</div><div><br></div><div>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. </div><div><div class="h5"><div><br>On Dec 13, 2015, at 17:49, Marc Knaup <<a href="mailto:marc@knaup.koeln" target="_blank">marc@knaup.koeln</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Sounds like a potential use case for object declarations:<div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001837.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001837.html</a><br></div><div><br></div><div>Same feature-set as structs but users cannot instantiate it since namespaces are basically singletons anyway.</div><div>Bonus is that you can pass them around and make them conform to protocols.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 12:44 AM, Cole Kurkowski via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>IMO using <span style="background-color:rgba(255,255,255,0)"> 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 </span></div><div><br><div><span style="background-color:rgba(255,255,255,0)">private init() </span></div><div><span style="background-color:rgba(255,255,255,0)">{</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">}</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">seems more intuitive than co-opting an enum, which has a fairly established use case. </span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">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.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">Allowing structs to be declared as static would be another way of simplifying this kind of declaration, i.e.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">static struct NotificationNames {</span></div><div><span style="background-color:rgba(255,255,255,0)"> let userDataChanged = ...</span></div><div><span style="background-color:rgba(255,255,255,0)"> let recievedAlert = ...</span></div><div><span style="background-color:rgba(255,255,255,0)">}</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">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. </span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div></div><div><div><div>On Dec 11, 2015, at 04:39, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Namespaces</div><div>Author(s): TJ Usiyan</div><div><br></div><div>Introduction</div><div><br></div><div>A `namespace` keyword for swift hold related global variables.</div><div><br></div><div>Motivation</div><div><br></div><div>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.</div><div><span style="white-space:pre-wrap"> </span></div><div><span style="white-space:pre-wrap"> </span>struct NotificationNames {</div><div><span style="white-space:pre-wrap"> </span> static let userDataChanged = "UserDataChangedNotificationName"</div><div><span style="white-space:pre-wrap"> </span> static let receivedAlert = "ReceivedAlertNotificationName"</div><div><span style="white-space:pre-wrap"> </span> static let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"</div><div><span style="white-space:pre-wrap"> </span>}</div><div><br></div><div>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. </div><div><br></div><div><span style="white-space:pre-wrap"> </span>enum NotificationNames {</div><div><span style="white-space:pre-wrap"> </span> static let userDataChanged = "UserDataChangedNotificationName"</div><div><span style="white-space:pre-wrap"> </span> static let receivedAlert = "ReceivedAlertNotificationName"</div><div><span style="white-space:pre-wrap"> </span> static let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"</div><div><span style="white-space:pre-wrap"> </span>}</div><div><br></div><div>No instances of the `enum` can be made. That this inability to create an instance is intentional is only conveyed via the type system. </div><div><br></div><div>Proposed solution</div><div><br></div><div>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.</div><div><br></div><div><span style="white-space:pre-wrap"> </span>namespace NotificationNames {</div><div><span style="white-space:pre-wrap"> </span> let userDataChanged = "UserDataChangedNotificationName"</div><div><span style="white-space:pre-wrap"> </span> let receivedAlert = "ReceivedAlertNotificationName"</div><div><span style="white-space:pre-wrap"> </span> let peanutButterJellyTime = "ItsPeanutButterJellyTimeNotificationName"</div><div><span style="white-space:pre-wrap"> </span>}</div><div><br></div><div>Detailed design</div><div><br></div><div>Namespaces can be represented in the type system as enums. All variables declared in a namespace's scope would be type variables.</div><div><br></div><div>Impact on existing code</div><div><br></div><div>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.</div><div><br></div><div>Alternatives considered</div><div><br></div><div>Don't implement namespaces. Developers could continue(begin?) using an empty enum to hold type variables.</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=-2Bxb47WeGoqMoAgzLM1ObomDZ33eAoWUyfgnPK0aY0kmOBV0UOL-2F-2FewTnMlFakhgehvwInLhXqOSgLWhWSC59AspLa6GqGYZeh-2BtdIo20WyqWuINj3rtuE9qLd-2BiL4jagc5HtjH2Ce0ulfeDXCmavB061BWZFQBdbt3RewD1Vr7Qm8vt6InljqJC-2FSC7yR9nSfTzLs3qbGWpKpC-2BzjutEtkq79cco-2BGmJif1-2BbbIwACs-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></span></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZgO93S0GjF-2FBLbNsjiS9bZCN6qivxY-2FMQm88297IFwucGKKnMPcpjI6abX5QU0DLTv2n2Sh-2FWurt7-2Fwo4VIFzKYo9Nps0yZEycNRrWJGYfDQp0CSUof-2FuBWp0Isvut2JnEF6b1q-2Bb6GO0Aqdz0Y-2FRTZiHlmHMC4KZOhk-2Bz9jh5uPLB-2FNFGMduTX-2BUib-2FgoLMYA-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div></div></div></blockquote></div><br></div>