<div dir="ltr">On 2 May 2013 02:18, Tres Seaver <span dir="ltr"><<a href="mailto:tseaver@palladion.com" target="_blank">tseaver@palladion.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div class="im"><br>
On 05/01/2013 12:14 PM, Guido van Rossum wrote:<br>
> But we'd probably have to give up something else, e.g. adding methods<br>
> to enums, or any hope that the instance/class/subclass relationships<br>
> make any sense.<br>
<br>
</div>I'd be glad to drop both of those in favor of subclassing:  I think the<br>
emphasis on "class-ness" makes no sense, given the driving usecases for<br>
adopting enums into the stdlib in the first place.   IOW, I would vote<br>
that real-world usecases trump hypothetical purity.<br></blockquote><div><br></div><div style>I have real-world use cases of enums (in java) that are essentially classes and happen to use the enum portion purely to obtain a unique name without explicitly supplying an ID.</div>
<div style><br></div><div style>In the particular use case I'm thinking of, the flow is basically like this:</div><div style><br></div><div style>1. An Enum where each instance describes the shape of a database query.</div>
<div style>2. Wire protocol where the Enum instance name is passed.</div><div style>3. At one end, the data for performing the DB query is populated.</div><div style>4. At the other end, the data is extracted and the appropriate enum is used to perform the query.</div>
<div style><br></div><div style>Why use an enum? By using the name in the wire protocol I'm guaranteed a unique ID that won't change across versions (there is a requirement to only add to the enum) but does not rely on people setting it manually - the compiler will complain if there is a conflict, as opposed to setting values. And having the behaviour be part of the class simplifies things immensely.</div>
<div style><br></div><div style>Yes, I could do all of this without an enum (have class check that each supplied ID is unique, etc) but the code is much clearer using the enum.</div><div style><br></div><div style>I am happy to give up subclassing of enums in order to have behaviour on enum instances. I've always seen enums more as a container for their instances. I do want to be able to find out what enum class a particular enum belongs to (I've used this property in the past) and it's nice that the enum instance is an instance of the defining class (although IMO not required).</div>
<div style><br></div><div style>I see advantages to enums being subclassable, but also significant disadvantages. For example, given the following:</div><div style><br></div><div style>class Color(Enum):</div><div style>    red = 1</div>
<div style><br></div><div style>class MoreColor(Color):</div><div style>    blue = 2</div><div style><br></div><div style>class DifferentMoreColor(Color):</div><div style>    green = 2</div><div style><br></div><div style>
then the only reasonable way for it to work IMO is that MoreColor contains both (red, blue) and DifferentMoreColor contains both (red, green) and that red is not an instance of either MoreColor or DifferentMoreColor. If you allow subclassing, at some point either something is going to be intuitively backwards to some people (in the above that Color.red is not an instance of MoreColor), or is going to result in a contravariance violation.</div>
<div style><br></div><div style>Tim Delaney <br></div></div></div></div>