[elseif] in WML

[Elvish_Hunter]

As the last poster in a thread, you can always copy the content of your last post, delete it, put it into a new post and add the edits. This effectively lets people know there is an unread post again.

I know, and sometimes I did it. I just didn't want to accidentally ruin my last post. It's quite easy to do disasters with Ctrl+X and a long message...

[Elvish_Hunter]

The features described in this topic are now merged in master with pull request #139, http://git.io/iYlW_A . Starting from the 1.13.0 version, it will be possible to use [elseif], and all the ConditionalActionsWML tags will perform the following checks about missing stuff:

Code: Select all

Tag          Required items
[if]         [then]
[elseif]     [then]
[while]      [do]
[switch]     variable=, [case], value=

[tekelili]

Just a little off topic: To face this readility problem, I decided some years ago never tabulate [then], [else] and [do] (inside [if] and [while])... and dont think gona change my mind

[AI]

all the ConditionalActionsWML tags will perform the following checks about missing stuff:
[table][row][header]Tag[/header][header]Required items[/header][/row]
[row][cell][if][/cell][cell][then][/cell][/row]
[row][cell][elseif][/cell][cell][then][/cell][/row]
[row][cell][while][/cell][cell][do][/cell][/row]
[row][cell][switch][/cell][cell]variable=, [case], value=[/cell][/row][/table]

Does that mean the following construct is no longer valid?

Code: Select all

[if]
    {SOME_CONDITION}
    [else]
        #complain
    [/else]
[/if]

[Anonymissimus]

[table][row][header]Tag[/header][header]Required items[/header][/row]
[row][cell][if][/cell][cell][then][/cell][/row]
[row][cell][elseif][/cell][cell][then][/cell][/row]
[row][cell][while][/cell][cell][do][/cell][/row]
[row][cell][switch][/cell][cell]variable=, [case], value=[/cell][/row][/table]

I would make sure this construct doesn't turn into garbage once the tables feature is deactivated again though, so that later visitors of this thread can understand it.
EDIT
Just asked shadowm, you should expect this to turn into unreadable text.

[iceiceice]

Does that mean the following construct is no longer valid?

I also use this construct frequently, I hope we don't drop support. I don't remember what UMC I picked this up from.

[zookeeper]

Does that mean the following construct is no longer valid?

Code: Select all

[if]
    {SOME_CONDITION}
    [else]
        #complain
    [/else]
[/if]

Yeah, you can't drop support for that, it's a pretty common thing to do.

[Elvish_Hunter]

Does that mean the following construct is no longer valid?

I also use this construct frequently, I hope we don't drop support. I don't remember what UMC I picked this up from.

Yeah, you can't drop support for that, it's a pretty common thing to do.

Wow. To be honest, I never suspected that such structure was so widely used . I must admit that I never stumbled upon it, perhaps only by sheer luck. So - at least for now - I added back its support in master, http://git.io/RvHROA .
That said, do you want to know why I added it in the first place? Because one time I accidentally forgot to add the [then] tag inside a [if], and of course it didn't work as I wanted. I wasted two days trying to find the bug, while if we had an error message I'd have fixed it in a few seconds.

Code: Select all

[if]
    {SOME_CONDITION}
    [else]
        #complain
    [/else]
[/if]

But isn't it more logical to use one of these blocks?

Code: Select all

[if]
	[not]
		{SOME_CONDITION}
	[/not]
	[then]
	[/then]
[/if]

Code: Select all

[if]
	{SOME_CONDITION}
	[then]
	[/then]
	[else]
	[/else]
[/if]

Besides, having only the [else] without the [then] IMHO is a bad style of coding, that could easily lead to bugs or, at least, confusion. Let's say that, for example, one writes a block without [then] and without putting comments; after six months, he picks again the code and notices that there isn't any [then]. Finally, he ends up wondering "was it intentional, or not?" . Instead, if [then] is mandatory, he is required from the start to use a cleaner style, thus reducing the chance of errors. The fact that a bad practice is widely used doesn't make it a good practice! That's why several languages do not allow it: Lua throws an error if one uses else without then, Python requires to put at least a pass in a indented block below if, while for C++ is perfectly valid; but would you write something like that?

Code: Select all

	int test = 42;
	if (test==42);
	else {
		cout << "Not 42" << endl;
	}

That's more or less like when the engine behaviour about missing macros was changed: at first, a simple error message was dumped to stderr; from version 1.6 or so, a fatal error is thrown and the add-on doesn't load. Was leaving around references to non-existing macros a good practice? No. Was it widely used, although unintentionally? Yes.

