[swift-evolution] [Proposal] Enums with staticstoredpropertiesforeach case
Leonardo Pessoa
me at lmpessoa.com
Thu May 26 15:23:19 CDT 2016
Ok, I'm not familiar with Scala but if the language does not have support for the type of enums we're discussing it may be their chosen mechanism to handle enums with associated values (feel free to correct me if I'm wrong always) but my main point for enums is still: do we really need to introduce another concept to handle the presented examples or can we reuse an existing concept? Enums are (or can be seen as) our case classes but there seems to exist a need for enums to hold more than just one value as of today.
Just to mention ahead, I'm not in favour of enum values having methods or computed properties
-----Original Message-----
From: "Charlie Monroe" <charlie at charliemonroe.net>
Sent: 26/05/2016 04:57 PM
To: "Leonardo Pessoa" <me at lmpessoa.com>
Cc: "Vladimir.S" <svabox at gmail.com>; "swift-evolution" <swift-evolution at swift.org>
Subject: Re: [swift-evolution] [Proposal] Enums with staticstoredpropertiesforeach case
Not really. When you take Scala's case classes, they are exactly for this purpose:
http://docs.scala-lang.org/tutorials/tour/case-classes.html
abstract class Term
case class Var(name: String) extends Term
case class Fun(arg: String, body: Term) extends Term
case class App(f: Term, v: Term) extends Term
Which in Swift could be an enum.
You can look at sealed classes in two ways:
1) Something that prevents others from subclassing your classes.
2) Something that ensures that only a known number of subclasses exists at compile-time - which is pretty much the definition of an enum.
On May 26, 2016, at 9:48 PM, Leonardo Pessoa <me at lmpessoa.com> wrote:
I think these are different concepts. Classes and structs are abstractions for something (think of them as empty forms while instances are filled forms) while enums identify a closed set of values (filled forms) known ahead of use. Sealed classes are intended to limit extensions to a class not to the instances that can be created.
From: Charlie Monroe
Sent: 26/05/2016 03:13 PM
To: Vladimir.S
Cc: Leonardo Pessoa; swift-evolution
Subject: Re: [swift-evolution] [Proposal] Enums with static storedpropertiesforeach case
Now thinking about this, what would solve this partially is being discussed in another topic here - sealed clasees.
Each planet would have its own class and the superclass Planet would be abstract sealed. You would then be able to do an effective switch on the instance of the planet, which would act like an enum.
> On May 26, 2016, at 8:06 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>
> Yes, this was mentioned in a similar thread in this email list earlier. There is even some proposal for such .values() for Swift enums.
>
> But this values() in Java is not the same thing as discussed dictionary with *keys* of enum type or Delphi's arrays with *index* of enum type.
>
> Could you write Java's example for array/dictionary of String which *index*(or key) will be of enum type? *And* compiler will check that value for each enum case is set in case of array of constants like:
> MyConsts : array [TMyEnum] of String = ('just one', 'two here')
> // compiler will always check that value assigned for each case
>
>
> On 26.05.2016 20:58, Leonardo Pessoa wrote:
>> Java enums automatically have a static values() method that return an array
>> with all values in an enum.
>> ---------------------------------------------------------------------------
>> From: Vladimir.S via swift-evolution <mailto:swift-evolution at swift.org>
>> Sent: 26/05/2016 02:36 PM
>> To: Ross O'Brien <mailto:narrativium+swift at gmail.com>
>> Cc: swift-evolution <mailto:swift-evolution at swift.org>
>> Subject: Re: [swift-evolution] [Proposal] Enums with static stored
>> propertiesforeach case
>>
>> On 26.05.2016 19:50, Ross O'Brien wrote:
>>> Perhaps there's an argument to be made for a sort of 'enumDictionary' type
>>> - a dictionary whose keys are all the cases of an enum, and is thus
>>> guaranteed to produce a value.
>>
>> In Delphi(Pascal) you can define an array with indexes of enum type i.e.:
>> type
>> TMyEnum = (One, Two)
>> var
>> MyVal : array[TMyEnum] of String
>> const
>> MyConsts : array [TMyEnum] of String = ('just one', 'two here')
>> // compiler will check that values for each enum were specified here
>>
>> ,so you can do
>> var e: TMyEnum
>> e := One;
>> MyVal[e] := 'hello';
>> s2 := MyConsts[e];
>>
>> This is really useful and used a lot. And this is safe in meaning compiler
>> will notify you if you changed the enum - you'll have to change such
>> constant array.
>>
>> I wish we'll have something like this in Swift.
>>
>>>
>>> I think the question I have is how you'd access the values, syntactically.
>>> To use the Planet example, if '.earth' is a value of the Planet enum, is
>>> '.earth.mass' an acceptable way to access its mass? Or perhaps
>>> 'Planet[.earth].mass'?
>>
>> Just like .rawValue currently, i.e.
>> let e = Planet.earth
>> print(e.mass, e.description)
>>
>>>
>>> On Thu, May 26, 2016 at 4:43 PM, Vladimir.S via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> Or(if we are sure we'll don't forget to udpate `infoDict` in case of
>>> new added case in future):
>>>
>>> enum Planet {
>>> case earth
>>> case moon
>>>
>>> struct PlanetInfo {
>>> var mass: Double
>>> var description: String
>>> }
>>>
>>> private static let infoDict = [
>>> Planet.earth :
>>> PlanetInfo(mass: 1.0, description:"Earth is our home"),
>>> .moon:
>>> PlanetInfo(mass: 0.2, description:"Just a moon"),
>>> ]
>>>
>>> var info : PlanetInfo { return Planet.infoDict[self]! }
>>> }
>>>
>>> But I agree with you, IMO we need static stored properties for each case.
>>>
>>>
>>> On 26.05.2016 18 <tel:26.05.2016%2018>:15, Jānis Kiršteins wrote:
>>>
>>> The problem is that PlanetInfo values are recreated each time while
>>> they are static. Imagine if PlanetInfo where some type that expensive
>>> to create performance wise.
>>>
>>> You could solve it by:
>>>
>>> enum Planet {
>>> struct PlanetInfo {
>>> var mass: Double
>>> var description: String
>>> }
>>>
>>> case earth
>>> case moon
>>>
>>> private static earthInfo = PlanetInfo(mass: 1.0, description:
>>> "Earth is our home")
>>> private static moonInfo = PlanetInfo(mass: 0.2, description:
>>> "Just a moon")
>>>
>>> var info : PlanetInfo {
>>> switch self {
>>> case earth: return PlanetInfo.earthInfo
>>> case moon: return PlanetInfo.moonInfo
>>> }
>>> }
>>> }
>>>
>>> But that again more verbose. The proposed solution is explicit that
>>> those properties are static for each case.
>>>
>>>
>>> On Thu, May 26, 2016 at 5:58 PM, Vladimir.S via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> I support the proposal, but couldn't the initial target be
>>> achieved today
>>> with such (more verbose,yes) solution? :
>>>
>>> enum Planet {
>>> struct PlanetInfo {
>>> var mass: Double
>>> var description: String
>>> }
>>>
>>> case earth
>>> case moon
>>>
>>> var info : PlanetInfo {
>>> switch self {
>>> case earth: return PlanetInfo(mass: 1.0,
>>> description: "Earth is
>>> our home")
>>> case moon: return PlanetInfo(mass: 0.2,
>>> description: "Just a
>>> moon")
>>> }
>>> }
>>> }
>>>
>>>
>>> let e = Planet.earth
>>> print(e, e.info.description)
>>>
>>> let m = Planet.moon
>>> print(m, m.info.description)
>>>
>>>
>>>
>>> On 26.05.2016 8:26, Charlie Monroe via swift-evolution wrote:
>>>
>>>
>>> What this proposal is asking for is an easier way to
>>> have derived values
>>> from enum cases. Asking for more flexible RawValues
>>> means mass and radius
>>> are not derived, they are the source of truth. It goes
>>> against the whole
>>> point of RawRepresentable. You are not saying ‘Mercury
>>> is identified by<br
[The entire original message is not included.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160526/74594427/attachment.html>
More information about the swift-evolution
mailing list