Has Anyone Done a Workaround

[Legacy_Tarot Redhand]

               

In the past couple of weeks I have come to realise that there is (for me at least) something that I use a lot in "real" programming and that is missing from NwN - Enumerations (I double-checked the on-line version of the lexicon). So what I'd like to know is if anyone knows of a workaround for this lack. I figure that if the lack of arrays can be overcome then surely this can.

 

So can anyone point me to a project on the vault that overcomes this lack, please?

 

For those that don't know here is an example in C/C++ - 

enum shape_type {
    circle,
    triangle,
    square,
    rectangle
};

main()
{
    shape_type shape = circle;
    //cut

    switch(shape)
    {
        case circle;
        case triangle;
        case square;
        case rectangle;    
    }
}

TR

               
               

               
            

[Baaleos]

               

I think the closest that nwn native has is constant ints which you name appropriately then use in your case statement.

 

Eg:

 

const int CIRCLE = 1;

const int RECTANGLE = 2;

const int TRIANGLE = 3;

const int OCTAHEDRON = 4;

 

Of course- it might not necessarily have to be an int - although, im not sure how well the nwscript works with strings as the case statements.

 

The limitations you have here are based on the basic nature of nwscript.

If you ported your script to java or lua (via nwnx)

You can work with real types.

               
               

               
            

[Legacy_KMdS!]

               

or a struct,,,,,,,very loosley interpreted.

               
               

               
            

[Legacy_meaglyn]

               

No. Baaleos is right. Use constants and move on. While you could cobble together something that sort of did what you want you'd end up with a huge amount of pain for very little gain. You need compiler support, at least, to get more of the benefits of, say, java enums.  Arrays are much easier to fake since they don't define things that are treated as new types.  You could fake it a bit using structs but then it'll be very cludgy.  What problem are you trying to solve that you can't do pretty simply with constants?

int shape = CIRCLE;
switch (shape) {
        case CIRCLE: 
        etc...
}   

Btw,  scripting is real programming.  It's no less real than java despite being domain specific.  All of the same thought processes are involved. Java has its own quirks and limitations. Many "real" programming languages did not have enums at one point either. We all did just fine without them '>

               
               

               
            

[Legacy_Tarot Redhand]

               

The problem arises when you see a dozen or more if(strMyString=="A1") type statements that cascade 1 after the other which could more easily be solved with enum in conjunction with switch/case. As enums are a data type in those languages that use them, it is so much easier to catch typos using them than with the use of strings. Yes I know you can mitigate against that to some extent by using constants but how many people who post requests for help on here actually do that?

 

PS For some people "Real" programming involves loads of switches to enter each machine instruction individually  .

 

TR

               
               

               
            

[Legacy_meaglyn]

               

That form of "real" programming does not have enums... I think java did not get enums until java 5 so you don't have to go back to vacuum tubes and plug boards to have to get by without enums.

 

In java 7 you can use strings as cases in switch statements, but you don't use that with enums. In nwscript if you use constant string values you can use the those names in the if and avoid the typo issue. There is no difference in nwscript between a switch/case statement and a chain of if/else if statements. 

 

You see some people do the const string thing with their local variable names in their systems too, which is often a good practice if you are not pushing up against the limit of global symbols.

 

The problem you are trying to solve is really best solved with const string and is not really related to enums anyway.

 

 

Cheers,

meaglyn

 

P.S, your PS should be after your TR or it's not a PS...

               
               

               
            

[Legacy_KMdS!]

               

There is no difference in nwscript between a switch/case statement and a chain of if/else if statements. 

This is actually true. You don't have the processing of switch/case statements like you do in other languages. switch and if/else statements are processed identically.

               
               

               
            

[Baaleos]

               

I do think that the nwscript language has difficulty with strings for case statements.

I am just remembering back to the way SIMTOOLs did the case statement for the commands.

Basically it converted the first character of each command into an int via FindSubstring (against the alphabet)

then it used that in a case statement - which then subdivided into if statements on each individual command.

 

You could end up having to write more complicated code just to get the sort of coding mechanic that you want.

It does feel easier to just use const ints and name the variables appropriately.

 

The only issue you might run into, is accidental re-use of int values - but that is perfectly fine in coding and scripting, as long as they are only used in specific areas of functionality that prevent accidental re-use.

 

This is where nwscript kinda has a downfall.

 

 
ABILITY_DEXTERITY  = 1;
 

 