Also, while we're at it - should I delete the sanity checks from [while] and [switch] as well?

Just asked shadowm, you should expect this to turn into unreadable text.

Aww... It was a nice and useful feature... Anyway, I fixed my post. Do you and AI mind if I fix yours as well?
What fooled me was the fact that shadowm wrote "For this reason, the odds that the current implementation will persist after this special occasion are pretty low". I intended it as "I may change its implementation later" rather than as "I'll remove tables later". An April Fools' that hit me with four days of delay. Well played, shadowm, well played .

[Spixi]

I don't think that tags like [else] or [elseif] are really needed. The only lead to confusion between different coding styles. Think KISS. There should only one way to do something and this way does it well. So I prefer to stay with:

Sample for IF-ELSE:

Code: Select all

[if]
    {CONDITION}
    [then]
        {STATEMENT}
    [/then]
[/if]
[if]
    [not]
        {CONDITION}
    [/not]
    [then]
        {ANOTHER_STATEMENT}
    [/then]
[/if]

Sample for IF-ELSEIF:

Code: Select all

[if]
    [and]
        {CONDITION_1}
        [not]
            {CONDITION_2}
        [/not]
    [/and]
    [then]
         {STATEMENT}
    [/then]
[/if]
[if]
    {CONDITION_2}
    [then]
         {STATEMENT}
    [/then]
[/if]

Sample for CASE:

Code: Select all

[if]
   {CONDITION}
    [then]
        {STATEMENT}
    [/then]
[/if]
[if]
    {ANOTHER_CONDITION}
    [then]
        {ANOTHER_STATEMENT}
    [/then]
[/if]
[if]
    {YET_ANOTHER_CONDITION}
    [then]
        {YET_ANOTHER_STATEMENT}
    [/then]
[/if]

[vultraz]

I don't think that tags like [else] or [elseif] are really needed. The only lead to confusion between different coding styles. Think KISS. There should only one way to do something and this way does it well. So I prefer to stay with:

By doing that, you are a perpetrator of the very issue you complain of - namely, different coding styles. If/then/elseif/else are very basic logic structures used in many if not all programming languages. It would make little sense not to use them here. Plus, your way only introduces more lines of code, and also is harder for a person reading it to parse logically.

[iceiceice]

Instead, if [then] is mandatory, he is required from the start to use a cleaner style, thus reducing the chance of errors. The fact that a bad practice is widely used doesn't make it a good practice! That's why several languages do not allow it:

I don't think that tags like [else] or [elseif] are really needed. The only lead to confusion between different coding styles. Think KISS.

Sure... but the time to make such a judgment call was before people had already written maybe a hundred thousand lines of WML in total with the existing rules.

[Spixi]

By doing that, you are a perpetrator of the very issue you complain of - namely, different coding styles. If/then/elseif/else are very basic logic structures used in many if not all programming languages. It would make little sense not to use them here. Plus, your way only introduces more lines of code, and also is harder for a person reading it to parse logically.

I am aware that most Ada-like and C-like languages have things like the ELSE keyword or different kinds of loops, but I don't think that they use the KISS principle. In Smalltalk, e. g. there is no ELSE statement. Instead of this the abstract class Boolean declares the methods ifTrue and ifFalse which are implemented in the derivated classes True und False, respectively. I am a proposer of the Unix philosophy "Worse is better". And the more complex an API is, the more bugs will occur. The current way works well and there is no reason to change a running syste

[Elvish_Hunter]

After some research on a few add-ons, I agree that, despite my good intentions, my fellow devs were right, so I decided that the [then] sanity check won't come back; not only this, but I deleted the sanity checks from [while] and [switch] as well (http://git.io/Vs637A and http://git.io/NwxAOQ), because otherwise we would have an inconsistent behaviour between ConditionalActions tags.
After all, that's why I waited until the start of the 1.13.x dev series to push the changes: because there was plenty of time to test the modifications and fix things, without the pressure of a stable release.

[8680]

Perhaps the checks could be moved to wmllint? Common as such [then]-less [if]s may be, it seems to me that it would be for the best to add the — at most — two additional lines of WML required to make them clearer.

(Also, have you tried the [commit] BBCode tag?)

[Elvish_Hunter]

Perhaps the checks could be moved to wmllint? Common as such [then]-less [if]s may be, it seems to me that it would be for the best to add the — at most — two additional lines of WML required to make them clearer.

I tried. But wmllint doesn't have a way to expand macros, and so I ended up getting a incredibly high number of false positives.

(Also, have you tried the [commit] BBCode tag?)

A few times. But most of the time I tend to forget it, and just use the short URL supplied by our IRC bots...