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