ID:134363
 Oct 12 2006, 2:03 pm
|
|
Why is it possible to add to a null variable? null in itself should really not be able to take on another type by addition, just by setting the variable equal to something else. I'm just pointing this out because it seems semi-illogical to me to allow this in the first place.
| |
:O. The thing is that I don't see how adding anything to null is the right thing for it to do, as null should (quite literally) mean 'nothing,' as opposed to 'whatever you want it to be.'
| |
In most dynamically-typed languages, null evaluates to 0 when used in a numerical context. It may sound odd, but it's usually the logical thing to do.
| |
Crispy wrote:
It may sound odd, but it's usually the logical thing to do. Actually, in German "null" stands for "zero" and in Dutch "nul" stands for "zero". I think the guy who coined the word was German. So, yeah, it DOES sound correctly as opposed to odd. | |
I'm glad BYOND works this way...
Most of the variables I program end up being defined as null variables... I often do not assign a default value to them in their initial declarations, even when I know what type it will be later (number, text string, etc)... So it's nice that BYOND allows me to later use these null variables for whatever I want to, without my having to tell it ahead of time... It intuitively handles changing these null variables to whatever type I put them to use as... I'm not sure I see any point in forcing a variable to remain a "null" variable, anyways, even if that sounds ratiional... What can you do with a variable that forever remains null? It simply makes sense that BYOND allows that variable to act like a blank slate... | |
SuperSaiyanGokuX wrote:
I'm glad BYOND works this way... This is generally not a good practice to get into for anyone who wants to get into C++, though. An uninitialized variable is a very bad thing. I'm not sure I see any point in forcing a variable to remain a "null" variable, anyways, even if that sounds ratiional... What can you do with a variable that forever remains null? It simply makes sense that BYOND allows that variable to act like a blank slate... It wouldn't have to remain null forever. Just until you reset the var with the = operator. | |
This is generally not a good practice to get into for anyone who wants to get into C++, though. An uninitialized variable is a very bad thing. More-modern languages like Java, C#, D, and many other programming languages do automatic initialisations of variables, usually to 0 or NAN. C++ was invented in the early 80s, you know. It's even older than I am. ;-) Python, DM's closest brother, is also a typeless language whose variables do not require initialisation. | |
Audeuro wrote:
This is generally not a good practice to get into for anyone who wants to get into C++, though. An uninitialized variable is a very bad thing. Correction: A programming language that does not automatically initialize variables is a very bad thing. ;-) It shouldn't have to be up to the programmer. The performance hit from initializing everything is unnoticeable (and you usually have to do it anyway in C++; just indirectly), and it goes a long way to preventing odd bugs. | |
What might be nice is to have a special NAN symbol which doesn't allow those sorts of operations, though.