On 4/5/13, Chad Joan <chadjoan@gmail.com> wrote:
> Enums do not have instances.

Sure they do.

enum Foo
{
	X,
	Y
}

void test(Foo foo) { }

void main()
{
    Foo foo = Foo.Y;
    test(foo);
}

Chad Joan:

> Hmmm, I don't remember python doing this.  Do you mean like Java?

I meant Python. In Python when you write:

import foo

You have then to use:

foo.bar()

If you want to import just bar you have to use:

from foo import bar

There is also this syntax, used only in special situations, like when you are using the REPL:

from foo import *

That imports all the names of foo.



> So I would have to write code like this:
> ---
> import std.file, std.array, std.stdio;
>
> void main()
> {
>     std.stdio.writeln(
>         std.array.replace(
>             cast(string)std.file.read("file.txt"),"\r\n","\n"));
> }
> ---
> instead of code like this:
> ---
> import std.file, std.array, std.stdio;
>
> void main()
> {
>     writeln(replace(cast(string)read("file.txt"),"\r\n","\n"));
> }
> ---
> ???

See the solutions used in Python.

But this stuff is long settled in D, so this discussion is now academic :-)

Bye,
bearophile

On 04/05/2013 01:18 PM, Andrej Mitrovic wrote:
> On 4/5/13, Chad Joan<chadjoan@gmail.com>  wrote:
>> Enums do not have instances.
>
> Sure they do.
>
> enum Foo
> {
> 	X,
> 	Y
> }
>
> void test(Foo foo) { }
>
> void main()
> {
>      Foo foo = Foo.Y;
>      test(foo);
> }

Where's the instance?

All I see is

void test(int foo) { }

void main()
{
    int foo = 1;
    test(foo);
}

There is no stateful aggregation for me to see here.

On 04/05/2013 01:48 PM, bearophile wrote:
> Chad Joan:
>
>> Hmmm, I don't remember python doing this. Do you mean like Java?
>
> See the solutions used in Python.
>
> But this stuff is long settled in D, so this discussion is now academic :-)
>
> Bye,
> bearophile

I skimmed some of the Python docs on this and it seems reasonable.  In Python I'd get my shorter example by doing something like:

from std.stdio import *

Which would put all of the std.stdio module's symbols into the current module's lookup table.  I probably used this a lot back when I used Python.

I also noticed something in there that I wish I could do in D:

from sound.effects import echo
echo.echofilter(input, output, delay=0.7, atten=4)

I think this would be analogous to the following D code, if it worked:

import std;

stdio.writeln("Hello world!");

That would be nice.  D seems to force your symbol qualifications to be either fully qualified or not qualified at all, which is not always the best solution :/

If D can somehow do partially-qualified module names, then please teach me.

On 04/05/2013 01:48 PM, Chad Joan wrote:
> On 04/05/2013 01:18 PM, Andrej Mitrovic wrote:
>> On 4/5/13, Chad Joan<chadjoan@gmail.com> wrote:
>>> Enums do not have instances.
>>
>> Sure they do.
>>
>> enum Foo
>> {
>> X,
>> Y
>> }
>>
>> void test(Foo foo) { }
>>
>> void main()
>> {
>> Foo foo = Foo.Y;
>> test(foo);
>> }
>
> Where's the instance?
>
> All I see is
>
> void test(int foo) { }
>
> void main()
> {
> int foo = 1;
> test(foo);
> }
>
> There is no stateful aggregation for me to see here.

I can probably word this another way, since I might not have been entirely clear.

Things like structs and classes occupy memory.  Enums do not.  Foo.Y expands to an immediate value and has no storage in the program's data segment.  Enums place constraints on other things that do occupy memory: usually integers.

On Friday, 5 April 2013 at 18:03:33 UTC, Chad Joan wrote:
> On 04/05/2013 01:48 PM, Chad Joan wrote:
>> On 04/05/2013 01:18 PM, Andrej Mitrovic wrote:
>>> On 4/5/13, Chad Joan<chadjoan@gmail.com> wrote:
>>>> Enums do not have instances.
>>>
>>> Sure they do.
>>>
>>> enum Foo
>>> {
>>> X,
>>> Y
>>> }
>>>
>>> void test(Foo foo) { }
>>>
>>> void main()
>>> {
>>> Foo foo = Foo.Y;
>>> test(foo);
>>> }

foo is the instance.

> I can probably word this another way, since I might not have been entirely clear.
>
> Things like structs and classes occupy memory.  Enums do not.  Foo.Y expands to an immediate value and has no storage in the program's data segment.  Enums place constraints on other things that do occupy memory: usually integers.

foo does occupy memory. That foo is represented just like an integer does not change this. foo could be a struct or an array, too.

On 04/05/2013 02:06 PM, Tobias Pankrath wrote:
> On Friday, 5 April 2013 at 18:03:33 UTC, Chad Joan wrote:
>> On 04/05/2013 01:48 PM, Chad Joan wrote:
>>> On 04/05/2013 01:18 PM, Andrej Mitrovic wrote:
>>>> On 4/5/13, Chad Joan<chadjoan@gmail.com> wrote:
>>>>> Enums do not have instances.
>>>>
>>>> Sure they do.
>>>>
>>>> enum Foo
>>>> {
>>>> X,
>>>> Y
>>>> }
>>>>
>>>> void test(Foo foo) { }
>>>>
>>>> void main()
>>>> {
>>>> Foo foo = Foo.Y;
>>>> test(foo);
>>>> }
>
> foo is the instance.
>
>> I can probably word this another way, since I might not have been
>> entirely clear.
>>
>> Things like structs and classes occupy memory. Enums do not. Foo.Y
>> expands to an immediate value and has no storage in the program's data
>> segment. Enums place constraints on other things that do occupy
>> memory: usually integers.
>
> foo does occupy memory. That foo is represented just like an integer
> does not change this. foo could be a struct or an array, too.

At this point it is probably definitional.

I would prefer to define enums as a kind of constraint over types, rather than as its own storable type.  This is just much more useful to me.

Usage-wise, I see enums doing two things:
(1) Constraining function input/output to a named set of possible values, at compile-time.
(2) Requiring constants to be qualified with a tag name.

I think that both of these are useful in different situations.  What I don't like is that they are tightly coupled.

Usually I want (1).  (1) can eliminate sources of bugs.  That's awesome.

Usually (2) is a hindrance to me.  It causes a lot of line-wrapping and noise.  The D compiler is good enough at finding ambiguities and erroring on them that I feel it is unnecessary in most situations (I'm sure there are exceptions).

(2) is especially bad for flag sets that get ORed together.  It's so clumsy that it discourages the use of enums.  Thus, having (2) tightly coupled with (1) can undermine the benefits of (1).  It runs against one of Walter's design goals: the easy thing should be the safe and correct thing.  Right now the safe and correct thing requires extra noise and line wraps; it is not easier.

I really just wish there was an easy way to pick-and-choose which attributes are desired for a given enum, based on usage scenario.

I will probably be writing "mixin dequalifyEnum!SomeEnum;" next to a lot of my enums from now on.  It's just another papercut, like all of the typedef'ing on structs in C.