May 01, 2023

On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote:

>

On Monday, 1 May 2023 at 00:34:03 UTC, ryuukk_ wrote:

> >

I don't think it's a misconception. It's more like a complete lack of clarity.

>

the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad

Value value;
value.type = ValueType.STRING;

vs

Value value;
value.type = .STRING;

This is another case of the "complete lack of clarity" I wrote about in my earlier comment. With an anonymous enum you could write

value.type = STRING;

Maybe you have something deeper in mind, but that example does not make a case for changing the language. Rather than shouting, you should put together a better example.

I will let this conversation die. I don't think it's going to resolve anything (and I'm not the one that needs convincing anyway).

Ok.. so you refuse to understand (as opposed to not understanding, wich in that case you'd only have to listen and learn)

You didn't read my previous comment, so let me copy/paste it:

>

the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad

And to make sure i'm being understood, the goal is not to make code less verbose, quite the opposite, the goal is to encourage verbosity while avoiding useless repetitions, the two are not compatible

Are you familiar with this popular quote? "democracy dies in darkness"? It goes the same way with discussing feature suggestions and language impromvents, don't "let this conversation die", convince me, argument, don't just try to silence me, that won't work

May 11, 2023

I was reading DMD source code, case of repetition that adds nothing of value but useless reading strain

https://github.com/dlang/dmd/blob/999d835c1196eb993a99bb7f1c863da265a6b6c0/compiler/src/dmd/json.d#L843-L869

        if (target.os == Target.OS.Windows)
        {
            item("windows");
        }
        else
        {
            item("posix");
            if (target.os == Target.OS.linux)
                item("linux");
            else if (target.os == Target.OS.OSX)
                item("osx");
            else if (target.os == Target.OS.FreeBSD)
            {
                item("freebsd");
                item("bsd");
            }
            else if (target.os == Target.OS.OpenBSD)
            {
                item("openbsd");
                item("bsd");
            }
            else if (target.os == Target.OS.Solaris)
            {
                item("solaris");
                item("bsd");
            }
        }
        arrayEnd();

what could be done to avoid the repetition?

Reduce the length of the repetition with a short alias?

        alias TOS = Target.OS;

        if (target.os == TOS.Windows)
        {
            item("windows");
        }
        else
        {
            item("posix");
            if (target.os == TOS.linux)
                item("linux");
            else if (target.os == TOS.OSX)
                item("osx");
            else if (target.os == TOS.FreeBSD)
            {
                item("freebsd");
                item("bsd");
            }
            else if (target.os == TOS.OpenBSD)
            {
                item("openbsd");
                item("bsd");
            }
            else if (target.os == TOS.Solaris)
            {
                item("solaris");
                item("bsd");
            }
        }
        arrayEnd();

Well, repetition is still there, now you got a short Type to type that doesn't mean anything without context, why is it needed? why do we need that noise? what problem does it solve?

We can use with()? but why do i need a with here? target.os is self explanatory already, it's supposed to be type safe, it's a type safe enumeration, i should only care about the values, why now introduce an extra scope with extra indentation? it'd create more noise and now visual strain

Don't you find this code easier to read and review?

        if (target.os == .Windows)
        {
            item("windows");
        }
        else
        {
            item("posix");
            if (target.os == .linux)
                item("linux");
            else if (target.os == .OSX)
                item("osx");
            else if (target.os == .FreeBSD)
            {
                item("freebsd");
                item("bsd");
            }
            else if (target.os == .OpenBSD)
            {
                item("openbsd");
                item("bsd");
            }
            else if (target.os == .Solaris)
            {
                item("solaris");
                item("bsd");
            }
        }
        arrayEnd();
May 11, 2023

On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:

>

Don't you find this code easier to read and review?

        if (target.os == .Windows)
        {
            item("windows");
        }
        else
        {
            item("posix");
            if (target.os == .linux)
                item("linux");
            else if (target.os == .OSX)
                item("osx");
            else if (target.os == .FreeBSD)
            {
                item("freebsd");
                item("bsd");
            }
            else if (target.os == .OpenBSD)
            {
                item("openbsd");
                item("bsd");
            }
            else if (target.os == .Solaris)
            {
                item("solaris");
                item("bsd");
            }
        }
        arrayEnd();

Honestly, not really. I've never looked at this part of DMD, and without context, I'd have no idea where the symbols Windows, linux, FreeBSD, and so on were coming from. Having it explicitly spelled out at the usage site--either via qualified names (Target.OS.Windows) or a local alias (alias TOS = Target.OS) makes it trivial to understand what's being referred to.

In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: enum TargetOS in cli.d, and enum OS in target.d. So you would have to scroll up and look at the imports to disambiguate.

May 11, 2023

On 5/10/23 11:22 PM, Paul Backus wrote:

>

In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: enum TargetOS in cli.d, and enum OS in target.d. So you would have to scroll up and look at the imports to disambiguate.

Then you misunderstand the DIP (as did Walter). There is only one enum that can be involved -- typeof(target.os).

-Steve

May 11, 2023

On Thursday, 11 May 2023 at 13:31:58 UTC, Steven Schveighoffer wrote:

>

On 5/10/23 11:22 PM, Paul Backus wrote:

>

In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: enum TargetOS in cli.d, and enum OS in target.d. So you would have to scroll up and look at the imports to disambiguate.

Then you misunderstand the DIP (as did Walter). There is only one enum that can be involved -- typeof(target.os).

Oh no, I'm perfectly aware that, from the compiler's perspective, it would be unambiguous--only one of the two enums would actually be in scope. But as a human reader, in order to figure out which one, I'd have to scroll to the top of the file and read through ~25 lines of imports (or rely on tooling, but there are contexts where that isn't available, like a Github code review).

May 11, 2023

On 5/11/23 10:10 AM, Paul Backus wrote:

>

On Thursday, 11 May 2023 at 13:31:58 UTC, Steven Schveighoffer wrote:

>

On 5/10/23 11:22 PM, Paul Backus wrote:

>

In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: enum TargetOS in cli.d, and enum OS in target.d. So you would have to scroll up and look at the imports to disambiguate.

Then you misunderstand the DIP (as did Walter). There is only one enum that can be involved -- typeof(target.os).

Oh no, I'm perfectly aware that, from the compiler's perspective, it would be unambiguous--only one of the two enums would actually be in scope.

Scope has nothing to do with it. The wrong enum might be the only one in scope, and it will still use the correct one. Both enums might be in scope, and it still uses the correct one.

>

But as a human reader, in order to figure out which one, I'd have to scroll to the top of the file and read through ~25 lines of imports (or rely on tooling, but there are contexts where that isn't available, like a Github code review).

