[Scripting] elseif keyword

[Marrub]

This looks ridiculous:

Code: Select all

TNT1 A 0 {
   if(condition)
   {
      // ...
   }
   else { if(condition2)
   {
      // ...
   }
   else
   {
      // ...
   } }
}

Could an "elseif" keyword be added to change it to this?

Code: Select all

TNT1 A 0 {
   if(condition)
   {
      // ...
   }
   elseif(condition2)
   {
      // ...
   }
   else
   {
      // ...
   }
}

[Kyle873]

Couldn't agree more. Right now it feels like it's encouraging people to write horrible code that indents into another dimension.

[DavidPH]

Alternatively, the parser could be made to allow single statements as the body of an if. This could avert other unforeseen consequences of enforcing a particular style, too.

[Major Cooke]

For the love of god, not 'elseif'. Please make it 'else if'. As someone who works with C++ that shit will drive me up the wall otherwise. Similarly to how randi grew tired of people complaining why their ACS scripts won't work.

[NeuralStunner]

As far as I know, the ability to use single-line if/else is what allows "else if" (two keywords) to work in the first place.

Also, I'm 99% sure the commit remark is referring to if+else. Braceless ifs have always worked in ACS, and [wiki=Other_useful_functions]many of the custom functions on the wiki use it[/wiki].

[Gez]

I don't get your point.


Randi's commit comment explicitly says that if you use separate keywords, the only way to do it is with else { if () {} }. else if is not possible. The alternative, therefore, is to make it a single keyword: "elseif". There are also "elsif" and "elif" variants in some languages, if you'd prefer that; but "else if" is out of question.

Also, C++ does not have elseif or equivalent, but the preprocessor does have #elseif and (as an alias) #elif.

[Kyle873]

Similarly to how randi grew tired of people complaining why their ACS scripts won't work.

That's some pretty shit reasoning for doing that. Forcing a style like that just comes off to me as "I can't be arsed to implement it otherwise and deal with people who don't know what they're doing".

This isn't VB.NET. The language itself shouldn't accommodate shitty coders and hold their hand while it's doing it.

[DavidPH]

The real point is that requiring braces has already resulted in a completely unnecessary problem and will almost certainly continue to do so in the future. It will also make certain code much less aesthetic, hurting maintainability. All of this just to accommodate what is an oddly specific early-learner mistake. Quite frankly, it is a problem to be solved with documentation, not restrictive syntax. Either tell new people to always use braces or offer a proper explanation of the grammar. Or both, for that matter. A well defined grammar is good for both new and experienced users, as well as a guideline for the programmer.

[Graf Zahl]

The problem here is not an 'early-learner mistake' but a parser that has some difficulty handling this stuff and is supposed to be superseded in the near future. How much work would you invest there?

[Major Cooke]

That's some pretty shit reasoning for doing that. Forcing a style like that just comes off to me as "I can't be arsed to implement it otherwise and deal with people who don't know what they're doing".

This isn't VB.NET. The language itself shouldn't accommodate shitty coders and hold their hand while it's doing it.

The only thing I was getting at was this:

Code: Select all

if(condition)
   {
      // ...
   }
   //elseif(condition2) //From this
   else if(condition2) //To this
   {
      // ...
   }
   else
   {
      // ...
   }

But like Gez pointed out it might be a problem regardless.
And what Graf has supplied, it's going to be replaced sometime anyway.

Also, I'm 99% sure the commit remark is referring to if+else. Braceless ifs have always worked in ACS, and [wiki=Other_useful_functions]many of the custom functions on the wiki use it[/wiki].

I always thought randi's commit message was to teach people the difference between using braces and not, because rookie mistakes happen. I could be wrong, but still, we all start from somewhere.

Code: Select all

//Broken
if (...)
    Function1
    Function2 //People mistake indenting here for counting as part of the if statement, when in reality, that's not happening. 2 and 3 are being called regardless.
    Function3

//Fixed
if (...)
{
    Function1
    Function2
    Function3
}

[DavidPH]

The problem here is not an 'early-learner mistake' but a parser that has some difficulty handling this stuff and is supposed to be superseded in the near future. How much work would you invest there?

If it is an internal limitation that is going to be fixed, I would say that this issue should be set aside until that time.

[NeuralStunner]

Cooke: For what it's worth, [wiki=Distance]else doesn't seem to need braces either[/wiki].

On the other hand, [wiki=A_quick_beginner's_guide_to_ACS#Flow_Control]there is documentation[/wiki] so I'm not sure what's supposed to be solved there. If people don't care to learn how things are supposed to be done, then how it's done doesn't really make a difference to them. I'd argue that some restructuring to the documentation (and more a more proactive attitude about directing people to it rather than fixing their code for them) would do more good than syntactic ideals.

[Major Cooke]

The guaranteed 'fix' at the end of the road will be DoomScript's coming. As in, DECORATE will become deprecated, kept around as compatibility baggage while encouraging everyone to move to the new language.

@Neural: I know, ACS doesn't have the brackets rule. Which in turn is why I'm still guessing he wants to rectify my mentioned example previously though by forcibly including brackets at any given time an if/else statement is found in DECORATE.

[NeuralStunner]

I'm saying it's not a great reason to do something like that. As a structural limitation to keep the parser from imploding I can understand, but a language needs less "it just works" and more "it works very well".

Building a strong, coherent syntax and then teaching it properly (I.E. good documentation and the willingness to say "go read it") is going to do the most good in the long run. The kind of person who throws up their hands at the first "it doesn't work" is not likely to be making the next Psychic or Reelism, after all.

[Graf Zahl]

The problem here is not an 'early-learner mistake' but a parser that has some difficulty handling this stuff and is supposed to be superseded in the near future. How much work would you invest there?

If it is an internal limitation that is going to be fixed, I would say that this issue should be set aside until that time.

I do not expect the entire DECORATE parser to get 'fixed' just to make the syntax more pleasing to you.