Immutable vs. Other
BlitzMax Forums/BlitzMax Beginners Area/Immutable vs. Other
| ||
| Can some of you smarter, younger, programmers explain the rational behind having Immutable types? Specifically, "Strings", or the new .NET BigInt type, or anything else? Second, In BlitzMAX, does it use Immutable types? Integer, Floats, Strings, custom, etc? Third, as it relates to mathematical functions like the new .NET BigInt type, my old brain just can't get around why someone would waste months of programming effort, money, research, etc, on a type that is supposedly intended for use as a type that is going to be used multiple times, with values changing rapidly, and often, but it makes a completely new copy of itself everytime anything happens to it, as in add +1 to the value, you get a new copy of the old variable??? what???? Please help an old man! LOL. What is the reasoning behind this? |
| ||
| All/most primitive types are immutable (in a sense, I suppose - I'm hesitant to categorize pointers or references as immutable). Strings aren't exactly primitives, but we'll consider them as such. Strings in BlitzMax are immutable, you cannot change them at runtime without doing things you're not supposed to be doing. One particularly good reason for having immutable types is simply that they do not change. What you put in will always be what you get out. If you pass a string to a function, the function can't change that string. It could create a new string that is a concatenation of the input string and something else or it could create an array with substrings of the input string, but it will never change the string you give it. It's a guarantee that your data isn't going to change. All types below Object other than String are mutable. Arrays can have their elements changed, any field of any type you pass around can be changed, etc. You can certainly treat a type as immutable, but there's no good way to implement this without access qualifiers, which BlitzMax does not (and probably never will) have. Basically, a half-assed test for mutability is this: if you pass it to a function, will the value you passed in be different when the function returns? Not the return value of the function, just what you gave it. Saying an Int is mutable because you can use Int Var or Int Ptr doesn't make an Int mutable, by the way. I don't know anything about the .NET BigInt type, so I'm going to ignore anything you've said about it, but I'm guessing it's immutable, which would be perfectly reasonable. It's likely a number, and numbers never change, so it's obviously going to be immutable. The sum of two numbers is a different number, it isn't "take the first number and change its value to be the sum." Also, the other you're looking for is 'mutable.' |
| ||
| Nilium, thanks for the response. I do understand what your saying. But... As far as I'm aware the following data types are all mutable (other. :D) in possibly all languages (C, Basic, Pascal, etc.) Byte, Integer, Float, Double, Char, Short, Long, basically any mathematical type. If you have a integer A that equals 5 and you say a=a+1, it changes the original memory location of A, quick, painless, and effecient. Also, your paragraph about functions... Functions already protect the original value of a variable. If you don't specifically pass a argument (variable) ByReference, it will not, can not change. (I'm sure there are exceptions, haha) It is possible to do a BigNumber type that is mutable. I guess I'm just confused as to why .NET (and probably others) decided to go the immutable route? Is it easier in object oriented languages, or is it just the nature of Object Oriented languages? The .NET version seems to be a continuation/restructuring of the failed Decimal type (which was immutable). |
| ||
| Byte, Integer, Float, Double, Char, Short, Long, basically any mathematical type. If these are immutable, then explain to me what is changing in this example: Local temp:Int = 5 temp = temp + 5 Is the value changing or is the content of 'temp' changing? You don't pass around 'temp' when you pass an integer to a function, you pass the value. Can the value change? No. The integer is immutable. The variable is mutable, it's a variable, the name alone should make it obvious. But the value the variable contains can't change, it can only be replaced by another value. Compare it to an object, when you set the value of a field. The field has changed, meaning the object has changed. The object is mutable. Basically, you're wrong. I already explained a decent enough reason for using immutable types in something like .NET, so that's all I can offer you. If you can't comprehend the reason, simple as it is, I don't really know what to tell you (well, I do, but you won't like it). |
| ||
| Oh, completely my fault, you are of course correct. This is a case of symantecs and my not explaining myself very well. Let me try to put this another way. Internally, to the compiler and output code, in BlitzMax and C, if I have a variable X that is an integer, then the compiler creates one memory location for this variable. Now if you do any math on that variable and it gets assigned a new value, (ie a=a+1), then the new value gets put into the original memory location. No new memallocs are performed, no clean-up, etc. This is what I was trying to explain as my definition of a mutable variable type. The memory storage of that variable always exists as long as that variable is in scope. Does that help everyone understand where I'm coming from. On the contrary a immutable type variable is created and recreated over and over again each time the value changes. Here is example lay-man code (from the compilers perspective) to illustrate fully what I'm trying to figure out, this first is mutable variables: First some basic code: 1. X:int=0 2. X=X+1 Now the compilers intrepretation of this code as it is run: 1. I'm being told that I have to allocate a memory location of size Integer for a variable called X. I call the system and tell it to give me a memory location, it tells me it's location is 1024. I assign this memory location to equal 0. 2. Now the user wants me to take variable X and add 1 to the current value. I retrieve the current value from address location 1024, add 1 to that value and put the answer back into address location 1024. Now the compilers intrepretation of a immutable variable. 1. Same as before. 2. First I get the value of the current memory location of variable X. Internally I add 1 to this value. NOW I must create a new memory location for the new value. I request a memory allocation from the system and assign that memory allocation to the new value and assign this to the NEW x. NOW I deallocate the OLD X. End of program. See all the extra steps? :) |
| ||
| This is what I was trying to explain as my definition of a mutable variable type. I think the problem is you're mistaken about what mutability in these sorts of discussions applies to. Nobody cares about variables, variables are mutable. Said, done, no discussion to be had, it's just not possible to have a variable that isn't variable. An immutable variable would be a constant, if anything.So what the compiler does about how the value is stored is entirely irrelevant, you're over-thinking it and definitely missing the point. The mutability of data types is what you ought to be concerned with. Now the compilers intrepretation of a immutable variable. The compiler has no concept of an immutable variable, it's illogical and impossible to have a variable that cannot be variable. If you have something that looks like a variable, but it's not variable, then it's a constant. See all the extra steps? The only thing I really see here is that you don't know what you're actually talking about, which is an impressive thing by itself. Most people shut up when they don't know what they're talking about, but I don't, and you don't, so it's interesting in that respect. My advice is that you let me be the idiot and you not make an idiot of yourself. |
| ||
| >+<+[>>>[-]<[-]<[>+>+<<-]>>[<<+>>-]<[>+++++++++++[>++++++++>++++++++++>+++>+++++++>+++++++++<<<<<-]>+.>+.++++++.---.>-.>.>++.----.<<<----.>+.>>[-]<[-]<[-]<[-]<[-]<+++++++++++++.---.[-]<<<[-]>[-]>[-]]<<] |
   |