Logical placement for realm parameter

[Yukiko]

I know I am going to kick myself for suggesting this but because I believe in consistency I will anyway.

Maybe not for POL 97 but in some future release I believe that the position of the realm parameter within the "upgraded" function calls should be placed in a more logical location.

I will give the example below to show what I mean.

CreateItemAtLocation( x, y, z, objtype, amount := 1, realm := _DEFAULT_REALM )

To be logical should be defined as
CreateItemAtLocation( x, y, z, realm := _DEFAULT_REALM, objtype, amount := 1 ) as it is in the MoveObjectToLocation function.

I understand why it is the way it is but it's more logical ro have it positioned with the XYZ coords.

Yeah, I know I am the one always griping about change but this is one of those times when logic outweighs my complaints. Besides I keep having to remember to put the realm info at the end of those function calls.

[Xandros]

Realm is an optional parameter (since there is a meaningful default
value for it). It doesn't make sense to place it before mandatory
parameters like objtype, which can't have a meaningful default
value.

Xandros

[Yukiko]

Actually realm is not optional. By the very definition that there is a default makes it clear that it is required. It's just that the developers were kind enough to define a default for us in the em file. If they had not done that then we would have been required to include our own parameter for realm.

If you look at the truly POL 96 unique function, MoveObjectToLocation you'll see the logical placement of the realm parameter. It is placed in this function following the XYZ parameters because this function was created as a brand new function for POL 96 and it is the logical place for it because it is part of an objects location within the "world".

MoveObjectToLocation( object, x, y, z, realm := _DEFAULT_REALM, flags := MOVEOBJECT_NORMAL )

Whereas for all the "upgraded" functions the realm parameter was tacked on the end for compatibility.

By placing it following the Z parameter you do not need to add the flag parameters in other functions.

Example:
Let's say you have this function in a script
ListMobilesNearLocationEx( x, y, z, range, flags, realm := _DEFAULT_REALM )

Now let's say you don't want to use any flags. As it currently stands you have to enter a 0 in the function call where the flags are supposed to be.
ListMobilesNearLocationEx( x, y, z, range, 0, realm)

Here is the logical placement of realm in that function call:
ListMobilesNearLocationEx( x, y, z, realm, range, flags)

So if the realm parameter is moved just following the X parameter you could just ignore the flag parameter if you were not going to use any special flags. This would cut down on a lot of mistakes in scripts. I am sure that many of you have forgotten to throw in that 0 for no flags in those function calls where the realm parameter follows the flag parameter.

Anyway, that's my thinking on the subject.

[Xandros]

[Yukiko]

My original arguement still stands: The realm parameter is not placed logically in the "upgraded" commands. It is in MoveObjectToLocation. This is an inconsistency in the syntax of eScript. One does not want inconsistencies in the definitions of functions. That can lead to confusion and errors. It is not logical. As anyone knows programming (scripting) is based on logic.

[Xandros]

[Yukiko]

I understand those who are scripting with one map will not understand my reason for this request and like I said maybe this isn't for POL 97. For those of us scripting for multiple maps the placement is more logical than the way it is now. It's obvious that had realms been around from day one the realm parameter would have been right zfter the Z parameter as it is with MoveObjectToRealm. Otherwise the developers would have placed realm after the MOVEOBJECT flags in that function as they did in the "upgraded" functions.

I think I have made my point, stated it as succinctly as possible and there is nothing more I need say.