VB Curioddities #1: Enum, Enum, my kingdom for an Enum.Parse

re: VB Curioddities #1: Enum, Enum, my kingdom for an Enum.Parse

Jonathan Allen — Thu, 29 Jun 2006 18:23:49 GMT

Perhaps I am being a bit dense on this. Kit, can you expand on this?

re: VB Curioddities #1: Enum, Enum, my kingdom for an Enum.Parse

Bill McCarthy — Thu, 29 Jun 2006 17:14:13 GMT

Jonathan, what do you mean by :
> What part of "Forget the Parse method" did you not understand?
You said:
> Finally, we can already make method calls on enums such as ToString and
> GetTypeCode.
So I was pointign out to you they are on the base class the same as Parse is. What exacly was your point if you want to forget Parse and now talk about yet another method on the base class. as I said, ToString is just the same as Parse is.

As to why you are not allowed to create your own methods, perhaps Kit can shed more light on that than I, but I think i've laready given you the HINT there. to put it simply, enums and their underlying type, e.g Int32, are fully interchangeable. This is why enums have no constraint checking as they are treated as an intrinsic value such as Int32. This offers great perfromance benifits at runtime, while still giving the design time goodness

re: VB Curioddities #1: Enum, Enum, my kingdom for an Enum.Parse

Jonathan Allen — Thu, 29 Jun 2006 05:23:25 GMT

> So basically the two problems you'd face if you tried to enforce a method being in an enum is that every language compiler in the world would need to implement that. That is, you'd have ot enforce a must override contract in System.Enum which also technically is illegal <g>

What part of "Forget the Parse method" did you not understand? The ship has sailed on that one. Fine, whatever. I don't care. What about my actual question...

WHY AM I NOT ALLOWED TO CREATE MY OWN METHODS INSIDE ENUM TYPES?

re: VB Curioddities #1: Enum, Enum, my kingdom for an Enum.Parse

Bill McCarthy — Wed, 28 Jun 2006 23:11:57 GMT

ToString, like Parse is on the base, System.Enum.

As to Enum's value memeber, it can in fact have any name but the requirements are there be only one field, that auto layout be applied and the field be an intrinsic type of the integer family. The reason for this is because you are allowed to use the underlying type instead of the enum anytime you like in IL, so the enum's stack alignment needs to match that of the intrinsic type.

So basically the two problems you'd face if you tried to enforce a method being in an enum is that every language compiler in the world would need to implement that. That is, you'd have ot enforce a must override contract in System.Enum which also technically is illegal <g>
Secondly, many languages compile the underlying value as a constant not a call to the enum static field. They woudl all have ot change.
So such a change would be (a) a breakign change in the framework, and (b) require extensive work by all language compilers. You have to weigh that cost against the benifit. you also need to compare that cost to other approaches such as non breaking low cost alternatives such as extension methods.

re: VB Curioddities #1: Enum, Enum, my kingdom for an Enum.Parse

Jonathan Allen — Wed, 28 Jun 2006 19:11:44 GMT

Forget the Parse method and the Extensions for a moment. The only thiing I'm really interested in is on why we cannot have methods on enumerations.

"So in the stack frame you don't even have an enum there, just an Int32, so you aren't really going to be able ot call a virtual method on it. "

No, you don't get just an Int32 on the stack. According to ILDASM, we get the actual enum on the stack...

Sub Foo()
Dim A As MyEnum = MyEnum.boat
Dim B As Integer = 1

.locals init ([0] valuetype WinForm_Scratch.Boom/MyEnum A,
[1] int32 B)

Futhermore, all enum's have a field called value__ that stores the value in the underlying type.

Secondly, any non-overriding method I write won't be virtual. Enums are always sealed, so the call is resolved statically at compile-time. (Unless of course you box the value, in which case I guess it gets resolved just like any other boxed value.)

Finally, we can already make method calls on enums such as ToString and GetTypeCode. And yes, these even work when the value is boxed.

I know that the Common Type System explicitly says that enums cannot have methods, but it doesn't say why. From what I have read so far, it is a convention rather than a technical requirement.

re: VB Curioddities #1: Enum, Enum, my kingdom for an Enum.Parse

Bill McCarthy — Wed, 28 Jun 2006 08:15:39 GMT

Jonathan, you can't expect every language to suddenly add parsing methods to each enum they declare.
Enums are a very special case of value type as they themselves derive from a value type, something that is techincially impossible. It's lots of smoke and mirrors that is actually going on, and for the most part, enums really are just a design time metadata thing, only being present in type (and parameter) declarations, but their values are compiled as constants usign the underlying base type (e.g. Int32). So in the stack frame you don't even have an enum there, just an Int32, so you aren't really going to be able ot call a virtual method on it. Sure some compilers could try to fudge this, but you'd end up with a lot of inconsistencies, and more work, and performance hits that what it would be worth.
As to Extension methods, they are really no different from what we use today with the Convert class, except they appear via the . syntax and so thee is a great intellisense story. They are of course CLS compliant as they are jsut shared methods. Any language can use them without the need for language support. Language support is only needed for the "." wizadry, which compiles exactly the same as if it is using the Shared method approach (e.g COnvert class)
As to documentation, hopefully the docs will include an "Extensions" section. that should be no problem for the classes MS produces, for your own, or third party extensions, I can't see how you could safely include that. But it is important to understand that you won't be using your own or third party extnesions wihtout Import'ing then, so the help for them would be via the import class name. I'd imagine f1 help couldresolve this to the actual shared method jsut like the compiler does.

