A procedure which is called when a variable changes

ID:259786
 
Aug 1 2004, 12:46 am
There should be a procedure which is called when a certain variable changes. This will help BYOND a lot, especially on updating HUDs. (It would reduce a bit of lag if you are using loops to update it, and it will reduce space of coding if you call it every time the "HP" variable is changed.)

This could be an idea for the procedure's args.

datum/ChangeVar(varname as text) // I'm not good at creating names.


Just an idea,
~~> Dragon Lord
Aug 1 2004, 12:54 am
I think something like that would do well also, seeing as how HUDs have become the new thing, it would be a good idea in general.
Aug 1 2004, 1:33 am
Why not just use a proc that changes the var, and have it update the HUD at the same time?
Aug 1 2004, 1:44 am
In response to Hazman
Hazman wrote:
Why not just use a proc that changes the var, and have it update the HUD at the same time?

People are lazy.

They don't want to edit their whole game so "src.blah += 1" turns to "ChangeVar(src, "blah")". It'd be a whole lot harder making procs because you'd have to either make some complicated system of adding, subtracting, etc... or make tons of other procs for different things.

~~> Dragon Lord
Aug 1 2004, 6:20 am
In response to Hazman
Hazman wrote:
Why not just use a proc that changes the var, and have it update the HUD at the same time?

This is the good programming practice. Procs that exist to return the value of or change a variable are known as "accessors". Having accessors allows for some very good things, like not initializing a variable until it's needed (especially good for lists and things that would be taking up memory when they were never needed otherwise), being able to debug when something is changing that you don't expect, letting you make sure the variable is only set to legal values, letting you do operations on a value before returning it, and allowing you to change how the information stored in the variable is generated without having to change code elsewhere.

In professional coding, a common approach for variables that have accessors is to prefix them with an underscore, which lets people know they shouldn't use the variable directly but should use the accessors, like so:

var/_max_health
var/ate_superpill

proc/MaxHealth()
    if (ate_superpill)
        return _max_health + 5
    else
        return _max_health

proc/SetMaxHealth(health)
    if (health > 1)
        _max_health = health
    else
        _max_health = 1

    UpdateHealthHUD()


This example shows several of the things mentioned above. You could just have a max_health variable, but by using an accessor here we get many benefits.

First off, we're able to check for other factors that might increase the maximum health in MaxHealth(), so if you've eaten a superpill, your maximum health is higher than usual, but since that's a temporary thing we don't actually change _max_health itself.

Second, in SetMaxHealth() we're able to check for legal values. If for some reason there is an attempt to set maximum health below 1 (which would mean you are permanently dead!) we don't allow that, instead interceding and setting it to the minimum of 1.

Finally, SetMaxHealth() triggers updating the health HUD, since the health has changed.

The key to this is to never ever use an underscored variable anywhere but inside the accessors for it. Everywhere else must use the accessors for this scheme to work.
Aug 1 2004, 10:36 pm
It'd be nice, except that it would lag to... somewhere really laggy. =) The approach Deadron suggested works just fine.
Aug 2 2004, 12:20 am
In response to Unknown Person
GOOD IDEA! LET'S GO SAVE 10 KEYPRESSES BY DOUBLING THE CPU USAGE OF BYOND! YOU DESERVE A PULITZER!
Aug 2 2004, 12:34 am
In response to Garthor
Garthor wrote:
GOOD IDEA! LET'S GO SAVE 10 KEYPRESSES BY DOUBLING THE CPU USAGE OF BYOND! YOU DESERVE A PULITZER!

If your not going to say anything helpful, dont.
Aug 2 2004, 7:34 am
In response to Critical
I'm being helpful by pointing out extremely major flaws in this idea. "Being helpful" doesn't always mean "being nice."
Aug 3 2004, 8:01 pm
In response to Crispy
It'd be nice, except that it would lag to... somewhere really laggy. =) The approach Deadron suggested works just fine.

Deadron's solution would be just as laggy and having built in support for making properties that call certain functions when setting or retrieving values would be much cleaner looking(it's very slick in VB and C#). But it is one of those things that would be nice to have but not essential.
Aug 4 2004, 12:33 am
In response to Theodis
Only if you applied it to every single variable you used.

it's very slick in VB and C#

I don't know about C#, but, well... VB isn't exactly renowned for efficiency. =P

It's certainly nice to have it available, but as you say it's not essential.
Aug 4 2004, 1:58 pm
In response to Crispy
I don't know about C#, but, well... VB isn't exactly renowned for efficiency. =P

It's just different notation for a procedure call. So it's just as fast as using a proc which is in fact slower than just assigning a value but if you're going to use Value() and SetValue() why not just stick with cleaner notation?
Aug 5 2004, 10:32 pm
In response to Theodis
I repeat: Value()/SetValue() would only be as slow as automatically calling a proc upon assignment if you had a Value()/SetValue() pair for every single variable you ever accessed or assigned to anything; which is unlikely.

It would be somewhat less slow if there was a flag of some sort attached to variables that enabled the assignment-calls-procs behaviour, but you still need to check the flag.

In any case, it's not going to happen and there are dozens of things that are more important. So I don't really see much point in this argument. :-)
Aug 6 2004, 1:50 pm
In response to Crispy
I repeat: Value()/SetValue() would only be as slow as automatically calling a proc upon assignment if you had a Value()/SetValue() pair for every single variable you ever accessed or assigned to anything; which is unlikely.

It would be somewhat less slow if there was a flag of some sort attached to variables that enabled the assignment-calls-procs behaviour, but you still need to check the flag.

That's why I suggest doing it like VB or C#. You never even define them as variables you just make the proc be a property. Here's how it works in VB.

Public Property Get HP() as Integer
HP = m_hP 'Set the return value to the internal value
End Property

Public Property Set HP(param as Integer)
if(param < m_maxHP) then
m_hP = param
else
m_hp = m_maxHP
end if
End Property

You never actually define an HP variable but if you try doing

theobject.HP = 5

it calls the set property and a similiar thing happens when you try and access HP. If you only define one or the other then you are limited to either reading or writing to the variable depending on which you did. All the other variables defined behave as normal. This is very slick and clean looking. It's a wonder other languages haven't started doing this yet.

[Edit] This doesn't even make the game run any slower since all those assignments and gets are mapped at compile time just as if you would have used procs instead. So effeciency isn't even an issue. It's just a matter of making code cleaner and easier to write.

In any case, it's not going to happen and there are dozens of things that are more important. So I don't really see much point in this argument. :-)

There have been plenty of features added in the past to make source code look cleaner like having the compiler read scope by indentation rather than braces. Stuff like this isn't critical but is very good for cleaning up source code and making it more readable and easier to write.