Global Functions

[Inverness]

Originally Posted by Skyld

There's no point. It takes almost no effort to type (@ "Control-NPC").functionname(); or this.join("classname");, and adding things like this just promotes laziness and makes things more complicated. :/

Those are both bad reasons. Classes get disorganized easily if you have many utility functions and things like I do and I don't want the functions from the class being added to the object for stuff like that.

Having global functions would make it easier on those who are unfamiliar with the system. Its called encapsulation and I try to practice it in just about everything I do. I'd love to be able to reorganize how something works and still have other scripts on the server work correctly because of the global functions. That is why GS1 still works, yes?

And please explain how it makes things more complicated, I can't see anything complicated with adding another space to the function lookup. It seems like you're worrying about how badly newbie scripters can **** it up instead of focusing on the good and thats irritating. Having global functions easily accessible to novice scripters would just make things easier.

So far I've seen bad reasons as to why a simple new feature shouldn't be added to gscript. Graal has a crapload of global functions and I suppose thats just too much for us mortal scripters to handle.

[Twinny]

Originally Posted by Inverness

Those are both bad reasons. Classes get disorganized easily if you have many utility functions and things like I do and I don't want the functions from the class being added to the object for stuff like that.

I'd rather a messy class over a messy Control-NPC

[Inverness]

Originally Posted by Twinny

I'd rather a messy class over a messy Control-NPC

Control-NPC can join classes.

[Twinny]

Originally Posted by Inverness

Control-NPC can join classes.

So can everything other object which allows access to functions which, in turn, provides your precious 'global functions'. So instead of asking for an update which lets you use one less word and a dot, how bout we use what is already there? And before you go all, "but lol global functions already exist!", I'd say there'd be quite a difference between hard coded global functions and gscript ones. Inheritance is more likely. (achieveable by classes!).

Request actual features...not just solutions for pure lazyness. Also, don't go running around calling it 'encapsulation'. Encapsulation is like the process of encapsulating a udp/tcp header/data into an ip packet. For gscript, encapsulation would be more like taking a piece of data and adding it to a self-sufficient container...which undermines the point of 'global functions'. Funilly enough, this could be more readily achieved with classes.

When requesting something, try explaining what it will achieve and how the current system can't easily achieve the same effect

[Inverness]

You know, I plan to go into game development/programming in my future and Graal is about the best amateur platform there is, however it makes it really hard to practice OOP principles sometimes.

Originally Posted by Twinny

So can everything other object which allows access to functions which, in turn, provides your precious 'global functions'. So instead of asking for an update which lets you use one less word and a dot, how bout we use what is already there? And before you go all, "but lol global functions already exist!", I'd say there'd be quite a difference between hard coded global functions and gscript ones. Inheritance is more likely. (achieveable by classes!).

Wrong, Global functions are separate from the existing object types and not inherited, they're global. They're not involved with inheritance at all. Inherited functions are part of the local object. Thats obvious from reading the Wiki.

Originally Posted by Twinny

Request actual features...not just solutions for pure lazyness. Also, don't go running around calling it 'encapsulation'.

There is a difference between joining a class and adding another space to the function lookup.

Originally Posted by Twinny

Encapsulation is like the process of encapsulating a udp/tcp header/data into an ip packet. For gscript, encapsulation would be more like taking a piece of data and adding it to a self-sufficient container...which undermines the point of 'global functions'. Funilly enough, this could be more readily achieved with classes.

"Encapsulation describes the ability of an object to hide its data and methods from the rest of the world - one of the fundamental principles of OOP (Object Oriented Programming)."

Encapsulation means people should be able to use my or anyone else's scripts without knowing how they work, this is the reason I want catchEvent() to work with dynamic function events.

Classes add their functions to the local object, something I don't want, or else I would simply put all the functions I consider "global" and join it to everything, however that would screw up the getfunctions() and such. So instead I divide it up between classes and it becomes disorganized for simple functions such as putnpc3() that don't really fit in a category (and if that happens I just drop it because there is no simple way to make it available everywhere), it also makes it harder on new scripters to the server. I'd rather not be the sole scripter on the server that constructs the main system and if I want my systems to work with others well, encapsulation should be practiced.

Originally Posted by Twinny

When requesting something, try explaining what it will achieve and how the current system can't easily achieve the same effect

Like I believe I said, it will make it easier for new scripters or scripters that aren't myself since they don't know how the server ticks, and having all the functions available in one space would make it easier for them since if I reorganize how things work internally they wont get confused. I'd love to be able to present a list to a new scripter or such and tell them thats how you work the server.

Also I like sharing alot of the things I make and global functions would allow something to interface with scripts on another server easily.

Its like standardization, many servers have different ways of organizing their scripts that are good or bad and having custom globals allows different things to work together easier by providing a common space for them to interact.


Its irritating really, I ask for a simple single addition to the function look up and nobody can actually give a good reason why it shouldn't be included and actually explain it at the same time.

[Twinny]

Originally Posted by Inverness

"Encapsulation describes the ability of an object to hide its data and methods from the rest of the world - one of the fundamental principles of OOP (Object Oriented Programming)."

Which is achievable like so

PHP Code:

class CPoly {
    int x, y;
  public:
    void set_vars (int,int);
    int getarea () {return (x*y);}
}; 


With that, only the local object can access x,y and everything else will have to use the two functions to interact with the variables. This is an example of how you hide data/methods in OOP languages. Global functions do not promote clean OOP programming standards.

Unless Stefan implements protected variables sometime soon (something I actually suggested a while ago), this isn't possible in gscript and global functions don't fall under the encapsulation umbrella.

