ID:120283
 
Not Feasible
Applies to:DM Language
Status: Not Feasible

Implementing this feature is not possible now or in the foreseeable future
This is a re-post of a feature request that was deemed not feasible. The content was revised to make the implementation of this as easy as possible.

The short of it is a request to implement variable and proc visibility: public, protected, private with public being able to get called from anywhere, protected from objects that pass an if(istype(sender, owner.type)) and private from objects that pass an if(sender.type == owner.type). This would only be in effect at compile-time. Visibility definition would not be mandatory and would default to public to ensure compatibility with existing dm code.

The reason for the request is to protect coders from themselves. In large project, such as Space Station 13, which I code for, variable visibility is absolutely required, because no one person understands the entire source and cannot foresee what the direct editing of variables would do (skipping setters). Setting variables to protected and setters to public would make this problem much more manageable.

Firstly, as anyone else, I don't know how precisely the Byond compiler works. I am assuming that at one point it however creates one or more lists of existing variables. If not, it uses some method for checking variable existence which triggers an error if a variable is how defined.

If defined variables lists are used:
- I propose visibility is included in these lists and when variables are checked that they exist, a second check is done immediately after the existence check which only checks if the variable can be seen from the caller object. If it can't, it throws an error.

If checks are done for each variable call at a time:
- I propose the existence check in the procedure or method that handles this is immediately followed by a visibility check.

As stated above, the checks would simply be the equivalents of:

if public: return 1
if protected: istype(sender,owner.type) ? return 1 : return 0
if private: sender.type == owner.type ? return 1 : return 0

With the sender being the object which is calling the variable (most commonly referred to as src) and owner being the object which is being referenced.

So:
/obj/item/axe/New()
var/obj/item/sword/s = new/obj/item/sword(src.loc)
s.name = "Great sword"


In this example at the very last line the sender is of type /obj/item/axe and the owner is of type /obj/item/sword.

In this variation I don't expect the implementation of such a feature would be overly complex, and yet it would add a much needed break for the communities which have large projects on their hands. I would greatly appreciate it if it was implemented. I think this is the most bare-bones implementation possible, so if even this is deemed not feasible I will stop bugging you about it. Thanks for your time.
Unfortunately, this would probably still be very complicated to add. The compiler is one of the most complex and least-understood parts of BYOND.
The reason the previous request was deemed infeasible was at its core. Trimming helps nothing; the basic concept is simply incompatible with our language.
It's a huge shame tho. It would be an incredibly useful feature for games which have been in development for years, with changing 'generations' of coders contributing to them.