I got 213 warning.
Here are some and their issues:
UserController.m:
ARC Issue — Assigning retained object to unsafe property; object will
be released after assignment V r’
LoginController.m
ARC Issue — Assigning retained object to unsafe property; object will be released
after assignment
Well, I checked that the object is declared without strong or retain. However, default for ARC files are strong, NOT assign.
Does the compiler still think that the files are non ARC files? Where can I check?
Semantic Issue No ‘assign’, ‘retain’, or ‘copy’ attribute is specified
— ‘assign’ is assumed
Semantic Issue Default property attribute ‘assign’ not appropriate for
non-gc object
Semantic Issue No ‘assign’, ‘retain’, or ‘copy’ attribute is specified
— ‘assign’ is assumed
Semantic Issue Again, no attribute is specified means RETAIN should be
assumed, which is the new default for ARC files.
Those things show up on codes generated automatically by the coredata.
Should I just ignore those warnings?
But it's too anoying
Replacing the code one by one is too time consuming. Also that means I am not taking advantage of the fact that the default is indeed strong.
Maybe I can search and replace. What exact format should I search and replace for?
Programs are working fine.
I would just turn off ARC for the current project and work with it during the next new project that you create. going from non-ARC to ARC is such a pain D:
Related
Ruby and many languages support safe navigation operator:
name = article&.author&.name
Is there any equivalent in JSONPath?
This is unnecessary in JSON Path. Navigation is safe by default. If a value doesn't exist at a given path, the node set returned will just be empty; it shouldn't error.
This may, of course, vary between implementations as we don't have a standard yet, but we're working on one.
I’m curious to know how feasible it is to get away from the dependency onto the application’s internal structure when you create an automated test case. Or you may need to rewrite the test case when a developer modifies a part of the code for a bug fix, etc.
We could write several automated test cases based on the applications internal object structure, but lets assume that the object hierarchy changes after 6 months or so, how do we approach these kind of issues?
I can't speak for other testing tools but at least in QTP's case the testing tool introduces a level of abstraction over the application so that non-functional changes in the application often (but not always) have no effect on the way the testing tool identifies the object.
For example in QTP all web elements are considered to be direct children of the document so that changes in the DOM (such as additional tables) don't change the object's description.
In TestComplete, there are a couple of ways to make sure that the changed app structure does not break you tests.
You can set up the Aliases tree of the Name Mapping feature. In this case, if the app structure is changed, you need to modify the Aliases tree appropriately and your test will stay working without requirement to modify them.
You can use the Extended Find feature of the Name Mapping in order to ignore parts of the the actual object tree and search for a needed objects on deeper levels.
This is what I was forced to do after losing all my work twice due to changes on the DOM structure:
Every single time I need to work with an object, I use the Find function with the ID of the object, searching for the object on the Page object. This way, whenever the DOM gets updated, my tests still run smoothly.
The only thing that will break my tests is if the object's ID get changed, but that's not very probable to happen.
Here you can find some examples of the helper functions I use.
I have added a reference to a DLL from another project (contained in the bin folder) and I have set Copy local to true. When I step through the code; the debugger jumps all over the place. I believe this is because the code is optimised. I have two questions:
Is this because the code is optimised
If (1) is true then why can I step through the code in the first place i.e. without Reflector.
My guess is the jumping is due to the PDB (symbols) being out of sync with the compiled DLL, thus the symbols tell VS to go to a line number that does not actually match up with what the code is actually doing; optimization may also play a part as well, because of in-lining functions.
Other things that influence the debugging experience are:
Just My Code setting
Methods explicitly marked with DebuggerNonUserCode attribute
Debugging optimized code may "jump around", as some functions become inlined. The most telling thing is that local variables usually get optimized away, giving a message to that effect when trying to read them.
If the jumping seems to make very little sense, though, then it's more likely you have the wrong PDB (which maps to line numbers) or source (which has the line numbers).
I'm used to dynamic typing meaning checking for type info of object/non object oriented structure at runtime and throwing some sort of type error, ie if it quacks like a duck its a duck. Is there a different type of dynamic typing (please go into details).
Yes, absolutely. Duck-typing is an idiom which says that the type of a value at this moment in time is based on the fields and methods that it has right now. Dynamic typing just says that types are associated with run-time values, not with static variables and parameters. There is a difference between the two, and you can use the latter without the former.
For example, if you programmed in PHP and limited yourself to the basic types without using OO, then you would be using dynamic typing without using duck-typing.
No, dynamic typing is when values have type but variables do not, so most type checking is done at runtime. So, basically, if the value walks or quacks like a duck, it's a duck, else an error is thrown. Duck typing really just describes a feature of dynamic typing that ensures it will be typesafe (i.e. a method will only run if variable foo'has the right attribute or can execute that method).
Because I rush in development (a lot of whip cracking here) and declare my objects at the top of the function and instantiate inside my try-catch block, I get a lot of the good old "object not set to an instance of an object" errors while doing TDD, and later if I do miss a branch that object was used in (doing VB now, would prefer C#) or just in every day coding, object not set to an instance of an object is a bit vague. Sure the stack trace sends me to the line the error occured at, but it would be nice if I could modify my logging to either name the object or its type because sometimes I have multiple objects on the same line. It's not the end of the world, but in the end it would save me a few minutes each day. Any ideas on how I can pass the info on which object wasn't set? Thanks
It is non trivial to "modify your logging" to output variable name or type - I am sure that if the framework could easily get this information from the executing IL, MS would have included it the null reference exception.
Prevention is always better than cure. Here are a couple of tips I would do
Fix your compiler warnings
C# would generate a compile error if it detects that there are code paths that could use an unassigned local variable. [For some odd reason] VB.Net will still compile but the compiler will generate a warning - take heed of these and go and fix the code and you should never run into the problem of unassigned variables again!
Adopt a different coding pattern for variable declaration
I appreciate that method variable scope in ye olde VB was that the variable was visible throughout the entire method regardless of where it was defined. As a result, it was a reasonable practice to put all your var declarations at the top of the method. VB.Net of course is different - you can only use variables after they are declared and so it is OK (and I would say preferable*) to put the declaration (and assignment) closer to where the variable is actually used. This should help you see "by eye" if your program logic means it is possible to use an unassigned variable.
Some people think this is a think that it is always good practice to put variable declarations in a block at the top of the method. I will not argue against them but I would say that that approach works best with small methods that do not use lots of variables.