It's no different than:

if(target.os == target.os.Solaris)

It's not very hard to understand, nor harder to figure out. What type is target.os? It's an enum from that type.

-Steve

May 11, 2023

On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:

>

Don't you find this code easier to read and review?

        if (target.os == .Windows)
        {
            item("windows");
        }
        else
        {
            item("posix");
            if (target.os == .linux)
                item("linux");
            else if (target.os == .OSX)
                item("osx");
            else if (target.os == .FreeBSD)
            {
                item("freebsd");
                item("bsd");
            }
            else if (target.os == .OpenBSD)
            {
                item("openbsd");
                item("bsd");
            }
            else if (target.os == .Solaris)
            {
                item("solaris");
                item("bsd");
            }
        }
        arrayEnd();

No, I find this harder to review.

. is the module scope operator, which is already going to be difficult for new dlang coders to learn about given that they would end up searching for the meaning of the . character (I speak from my experience learning D).

I haven't reviewed the DIP in full, but a quick search of the DIP for "module scope operator" does indicate that overloading the module scope operator was already called out as undesirable, so I'm not sure why you would use . again here when trying to defend the rejected DIP.

Having read the conversation, but not the DIP, I think the repetition issue is known, but the examples offered don't demonstrate (to me, a random nobody reading this thread) a clear improvement of the language or the code in question.

I will add that this particular case of repetition the DIP seems to be intended to solve reminds me of brace-expansion in bash, where foo.iso{,.sig} expands to foo.iso foo.iso.sig allowing bashers to avoid repetition in some cases of repetitive strings, but it should be evident to anyone subjected to reading someone else's bash script that that reducing repetition with brace expansion does not unconditionally improve reviewability of the code in question.

May 12, 2023

On Thursday, 11 May 2023 at 23:00:03 UTC, epilogue wrote:

>

On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:

>

Don't you find this code easier to read and review?

        if (target.os == .Windows)
        {
            item("windows");
        }
        else
        {
            item("posix");
            if (target.os == .linux)
                item("linux");
            else if (target.os == .OSX)
                item("osx");
            else if (target.os == .FreeBSD)
            {
                item("freebsd");
                item("bsd");
            }
            else if (target.os == .OpenBSD)
            {
                item("openbsd");
                item("bsd");
            }
            else if (target.os == .Solaris)
            {
                item("solaris");
                item("bsd");
            }
        }
        arrayEnd();

