|
|
|||||||
It would be nice to be able to declare a variable and assign a value o it in one command. For instance Code:
This saves many lines of code especially when declaring ALOT of variables. Maybe someone could add this to the Masterlist of suggestions ? |
||||||||
|
|
|||||||
are you using option explicit? as if not, you may use implicit declaration. |
||||||||
|
|
|||||||
I use opion explicit to check wether I have loose vars or not. but without option explicit I can declare and assign at the same time ? |
||||||||
|
|
|||||||
Assigning a value to the variable will create it implicitly in the global scope if you do not have the "Explicit" option set. |
||||||||
|
|
|||||||
Ugh of course.. was too early for me when I answered that. |
||||||||
|
|
|||||||
You could always have the best of both worlds: Code:
|
||||||||
|
|
|||||||
Thats's a good workaround for most scripts thx However I'm working on a new UDF which requires ALOT of variables and I want to keep the code as nice and tidy as possible, with option explicity it adds at least 10 more lines of code hence why I suggested this feature. But thanks for your suggestion I will use this in my main scripts |
||||||||
|
|
|||||||
Quote: Not quite true - $a is declared in the global scope, there is no way of implicitly declaring a variable in the local scope. This means that if you routinely use this trick to avoid having to explicitly declare variables you may well have implicitly declared the same variable twice in different files or functions. As you don't have "Explicit" set on, you will not get an error about re-declaring the variable and you will screw up the value of the originally declared variable. The same will apply if you forget to declare a variable which has already been (implicitly) declared as global - the global variable will be used and you will not get any runtime interpreter errors however your script may not function as intended. |
||||||||
|
|
|||||||
anyways, saying that having to declare and initialise variables separately increases the line count of a script is not true. the amount of lines has always been in kixtart coding totally about the scripters liking. no matter how complex your script, you can always write it in single line. and true words there richie. even though implicit declaration works, it's not the best way to go. imho, it works for short simple scripts but gradually as the complexity of the script grows, every global variable adds to the pain of the scripter exponentially. specially when implicitly declared. |
||||||||
|
|
|||||||
Quote: hmm, how would this go into one line Code:
Besides, it is a simple thing to implement, and it saves time at least. When you decide to use a variable of which you already know what info it is gonna hold it IS far easier to use Code: Dim $var = "string" [edit] post fixed by jooel |
||||||||
|
|
|||||||
how about: Code:
I see only one line. |
||||||||
|
|
|||||||
Fair enough But you'd have to agree that typing the var 2 times is a bit annoying to say the least and not very practical. Especially since most scripting languages support declaration and assigning at once. |
||||||||
|
|
|||||||
Quote: Well one would also agree that we don't want to turn this into another scripting language like Ruby/Perl/VBS. I'm not trying to squash the idea, just saying I can take it or leave it as I don't write too many LARGE scripts that make that much of a difference to me. |
||||||||
|
|
|||||||
the problem of assigning and dimming at once is exactly what explicit is trying to remove. loose variables lying around the scripts as the scripter doesn't want to keep scrolling to the top so he just dims the vars where ever he is at that point. also, the difference with kixtart is that the vars don't need to be initialized to be of some type like with many others. it's a blessing and a curse but weights more on the plus side what comes to easiness of use. that's also why ppl can see scripts written in kixtart that have a block of variables dimmed on a single line consisting of some dozens of vars. but like doc said, it's not a big deal. and I can see it being useful specially if the scripter or the code viewer is used to other languages and their extensive initialization blocks. |
||||||||
|
|
|||||||
included in the masterlist. |
||||||||
|
|
|||||||
One step further Declare as type and assign at once. For instance: Dim $var As String = "New string" DIm $Shell As Object = CreateObject("WScript.Shell") |
||||||||
|
|
|||||||
apronk, that wouldn't make much sense as kixtart is autotype. so, if you do: Code: DIm $Shell As String = CreateObject("WScript.Shell") vartypename($Shell) it would still return object. |
||||||||
|
|
|||||||
Strong Types. Cool. No "autocasting" problems anymore. Code: Dim $RC $RC = SetOption("StrongType", "On") Dim $strNumber As String = "500" Dim $intNumber As Integer = 500 ; $strNumber + $intNumber ? ; This line would give an error Cast($strNumber, "Integer") + $intNumber ? But anyway, I agree, declare and assign at once would be nice Code: Dim $strNumber = "500" Dim $intNumber = 500 |
||||||||
|
|
|||||||
Originally Posted By: Jooel apronk, that wouldn't make much sense as kixtart is autotype. so, if you do: Code: DIm $Shell As String = CreateObject("WScript.Shell") vartypename($Shell) it would still return object. Autotype should be optional enabled off course. SetOption("AutoType",Off") That way you will HAVE to assign types to your vars when turned on. If turned on, Kix should give error if a type is not declared. |
||||||||
|
|
|||||||
You got my two cents on this one. |
||||||||
|
|
|||||||
Makes me think of what I suggested last year Strict Option |
||||||||
|
|
|||||||
just to note that disabling autotype would most likely take full rework of the entire source of kix... |
||||||||
|
|
|||||||
Originally Posted By: Jooel just to note that disabling autotype would most likely take full rework of the entire source of kix... Can't imagine it being coded that it needs a full rework. As I imagine AutoType would be some kind of function, and a function can be tweaked to turn off and on. Seems easy to implement. Then again I haven't seen the source or even know what language it is programmed in, I guess I could take a look at kix.exe but I'm just too lazy |
||||||||
|
|
|||||||
C or c++ |