I have code that looks like this:
var variableX:uint = something;
if (variableX > 1)
{
var variableY:uint = foo;
}
else
{
var variableY:uint = bar;
}
When compiled in FlashDevelop, the compiler gives the following warning:
Warning: Duplicate variable definition.
Being a beginner with AS3 and programming I don't like compiler warnings. The compiler is looking at me through squinted eyes and saying "Ok, buddy, I'll let you off this time. But I'm warning you!" and then doesn't tell me what's so wrong about what I'm doing.
What should I be aware of when I do something like this? I mean I could obviously define the variable outside of if and then this wouldn't be a problem, but maybe there's something more to this? Or is the compiler just giving a helpful nudge saying "hey, you might have accidentally created two different variables with the same name" ?
You're correct in your assessment of the warning. It's just letting you know there was already a variable in scope with that name and that you're about to redefine it. This way you don't accidentally overwrite a variable. Although they may not appear to be in the same scope if you check out variable hoisting on this page you'll see what the deal is: http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9d.html
An interesting implication of the lack of block-level scope is that
you can read or write to a variable before it is declared, as long as
it is declared before the function ends. This is because of a
technique called hoisting , which means that the compiler moves all
variable declarations to the top of the function. For example, the
following code compiles even though the initial trace() function for
the num variable happens before the num variable is declared:
My personal tendency is to just bring the definition up top myself to avoid having extra warnings that make me miss more important issues. Been out of AS3 for a while but in large projects people let things go and you end up with 100s-1000s of warnings and relevant ones get buried.
Related
I have a namespace variable which is defined as below:
namespace eval ::SMB::{
variable SmbInfo
------
------
proc ::SMB::SmbCreate {name dutport} {
variable SmbInfo
global DutPorts DutPort_2 DutPorts_3 smb
------
------
if{"" != [info command SMB::$name]} {
return -code error "command name \"$name\" already exists"
}
set SmbInfo($name -DutPort) $dutport
I am new to Tcl and trying to understand the above piece of code. Few questions, please correct me if I am wrong at any point:
The variable SmbInfo defined on top in namespace is getting overridden by the one declared in the procedure SmbCreate. I am unable to figure out what is the objective of the line:
set SmbInfo($name -DutPort) $dutport
I can see that 'DutPorts' is defined as global but I could not find 'DutPort'. I have not executed the code yet. Could it be an error?
Is ($name - DutPort) creating an array index for the variable SmbInfo and the value of $dutport is being set to that particular array variable?
I have similar code structures in the file like below
set SmbInfo($name - SmbSetDmac) [BuildMac1 $SmbInfo($from_name-DutPort)]
Where BuildMac1 is a procedure. A bit explanation of the above code might also make the thing clear.
If anything I missed to post in the question, kindly point me, I will edit my question.
Thanks in advance.
The second declaration doesn't override, it's the same variable in both cases.
The command is a syntax error because of the space after $name. The intent seems to be to assign the value of $dutport to the member of SmbInfo that has the name "$name -DutPort" (where $name is replaced by the variable value).
A similar assignment, but here the value comes from the result of the command.
There are a few syntax errors in the code, too many or too few spaces here and there. It seems unlikely this code has ever been executed.
The purpose of the smb::SmbCreate command would seem to be to 1) create a new command in the SMB namespace named by the first parameter (unless such a command already exists) and 2) store metadata in the SmbInfo namespace variable, indexed by a) the name parameter and b) a keyword such as -DutPort or -SmbSetDmac.
Code like this essentially implements an ad-hoc object-oriented interface. If the whitespace issues are resolved, it should work fine.
You have many syntactic problems that are going to cause you much grief. Tcl cares very much about its syntax level, which includes exactly where the spaces and newlines are, and whether there are {braces} and [brackets] as expected. You must get these things right.
Looking at the specific code you're having problems with, this line:
set SmbInfo($name -DutPort) $dutport
would appear to be highly unlikely, as it is passing three arguments to the set command when that only takes one or two. I'd guess that you've got a command that you're calling to obtain a key for an array, and that the code therefore ought to be this:
set SmbInfo([$name -DutPort]) $dutport
See those [brackets]? They matter here, as they say “run my contents as a little subscript and use the result”. With that sorted out, there's also the question of whether $name -DutPort works at all, but you'll just have to be guided by the error messages there. Tcl usually gives very good error messages, though sometimes you have to think about why the code got in the state where it is giving that message in order to figure out what the actual problem is. You know, usual debugging…
I would expect similar problems with:
set SmbInfo($name - SmbSetDmac) [BuildMac1 $SmbInfo($from_name-DutPort)]
and would guess that it is actually supposed to be:
set SmbInfo([$name -SmbSetDmac]) [BuildMac1 $SmbInfo([$from_name -DutPort])]
Note again that I have modified the spaces to follow the existing pattern (which I'm guessing is a property access; it looks like it's OTcl or XOTcl) and added brackets.
Finally, this line:
if{"" != [info command SMB::$name]} {
is also syntactically wrong, and should instead be:
if {"" != [info command SMB::$name]} {
That extra space matters, because it separates the word that is the command name (if) from the word that is the condition expression. The remainder of the line is probably correct (the SMB::$name might be suspicious, except you're using it in info command, but then you probably only need info command $name as it already knows about what namespace you're working in and you're using the unqualified name elsewhere).
Take the following code:
private var m_iQuanitity:int;
public function get quantity():int
{
return m_iQuantity;
}
That seems to make perfect sense. You can see what the quantity is from an outside class without any problems, but you can't really mess with it at all. Now take the following code:
private var m_acUsers:ArrayCollection = new ArrayCollection();
public function get users():ArrayCollection
{
return m_acUsers;
}
In that case you can't really set the variable directly, but you can still do just about everything else under the sun to it without any problems. You can call its AddItem and RemoveItemAt functions, which can do quite a bit to "set" the variable.
Does it still make sense to do this? I know you can create a duplicate ArrayCollection and just pass the duplicate back to avoid allowing it to be set, but doing stuff like that all over the place, purely for defensive programming, can waste a lot of CPU time. So I guess I'm asking if it still makes sense anyway, how so, and if I'm missing the point of using get and set completely? Thanks!
Syntactically there is nothing wrong with what you've got, but the second example does break down the concept of 'get' by making more than a read only property. If you need to adhere to a read only policy, then you've broken that since now you can manipulate the ArrayCollection.
In the end it comes down to what it is you're tying to do. Does it matter for the project that you can change the value? If you're working on a project with more than a few people, this type of coding will require you to either add a comment or have you explain what you're doing. When ever you do something outside of the norm, that can add confusion, so it's always best to simplify and stick to what is expected, avoiding having to explain something.
Also, I can think of a few ways this could cause problems - changing values outside of the function if you pass the returned property off to other classes that don't know where it came from and having internal code in the original class fail.
Consider the following code:
static if (!is(MyStruct))
{
struct MyStruct
{
}
}
static if (is(MyStruct))
{
static assert(0);
}
My original understanding has been that the order of declarations (in global scope) does not matter in D.
However, in this case, the order of the static ifs makes the difference between whether or not the program compiles.
Is D's compile-time evaluation stage, therefore, a procedural feature (like C/C++), a declarative feature, or something else? What is it currently, and what is it planned to be (if the two are different)?
Edit:
I just realized, the problem doesn't even end here. What happens of a static if uses .tupleof to enumerate the members of the current module, and create the same type of problem?
It's a declarative feature that has procedural properties as a side effect of the implementation.
It gets complicated. It's essentially declarative, but order can still matter when a static if introduces a new symbol. Aside from that, I don't believe that it ever matters, but as your example shows, when you introduce a new symbol in a static if, and another static if uses it, the order definitely can matter.
There has been some discussion recently about how to make it as consistent and intuitive as possible. So, particularly in corner cases, the situation may change in the near future. But I would expect that your example would continue to trigger the static assert. The question is whether it will start to trigger the static assert if you reverse the order of the static if blocks, and I'm not sure that that's really been decided yet. The discussion on it in the compiler's newsgroup isn't entirely conclusive and a bit hard to follow IMHO, so I can't say for sure. But I expect that ordering will still matter in at least some cases which involve a static if block introducing a new symbol.
EDIT:
This was recently posted by one of dmd's primary contributors:
At present, the order of compile-time evaluation is not defined; DMD
currently does it vaguely in lexical order but that is planned to
change in the near future. 'static if' and 'mixin' will be evaluated
in lexical order, before anything else is done. Afterwards,
everything else will be evaluated on-demand.
Apart from the "static if/mixin" pass, compilation can proceed in
parallel (though the current implementation doesn't yet do this) which
means there's no ordering (multiple items may complete compilation
simultaneously).
So, hopefully that clarifies things.
I have to decide whether to put a variable within a constructor or outside, but I keep getting the feeling that I am missing information, I have looked at other posts on stack overflow, but all mentioned it was a matter of preference, yet I found two difference that I feel might be important:
-If I decide to put the variables within a constructor, then I must have an object parameter for any function that wish to alter the variables, even if the code is internal to the class.
-Subclassing would cause the variables to not appear, something that causes problems when the class and any subclasses must have the variables in order to operate properly.
I may be wrong on all of these points, but at 4am, I would rather be told I am wrong than commit a mistake due to pride. If this has been answered somewhere else and I missed it, I am sorry, and if you could post the link, I would be grateful.
actions inside the constructor are interpreted, all others are precompiled so they work faster
Like www0z0k already said, the declarations outside the constructor are merly interpreted, so declaring them outside can be a performance bost under some circumstances.
-If I decide to put the variables within a constructor, then I must have an object parameter for any function that wish to alter the variables, even if the code is internal to the class.
This is correct.
-Subclassing would cause the variables to not appear, something that causes problems when the class and any subclasses must have the variables in order to operate properly.
You should think about what you want to archive. Most times you should rather choose a good software design then to think about performance. This subclassing problem that you mentioned can also protect some variables from being changed.
Greetings,
iuiz
-Subclassing would cause the variables to not appear, something that causes
problems when the class and any
subclasses must have the variables in
order to operate properly.
If I understood you correctly you're looking for protected fields (or properties).
-If I decide to put the variables within a constructor, then I must have
an object parameter for any function
that wish to alter the variables, even
if the code is internal to the class.
Sry, I don't get that...
#Performance: with all that said about interpreted constructors you could add a simple init(...) function within your constructor which does all you would do in the constructor - but without being interpreted.
public function ConstructorOfClass(arg1:int, arg2:*)
{
init(arg1, arg2);
}
private function init(arg1:int, arg2:*):void
{
// do whatever you want here
}
Let's say that I have a function that should only execute if some constant is defined. which of the following would be better
Option 1: wrap all the function calls in an if block:
if(defined('FOO_BAR_ENABLED')) {
foobar();
}
I figure this way the intent is more clear, but it requires checking the constant every time the function is called.
Option 2: check the constant in the function itself:
function foobar() {
if(!defined('FOO_BAR_ENABLED')) {
return;
}
//do stuff
}
This way requires less lines of code, and the constant is sure to get checked. However, I find it confusing to see calls to this function when it's not actually doing anything. Thoughts?
May I suggest renaming the function to FoobarIfEnabled(), then doing the check in the function?
Stealing liberally from a great language-agnostic answer to one of my own questions, when programming we have the following concerns:
Make it correct.
Make it clear.
Make it concise.
Make it fast. ... in that order.
If you do the check outside the function, you might end up missing it in one place. And if you want to change the behavior, you'll have to find all the places it gets called and fix it. That's a maintenance nightmare which violates principle 1. By adding "IfEnabled" or something like that to the name, now it is not just correct but also is clear. How can you beat that?
Performance is not to be worried about unless the final speed is unsatisfactory and you have identified this as the bottleneck (unlikely).
I recommend you follow the link above and read as it was a very useful answer that gave me much to think about.
Option 3:
void maybe_foobar() {
if(defined('FOO_BAR_ENABLED')) really_foobar();
}
void really_foobar() {
// do stuff
}
On a good day I'd think of better names than "maybe" and "really", but it depends what the function does and why it's turn-off-and-onable.
If there is no circumstance under which anyone could validly "do stuff" when FOO_BAR_ENABLED isn't defined, then I'd go with your option 2 (and perhaps call the function do_stuff_if_possible rather than foobar, if the name foobar was causing confusion as to whether calling it entails actually doing anything). If it's always valid to "do stuff", but some users just so happen do so conditionally, then I'd go with my option 3.
Option 1 is going to result in you copy-and-pasting code around, which is almost always a Bad Sign.
[Edit: here's Option 4, which I suspect is over-engineering, but you never know:
void if_enabled(string str, function f) {
if (defined(str + '_ENABLED')) f();
}
Then you call it with:
if_enabled('FOO_BAR', foobar);
Obviously there's some issues there to do with how your language handles functions, and whether there's any way to pass arbitrary parameters and a return value through if_enabled.]
Does the condition of the if fall within the function's responsibility? Is there a use case for calling the function without the if?
If the condition always needs to be checked, I'd put it in the function. Follow the DRY principle here: Don't Repeat Yourself. Another quip that might be helpful is the SRP - the Single Responsibility Principle - do one thing, and do it well.
In the header file, if foobar always takes the same number of arguments,
#ifdef ENABLE_FOOBAR
#define maybe_foobar(x) foobar(x)
#else
#define maybe_foobar(x)
#endif
Not sure how to do that in C++ or older C dialects if foobar can take a variable number of arguments.
(Just noticed language-agnostic tag. Well, the above technique is what I'd suggest in languages where it works; maybe use an inline function for languages which have those but lack macros).
Option 2, less code and it ensures the constant is defined, as you suggested.
Since this is apparently only used with the foobar() function, then option 2 should be your choice. That means the test is located in only one place and your code is more readable.