Encapsulation isn't referring to protecting your code from other coders . You could achieve the same effect by having a class with private functions and make sure only you can read the class. It's making sure you follow OOP rules and only allow the local class have access to it's variables.

Nothing should ever need access to everything at any point. Classes can be nicely labeled ("mud_functions", "magic_functions"), and new scripters will be able to find what they are looking for alot easier than sifting through a massive Control-NPC script. This also means that an item object can't turn a player into a duck and plants don't spit out weapons. Global functions are just messy and lazy.

And yes, I realize there are hard coded global functions. I was suggesting that you could happily follow the concept of inheritance using classes to achieve the same effect...alot more cleaner as well.

[Inverness]

Originally Posted by Twinny

Which is achievable like so

PHP Code:

class CPoly {
    int x, y;
  public:
    void set_vars (int,int);
    int getarea () {return (x*y);}
}; 


With that, only the local object can access x,y and everything else will have to use the two functions to interact with the variables. This is an example of how you hide data/methods in OOP languages. Global functions do not promote clean OOP programming standards.

Don't start comparing GScript to other languages. Btw, I'm pretty sure I never said global functions were part of encapsulation. They're for compatibility and interface. Which is something needing on Graal because of the lack of standards.

Originally Posted by Twinny

Unless Stefan implements protected variables sometime soon (something I actually suggested a while ago), this isn't possible in gscript and global functions don't fall under the encapsulation umbrella.

See above.

Originally Posted by Twinny

Encapsulation isn't referring to protecting your code from other coders . You could achieve the same effect by having a class with private functions and make sure only you can read the class. It's making sure you follow OOP rules and only allow the local class have access to it's variables.

No, what I mean by encapsulation is that I could have others use my scripts with full functionality without knowing how they work. I don't know what you mean by limited variable access considering this is GScript we're talking about.

Originally Posted by Twinny

Nothing should ever need access to everything at any point. Classes can be nicely labeled ("mud_functions", "magic_functions"), and new scripters will be able to find what they are looking for alot easier than sifting through a massive Control-NPC script.

Uh, first of all, the global list would be written down in a format like in the Wiki in a commented-out weapon labeled *FunctionList or so, second, there is a find button. It would be no different than looking for the global functions on the Wiki, except mine would actually be documented

Originally Posted by Twinny

This also means that an item object can't turn a player into a duck and plants don't spit out weapons.

I don't see how thats even related to global functions, but that would be interesting to do.

Originally Posted by Twinny

Global functions are just messy and lazy.

I have yet to be convinced as to why, considering what I would use global functions for. Its not like I'm going to make everything global or something. It wont be nearly as messy as the hard-coded global functions already are.

Originally Posted by Twinny

And yes, I realize there are hard coded global functions. I was suggesting that you could happily follow the concept of inheritance using classes to achieve the same effect...alot more cleaner as well.

Like I said, using classes aren't like adding another function lookup space. I don't want certain functions added to the function/variable list of the object.

Edit: These are the functions I would make global on Val Dev:

PHP Code:

clientFunction()
clientFunction2()
error()
import()
mudAddItem()
mudApplyItem()
mudFindItem()
mudRemoveItem()
putNpc3()
reflectObject()
//#CLIENTSIDE
addHistoryMsg()
addMsg()
addObject()
addReflection()
clearMsgs()
consoleMsg()
disconnect()
hideHud()
import()
reconnect()
refreshInventory()
serverFunction()
serverFunction2()
showCharacterSelect()
showHud()
showInputDialog()
showInventory()
triggerAllObjects()
triggerAllWeapons() 


It doesn't look very messy to me.

If you look at the Wiki, you'd see over 100 global functions that GK has added just for itself, many of which point to functions in objects in the same manor that I would do myself, obviously its not so messy if GK does it.

[Twinny]

Originally Posted by Inverness

If you look at the Wiki, you'd see over 100 global functions that GK has added just for itself, many of which point to functions in objects in the same manor that I would do myself, obviously its not so messy if GK does it.

GKs mud functions are hard coded into the NPC-Server

Originally Posted by Inverness

Uh, first of all, the global list would be written down in a format like in the Wiki in a commented-out weapon labeled *FunctionList or so, second, there is a find button. It would be no different than looking for the global functions on the Wiki, except mine would actually be documented

Nothing stopping you from doing this with classes. It can be organized in exactly the same way .

And you're right, gscript is not like other languages which makes it confusing when you bring up OOP programming concepts like, "encapsulation" and even quote them then try to relate it to different concepts .

Pretty sure the burden is on you to prove why these updates are necessary: not the other way around.

[Inverness]

Originally Posted by Twinny

GKs mud functions are hard coded into the NPC-Server

Those are global functions pointing to object functions, obviously you're not understanding dynamic globals would do the exact same thing.

Originally Posted by Twinny

Nothing stopping you from doing this with classes. It can be organized in exactly the same way .

How many times do I have to say it? Classes are unnecessary for a small amount of functions, especially when I don't want them added to the function/variable list for the object.

Originally Posted by Twinny

And you're right, gscript is not like other languages which makes it confusing when you bring up OOP programming concepts like, "encapsulation" and even quote them then try to relate it to different concepts .

Same with your private variables. I explained my reason for practicing Encapsulation in an earlier post.

Originally Posted by Twinny

Pretty sure the burden is on you to prove why these updates are necessary: not the other way around.

I do not think so. The 'update' is an addition of one object to the function look up, something so simple is easy to add (or should be) and would require no/minimal effort so there should really be no reason NOT to do it.

Please tell me why GK is allowed to have global functions pointing to object functions yet we're not? When they're certainly possible dynamically as Stefan has said. I'm going to be honest and say absolutely nothing will convince me why Global functions shouldn't be allowed until this is explained.