No, I find this harder to review.

. is the module scope operator, which is already going to be difficult for new dlang coders to learn about given that they would end up searching for the meaning of the . character (I speak from my experience learning D).

I haven't reviewed the DIP in full, but a quick search of the DIP for "module scope operator" does indicate that overloading the module scope operator was already called out as undesirable, so I'm not sure why you would use . again here when trying to defend the rejected DIP.

Having read the conversation, but not the DIP, I think the repetition issue is known, but the examples offered don't demonstrate (to me, a random nobody reading this thread) a clear improvement of the language or the code in question.

I will add that this particular case of repetition the DIP seems to be intended to solve reminds me of brace-expansion in bash, where foo.iso{,.sig} expands to foo.iso foo.iso.sig allowing bashers to avoid repetition in some cases of repetitive strings, but it should be evident to anyone subjected to reading someone else's bash script that that reducing repetition with brace expansion does not unconditionally improve reviewability of the code in question.

The syntax doesn't matter, i could have used # or :, what ever, let's focus on the idea first

It's am improvement to me, hence why i advocate for it, i'm not a compiler developper, i can't think of everything, all i can think of is it's going to improve the way i write my code

All it took me to appreciate it was to discover it when i was using a language that happen to support it, as simple as that, i'm not good at english, not even at programming, but i can appreciate things makes me write nice code

switch (action.type)
{
    case .Attack: do_attack(); break;
    case .Jump: do_jump(); break;
}

this is simple and readable, if i can't convice you, then there is nothing i can do

Steve Jobs came up with the iPhone when everyone was saying "touching your screen with your fingers is a stupid idea", and look at us now..

All it takes is to try it

May 12, 2023

On Friday, 12 May 2023 at 03:11:49 UTC, ryuukk_ wrote:

>

On Thursday, 11 May 2023 at 23:00:03 UTC, epilogue wrote:

>

On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:

>

Don't you find this code easier to read and review?

        if (target.os == .Windows)
        {
            item("windows");
        }
        else
        {
            item("posix");
            if (target.os == .linux)
                item("linux");
            else if (target.os == .OSX)
                item("osx");
            else if (target.os == .FreeBSD)
            {
                item("freebsd");
                item("bsd");
            }
            else if (target.os == .OpenBSD)
            {
                item("openbsd");
                item("bsd");
            }
            else if (target.os == .Solaris)
            {
                item("solaris");
                item("bsd");
            }
        }
        arrayEnd();

No, I find this harder to review.

. is the module scope operator, which is already going to be difficult for new dlang coders to learn about given that they would end up searching for the meaning of the . character (I speak from my experience learning D).

I haven't reviewed the DIP in full, but a quick search of the DIP for "module scope operator" does indicate that overloading the module scope operator was already called out as undesirable, so I'm not sure why you would use . again here when trying to defend the rejected DIP.

Having read the conversation, but not the DIP, I think the repetition issue is known, but the examples offered don't demonstrate (to me, a random nobody reading this thread) a clear improvement of the language or the code in question.

I will add that this particular case of repetition the DIP seems to be intended to solve reminds me of brace-expansion in bash, where foo.iso{,.sig} expands to foo.iso foo.iso.sig allowing bashers to avoid repetition in some cases of repetitive strings, but it should be evident to anyone subjected to reading someone else's bash script that that reducing repetition with brace expansion does not unconditionally improve reviewability of the code in question.

The syntax doesn't matter, i could have used # or :, what ever, let's focus on the idea first

It's am improvement to me, hence why i advocate for it, i'm not a compiler developper, i can't think of everything, all i can think of is it's going to improve the way i write my code

All it took me to appreciate it was to discover it when i was using a language that happen to support it, as simple as that, i'm not good at english, not even at programming, but i can appreciate things makes me write nice code

switch (action.type)
{
    case .Attack: do_attack(); break;
    case .Jump: do_jump(); break;
}

this is simple and readable, if i can't convice you, then there is nothing i can do

Steve Jobs came up with the iPhone when everyone was saying "touching your screen with your fingers is a stupid idea", and look at us now..

All it takes is to try it

that switch could be further improved with pattern matching, but that's a discussion for a different DIP

May 12, 2023

On Tuesday, 25 April 2023 at 06:41:04 UTC, zjh wrote:

>

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

>

..

Is it okay to use a new keyword enumswitch that is equivalent to with final switch?

Why would you use a new keyword? Use enum switch with a space. Both are keywords already.

1 2 3 4 5
Next ›   Last »