This got mentioned in passing in a thread on the old boards, and I thought I would just bring it up as a topic of interest. I expect it would not be trivial at all to do, and perhaps not even desired among my fellow eScript monkeys...
But what are the chances of a future version of POL (obviously not 096!!) being strongly-typed in relation to variables?
For those scripters familiar only with scripting languages, that might not be clear; 'strong typing' means that each variable is declared with a specific type, and can only hold data of that type. An attempt to assign "232" into an Integer (number) type would either not work, or would result in automatic conversion of that into a number. This would also apply to classes, and would permit 'early binding' behaviors, where the compiler can recognize if you attempt to use an object class member that does not exist; typos in your scripts would become much less problematic (If you accidentally typed "character.cmndlevel" instead of "character.cmdlevel", the compiler would return an error, since the "character" class instance would be clearly defined, and the compiler would know what members the class has)
Besides the ease of catching errors, this -could- increase performance marginally. I don't find POL's performance to be lacking at all, but... ehhh!
All of the above said, this would not be without trouble; Both for the POL Devs, and for scripters.
For the POL devs, well; they'd have to speak for themselves, but I know this would not be trivial at all to implement properly.
However, for POL scripters, it could appear to be a nightmare; It would require much more careful use of variables, particularly when being passed as parameters to functions. I imagine inheritance issues would need to be understood by scripters, so they would know how to pass 'base classes'; for example, to implement a function that can accept both an Item or a Character, but is also able to figure out which one was passed, and be able to access specific members of the individual class. All-in-all, it would end up making a scripter's life much more complex.
So, why am I even mentioning this? Mostly to get discussing moving, and to maybe put a bug in the ear of a dev or two, to see if it's possible to consider in the future!
Long-Term Suggestion: Strong Typing
Strongly Typed means that the types must be enforced, ie you can use string "123" as an integer without explicitly casting it.
What you suggest is having EScript 'statically typed' where types are fixed at compile time, thus having to explicitly state them in our code.
I am not sure that POL would benefit from either of those switches. I think that scripters should be able to walk more loosely in their scripting.
One of the strong points of POL is, that EScript is quite easy to catch up, even for people who have no prior scripting/coding experience, and I'd hate to lose that advantage.
What you suggest is having EScript 'statically typed' where types are fixed at compile time, thus having to explicitly state them in our code.
Code: Select all
int myInt;One of the strong points of POL is, that EScript is quite easy to catch up, even for people who have no prior scripting/coding experience, and I'd hate to lose that advantage.
-
Marilla
My terminology often suffers from excessive fluidity 
ops:
You are absolutely correct about what I am speaking about, of course. I also do happen to agree that it would lose a good bit of flexibility. To be honest, one of the biggest reasons for thinking of this was that in working to upgrade to 096, I have -still- found uses of "mobile.hp" in scripts (luckily, not in anything vital - mostly in scripts to kill off temporary NPCs after sending them to 'jail'), as well as sometimes difficulties when string/numeric data types don't convert as expected (though admitedly, it seems that has gotten a LOT better since 092!)
ops: You are absolutely correct about what I am speaking about, of course. I also do happen to agree that it would lose a good bit of flexibility. To be honest, one of the biggest reasons for thinking of this was that in working to upgrade to 096, I have -still- found uses of "mobile.hp" in scripts (luckily, not in anything vital - mostly in scripts to kill off temporary NPCs after sending them to 'jail'), as well as sometimes difficulties when string/numeric data types don't convert as expected (though admitedly, it seems that has gotten a LOT better since 092!)
Here is what I remember from Pascal as syntax for typed variables.
MyString : string; // Dynamic length string variable. Max length for asll strings was 255 chars I think
MyFixedString : string[20]; // Fixed length of 20 chars. Pascal used the zeroth pos to store string length
MyInt : integer; // Integer from 0...255
MyDouble : double; // This would be a double byte integer. Range 0...65535
My Real : real; // Floating point variable.
The next is a bit sketchy. It's bee a while since I wrote Pascal but I believe this is fairly accurate.
MyArray : array of integer; //Defines a dynamic sized integer array
MyFixedArray : array of Integer [1...10]; // Same as above but the size is limited to 0 through 10 elements.
Multidimensional array sizes can be specified like this:
MyStringArray : array of string [0...20, 4...100, 20...30];
Arrays can be of any type and if I recall you could have one type of array within another type but the syntax escapes me on that one.
Pascal also had a way of specifying user defined types also.
The Type header told the compiler when those were coming up.
Here is an example of a custom type.
color = {black, brown, red, orange, yellow, green, violet, grey, white};
Remember that a lot of what I just mentioned is from memory so there might be some innaccurracies.
The point though is that this would promote a more structured approach to scripting. Variables, all variables, should be defined at the start of the script or function.
Oh well, this post has grown longer than I had intended and it was a spur of the moment response to the thread. Consider this reply an example of unstructured posting.
*chuckles*
MyString : string; // Dynamic length string variable. Max length for asll strings was 255 chars I think
MyFixedString : string[20]; // Fixed length of 20 chars. Pascal used the zeroth pos to store string length
MyInt : integer; // Integer from 0...255
MyDouble : double; // This would be a double byte integer. Range 0...65535
My Real : real; // Floating point variable.
The next is a bit sketchy. It's bee a while since I wrote Pascal but I believe this is fairly accurate.
MyArray : array of integer; //Defines a dynamic sized integer array
MyFixedArray : array of Integer [1...10]; // Same as above but the size is limited to 0 through 10 elements.
Multidimensional array sizes can be specified like this:
MyStringArray : array of string [0...20, 4...100, 20...30];
Arrays can be of any type and if I recall you could have one type of array within another type but the syntax escapes me on that one.
Pascal also had a way of specifying user defined types also.
The Type header told the compiler when those were coming up.
Here is an example of a custom type.
color = {black, brown, red, orange, yellow, green, violet, grey, white};
Remember that a lot of what I just mentioned is from memory so there might be some innaccurracies.
The point though is that this would promote a more structured approach to scripting. Variables, all variables, should be defined at the start of the script or function.
Oh well, this post has grown longer than I had intended and it was a spur of the moment response to the thread. Consider this reply an example of unstructured posting.
*chuckles*
Oh yes. One more thing.
Melanius, I understand your concerns about ease of use but syntax is not always the key to ease of use. One of the biggest complaints I hear about POL is that scripts are so hard to follow because of the includes and how deep they go. Anyone who has tried to follow a hitscript understands that. Syntax is the easiest thing to learn in programming. Trust me I learned Pascal and I came from programming in BASIC. Not Visual Basic. I mean the BASIC that was taught long before Bill Gates hit the scene. That was a VERY unstructured language.
Have faith in your family of POL scripters. If they can follow the distro scripts and learn from those they can learn a little discipline in scripting.
Melanius, I understand your concerns about ease of use but syntax is not always the key to ease of use. One of the biggest complaints I hear about POL is that scripts are so hard to follow because of the includes and how deep they go. Anyone who has tried to follow a hitscript understands that. Syntax is the easiest thing to learn in programming. Trust me I learned Pascal and I came from programming in BASIC. Not Visual Basic. I mean the BASIC that was taught long before Bill Gates hit the scene. That was a VERY unstructured language.
Have faith in your family of POL scripters. If they can follow the distro scripts and learn from those they can learn a little discipline in scripting.
Oh, don't get me wrong. I don't think that POL scripters are no good and they couldn't handle it.
What worries me is new users. Imagine the fun a new user will have by following the tutorial and having his own custom item in a matter of minutes. Then he can build on that and really start learning.
I prefer to be loose and have users learn what good programming techniques are. There's no thing in forcing such things, 'cause they should be learned by experience, especially in a scripting language, which means to build and extend functionality, rather than be hard-coded to provide speed.
What you say about the level of include follow-ups is true. But that is the scripter's fault. We can't blame EScript for allowing him to do so.
When we started re-writing the distro, amongst our rules was not to go deeper than 1 or 2 levels deep in includes. Point is these things are learned as part of your scripting experience. Rather than forcing someone to do something right, we let him found out on his own.
I am not standing against any of this, I just want to make sure that we hear all points of view, so we can base our decision on real issues and facts.
What worries me is new users. Imagine the fun a new user will have by following the tutorial and having his own custom item in a matter of minutes. Then he can build on that and really start learning.
I prefer to be loose and have users learn what good programming techniques are. There's no thing in forcing such things, 'cause they should be learned by experience, especially in a scripting language, which means to build and extend functionality, rather than be hard-coded to provide speed.
What you say about the level of include follow-ups is true. But that is the scripter's fault. We can't blame EScript for allowing him to do so.
When we started re-writing the distro, amongst our rules was not to go deeper than 1 or 2 levels deep in includes. Point is these things are learned as part of your scripting experience. Rather than forcing someone to do something right, we let him found out on his own.
I am not standing against any of this, I just want to make sure that we hear all points of view, so we can base our decision on real issues and facts.
-
Marilla
I agree, Mel; I didn't necessarily so much post this as "I want this!!", but I thought it'd also be an interesting discussion.
So, that brings me to something to add;
How about leaving the 'default' as it is now - having a default class which can handle data of any type at all. Declaring variables as they are now results in this type, and declaring functions as now does the same.
But then create the ability to create variables as instances of specific types of classes, and define functions to only accept them that way. So;
Just as some examples 
Another nice thing that I would think would make this much easier to swallow would be function overloading, or passing 'base types', so that we wouldn't get into a huge mess where we had to write ten different versions of functions.
Just some off-the-wall thoughts
So, that brings me to something to add;
How about leaving the 'default' as it is now - having a default class which can handle data of any type at all. Declaring variables as they are now results in this type, and declaring functions as now does the same.
But then create the ability to create variables as instances of specific types of classes, and define functions to only accept them that way. So;
Code: Select all
var MyVariable;
...
int MyInteger;
float MyFloat;
mobile MyMobile;
account MyAccount;
...
function RegularFunction(who, what, where)
...
function WithTypes(character who, item what, COORD_STRUCT where)
Another nice thing that I would think would make this much easier to swallow would be function overloading, or passing 'base types', so that we wouldn't get into a huge mess where we had to write ten different versions of functions.
Just some off-the-wall thoughts
I can see both sides and I agree that it is important to have folks be able to get a grasp of eScript quickly but I also know, from personal experience, how hard it is to go from unstructured "free style" programming to a structured approach.
One thing that structured programming does fopr you is it causes you to plan out logically what your program is going to do in a step by step format.
ANyway, I know this discussion could go on and on so I'll let it go from my end. Unless ofcourse someone says something that I want to comment on.
*giggles*
Oh yes there is one statement that causes me either go back to an example or the eScript docs and that is the "for" statement. I can never remember the format for that one. I rather like the old BASIC language format of:
for...
next
and then you had the optional "step" that allowed you to modify the incremental value. eScripts "for" is rather cryptic.
But I am glad that eScript resembles Pascal so much. That was my saving grace in learning it.
Anyway, I have to get ready for work.
Have fun.
One thing that structured programming does fopr you is it causes you to plan out logically what your program is going to do in a step by step format.
ANyway, I know this discussion could go on and on so I'll let it go from my end. Unless ofcourse someone says something that I want to comment on.
*giggles*
Oh yes there is one statement that causes me either go back to an example or the eScript docs and that is the "for" statement. I can never remember the format for that one. I rather like the old BASIC language format of:
for...
next
and then you had the optional "step" that allowed you to modify the incremental value. eScripts "for" is rather cryptic.
But I am glad that eScript resembles Pascal so much. That was my saving grace in learning it.
Anyway, I have to get ready for work.
Have fun.