Global Functions
 

Why haven't they been implemented yet? We even have function objects now but no global functions yet, its not that hard to do I'm sure. Don't like using classes for things that should be global anyways.

I am not sure how you magically expect global functions to work internally in the script engine.

Just use classes. :/ They aren't that inconvenient.

We have dynamic global variables and objects, why not functions? I doubt it would take that much of an adjustment. Just make the function lookup look at something else between the local functions and the globals. Perhaps the Control-NPC? I had originally thought functions in there should be global by default but was rather disappointed.Class functions show up in getVarNames() and getFunctions(), icky. Global functions are just easier since you don't need to remember what class the thing is in or maintain classes so they match up to a system as you update it.

Global functions are techincally possible, but they make programming actually much harder. It is making it even harder to find where the function is declared. We already have global variables, and we should not repeat that mess with global functions. It is much cleaner to put the functions in an npc and call NPCName.function(), or put it in a class.

I suggested only functions in Control-NPC would be only ones qualifying as global, it would not be difficult at all to find out where they're declared if that is the case.
Simple enough.

I'm not suggesting global functions be declared the same way that global variables are (since that would be a horror as you're saying), just that when the Control-NPC is compiled its functions added to the global list or something.

So basically, for the function lookup, if there is no prefix it would look at:
Local Object (this.) -> Control-NPC -> Static Globals.

could be nice

Why not simply use MyFunctionsNPC.function() ?

Scripter's are lazy, and classes is just a hazzle when there's alot of them

It could be nice with global functions that would make it so you couldn't make more functions with the same name, for example when you make another onCreated() event or make two functions with the same name, it will cause an error

etc.. in the end you get confused, but that was kinda a bad example, but if you could create global function it would help for example the main systems of the server, for example the mudlib that servers lately are interested in.

Yes it works and I do use it in the cases where I need to, but its not preferred when you have lots of different groups of functions in different weapons/objects or classes. And it just looks bad next to the globals that Graal has :(

For the classes, rather than having to join small utility classes to everything that uses it you can just join it to the Control-NPC and then everything can use it, including the random LAT with little knowledge of scripting.

Having globals puts everything on the same plate and would make it easier for people unfamiliar with the system. I don't think its asking much to make public functions in the Control-NPC global (and those with a global_ prefix in the function name only?). Since they would only work in the Control-NPC it would the massive chaos of someone not knowing where the global function is declared.

Bump

I would appreciate a response.

Still seeing it as bad coding style.

The negatives you stated in first post are invalidated by using the Control-NPC for global functions only.

I don't see how its bad coding style to have a single additional location in the function-lookup process.

Local Object -> Control-NPC -> Static Globals

There is nothing confusing about that. It puts all the globals in one bag so you can't miss them.

I mean, they would only be placed in the Control Npc so that it won't be a hard to find the functions when necessary.

I completely agree with this as it would be a nice addition to servers period

I don't think Stefan should honestly have to go through that just to save yourself from having to join a class or putting a weapon name in front of the function. (i.e. "FunctionsWeapon".doThingy())

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.

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

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 :whatever:

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.
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.
There is a difference between joining a class and adding another space to the function lookup."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.
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.

Which is achievable like so
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 :whatever:. 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.

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.
See above.
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.
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 :whatever: I don't see how thats even related to global functions, but that would be interesting to do.
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.
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:
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.

GKs mud functions are hard coded into the NPC-Server :rolleyes:

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

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 :rolleyes:.

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

Those are global functions pointing to object functions, obviously you're not understanding dynamic globals would do the exact same thing.
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.
Same with your private variables. I explained my reason for practicing Encapsulation in an earlier post.
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.