Well...

 
VFX_DUR_DARKNESS = 1;
 

 

NWScript has all their consts in the same file. (NWScript.nss - or somewhere similar)

 

As a good practice, you should try to make sure that your constants are kept segregated and coherent as possible, not coupled to other systems that are irrelevant.

Eg: ABILITY_DEXTERITY   Shares the same value as VFX_DUR_DARKNESS.

      They clearly have different meanings (purpose), but their in the same file, and exposed / defined within the same scope.

       NWScript.nss could be seen as a somewhat 'god file', but I suspect it was built that way for our benefit.

 

If you plan on re-using integer constants, I would recommend keeping constants of a specific purpose, inside a specific constants include file.

Only add it in when needed, and certainly prefix/name them appropriately.

               
               

               
            

[Legacy_Tarot Redhand]

               

Alas, some of what I was saying must have got lost in translation. In the UK when you put something in quotation marks in the manner that I did (no not every time just when highlighting a multi-word concept) I am saying I don't really believe it. When I include a smiley/emoji I am saying this is tongue in cheek (ie humorous intent), not to be taken seriously.

 

TR

               
               

               
            

[Baaleos]

               

Sorry, wasn't a 'lost in translation' moment.

I'm actually in work at the moment, so I can only briefly flick onto the forum here and there.

I am ashamed to admit it - but I didn't read your post fully. '>

I just posted what I recalled about NWScript and case statements - randomly.

If you covered the subject - oh well. :-)

               
               

               
            

[Legacy_meaglyn]

               

No. I understand the quotes.  The emoji you used was more of an obnoxious one than a wink or smile, though.  But language is important. You start drawing that distinction and soon you may believe it.  Not a big deal, none of that is important to the real issue at hand (unless you meant to put a smiley/winkey on the whole original post '>.  My point is really that you get the most benefit you can by using constants. And since your example is a string and enums really aren't about strings it makes more sense to just do the if (foo = MY_STRING_1) ... thing.

 

@Baaleos,  re-using an int value for multiple constants is not an issue. Think of a set of constants (the ability ones) as an enumeration. You'd never write a switch that expected ability constants and VFX constants from the same variable (or if so remind me never to use any of your code '>  All those constants are just there to make it easier to read and write the code. 

               
               

               
            

[Legacy_Tarot Redhand]

               

I am sorry you found the whistle emoji obnoxious. To me it is the act of pretending to look innocent having just gently teased someone (immediately before they thump you in the shoulder).

 

I don't disagree about the constants as I did mention them in my last but one post.

 

I didn't know that NwN script didn't process switch/case the way I expected it to. Thanks for enlightening me. Mind you, I am still inclined to use them in preference to long chains of if() statements as, for me anyway, it just seems cleaner.

 

TR

               
               

               
            

[Legacy_meaglyn]

               

I can't reach your shoulder '>

 

I totally agree that a switch statement, especially if spaced and formatted well, is easier to read than a chain of ifs for anything more than a handful cases.  I prefer them too.  But not for strings since that doesn't work in nwscript.  Nearly violent agreement as they say... 

               
               

               
            

[Legacy_KMdS!]

               

I find case easier to read too, and never take me too seriously, I am always in a hurry and sometimes I don't have time to take a light hand at things....but then, like this second I am feeling a bit wonky doodle.......lol

               
               

               
            

[Legacy_Lightfoot8]

               

This is actually true. You don't have the processing of switch/case statements like you do in other languages. switch and if/else statements are processed identically.

 

Not completely true,  Every Case Label will have a comparison for it.  there will be no nice look up "Jump Table" that switches normally generate in other languages.  The only difference in the code, between the Switch and a bunch of If .. else if statements, Is the break.   It is optional in the Switch and  always encoded at the end of every 'If' block.   Even if it jumps over nothing. 

 

 

 

 

As far as emulating enumeration in NWNScript,   I guess you could script something,  However you would lose all the Value of it. Simply because all of the Processing of the enumeration would happen during run time, when it should be happening during Compile time.    

 

 

enumeration is a limitation of the compiler.   If SkyWing is still around you may be able to get him to add it to his. I'm pretty sure,  He did add the ability to use strings  in Case  Statements to his Compiler. 

 

The Look Up Table for case statements is a limitation of the NWN Virtual Machine.    There is just no instruction set to pull it off.