re: VB Curiodities #1: Enum, Enum, my kingdom for an Enum.Parse

Jonathan Allen — Tue, 27 Jun 2006 20:04:13 GMT

> Jonathan said 'Why not just make it a standard method on the real type itself?
Dim ct as CarType = CarType.Parse("Sedan")
We could do additional work here Jonathan, but it would be considerable work, with little benefit. More importantly, it would be a breaking change, therefore, we're unlikely to ever make that kind of change. It's one of those 'the ship has sailed' situations.

Ok, maybe automatically generating the method would be bad. But is there any reason why we cannot have method on Enumerations?

re: VB Curiodities #1: Enum, Enum, my kingdom for an Enum.Parse

Jonathan Allen — Tue, 27 Jun 2006 19:54:07 GMT

Extensions are interesting, but they don't really address all of my issues.

In OOP, methods that affect data are supposed to be defined along with the structure that holds the data.

With extension methods, you get the illusion of OOP when using the Enum. However, you are still storing the function in a different place than the structure with its associated maintenance costs. In fact, the maintenance cost is a bit higher because it isn't clear where the extension lives.

Extension methods have the additional cost of being a language feature. This means that they won't be readily available to other languages. (Are they even CLS compliant?)

From a documentation stand-point, where do Extensions go? In their own section? If so, they will be hard to find there. Or with the class they are extending? But that means we need special notes indicating that some methods are not in the same assembly as the rest of the class.

My proposal to allow methods on enumerations shouldn't be hard to implement. Enumerations are just a special case of a Value type, and all other Value types already allow methods.

The only issue I see with the syntax is it can get confusing if enum values are mixed in with the methods. To whit I suggest that all enum values must be defined before any methods.

re: VB Curiodities #1: Enum, Enum, my kingdom for an Enum.Parse

Bill McCarthy — Tue, 27 Jun 2006 19:43:26 GMT

of course if you have an enum such as :

Public Enum Operations
Parse
...
End Enum

Then code such as

Dim op As Operations = CType(Operations.Parse("parse"), Operations)

won't even compile as the field hides the shared method of System.Enum.

So perhaps what we need is
- as has been mentioned a generic method on the base System.Enum;
- the compiler to suggest to "fix" code that tries to use Parse from a specific enum;
- relaxed rules on protected keywords (surely the []'s are note needed for Enum.Parse)

re: VB Curiodities #1: Enum, Enum, my kingdom for an Enum.Parse

VBTeam — Tue, 27 Jun 2006 19:27:09 GMT

Thanks all for the welcome folks! First, the CLR of course, is always in good hands (although feel free to use me as a reference point into them if you have no-one else, kitg@microsoft.com). Second, the dark side? I will be making sure "you shall pay for your lack of vision". I agree with Anthony, this is the land of happy code, I've always had a smile on my face when i get to code in VB.

Jonathan said 'Why not just make it a standard method on the real type itself?
Dim ct as CarType = CarType.Parse("Sedan")
We could do additional work here Jonathan, but it would be considerable work, with little benefit. More importantly, it would be a breaking change, therefore, we're unlikely to ever make that kind of change. It's one of those 'the ship has sailed' situations.

Geoff said 'Shame on you for not mentioning that your above samples only work with Option Strict Off'
Fair, fair. The only change for those who are curious is that you need to use CType to convert the object returned by Enum.Parse, to the specific Type you're converting to:
Dim ct as CarType = CType(CarType.Parse(GetType(CarType), "Sedan"), CarType)
The fact that an object type is returned from Parse leads nicely into the next point above:

Comment made by various folks: why not add a generic Enum.Parse method?
So yes, we have had this request before, and thanks for it, it is a great idea (hint: it's always a good idea to reping teams after they've said 'we'll consider this in a future version' to see how that consideration is coming along). You won't see this kind of addition in Orcas unless we did add it as an extension method, I'll be reforwarding the request onto the BCL team. It would certainly make the operation a lot more elegant, there's no doubt about that. Anthony's proposed implementation would do the trick.

Geoff's proposed solution is also a nice mechanism to resolve this issue, simply fully qualify Enum:
Dim ct as CarType = System.Enum.Parse(GetType(CarType), "Sedan")
Personally, I NEVER like fully qualifying stuff, my knee just kinda starts jerking.

Anthony said 'Why not just make the compiler spit out type specific Parse methods?'
This is an interesting idea, but I'm not sure we would ever do it. It would take a LOT of compiler work to make this happen (detect when to spit the type specific Parse, vs. not), and would require compiler work. Plus, what does it mean for the contract of a method? Generics seems to achieve the same objective.

Finally, Josh, on your vb syntax: looks good, apart from the trailing darkside at the end of your line. Uh, I mean, semi-colon ;-).