I prefer watching people as they code, and think. But I don't like watching how not to do something. So when you leave in mistakes and quickly cut to right way of doing something, I would prefer if you just cut off the mistake entirely and cut to the correct way.. if that makes sense. Also it appears more professional if you hide your mistakes, although EVERYONE does them, there's no value I find in seeing mistakes occur when I'm trying to learn something new. 😊 Great work man. ------------------------------------------------- Update: I take that back, for the purpose of testing, seeing the types of natural mistakes and how they affect the testing itself is actually very relative and informative. Thanks!
FacePalmProductions thank you for your comments on this I have gone back and forth with that my self and want people to feel like they can do it them selfs because I know some people are really negative about their work and look at the tutorials with everyone doing everything correct the first time and it sorta hides the reality of programming! Programming is really just making some code and then fixing your mistakes until there are not mistakes (that you know of) when you really think about it.
In all my classes I have been told to define != in terms of == meaning return !(this == that). and similarly when designing circuits it is better to do the same thing. Is there any backing that you have to support your claim that this is wrong? I don't mind, you just seemed sure that rewriting the != was better
This is a great question! Ok so normally yes I support that { bar == false } is better then { !bar } this is how ever only because its harder to confuse the two. The reason your taught to use == instead of != is because of the fact that they can be confused how ever this is mitigated with code editors that use support lignatures because it can turn != into ≠ instead which you will not mix up with ==. How ever all of this has nothing to do with performance nor the reason I say that we must use != in this video it is all to avoid human error reading the code. The backing to my claim is that when you use == or != on an object that is not a base type you are actually calling a function so when you say { foo == bar } conceptually your actually saying something like { foo.==(bar) } and the same with != and so because we are testing our code that overrides the operators == and != we need to make sure we are actually testing the right function. For example imaging we wrote all our tests with { !(foo == bar) } instead of { foo != bar } we would never actually test the method != that we are writing. Also to be clear I am not asserting anything on the use of == over != in the normal flow of a program but because we are dealing with overloading those 2 ops in this test we must use both or we will not be testing our program correctly. Please let me know if this makes sense? If please tell me what does not make sense to you.
@@eforencreates548 oh, that makes complete sense. It's better in this case to have them completely independent since the testing of it needs to test each individual part rather than a culmination of parts.
Its basically Handle h = (Handle)obj; The difference is that this code will throw an InvalidCastException if obj is not actually a Handle, where as "as" will not instead in the same situation as will simply return null instead of throwing an exception. Does that make sense?
What do you all think of the new way I am handling explaining the tests we are using?
I prefer watching people as they code, and think. But I don't like watching how not to do something. So when you leave in mistakes and quickly cut to right way of doing something, I would prefer if you just cut off the mistake entirely and cut to the correct way.. if that makes sense. Also it appears more professional if you hide your mistakes, although EVERYONE does them, there's no value I find in seeing mistakes occur when I'm trying to learn something new. 😊 Great work man.
-------------------------------------------------
Update: I take that back, for the purpose of testing, seeing the types of natural mistakes and how they affect the testing itself is actually very relative and informative. Thanks!
FacePalmProductions thank you for your comments on this I have gone back and forth with that my self and want people to feel like they can do it them selfs because I know some people are really negative about their work and look at the tutorials with everyone doing everything correct the first time and it sorta hides the reality of programming! Programming is really just making some code and then fixing your mistakes until there are not mistakes (that you know of) when you really think about it.
In all my classes I have been told to define != in terms of == meaning return !(this == that). and similarly when designing circuits it is better to do the same thing. Is there any backing that you have to support your claim that this is wrong? I don't mind, you just seemed sure that rewriting the != was better
This is a great question! Ok so normally yes I support that { bar == false } is better then { !bar } this is how ever only because its harder to confuse the two. The reason your taught to use == instead of != is because of the fact that they can be confused how ever this is mitigated with code editors that use support lignatures because it can turn != into ≠ instead which you will not mix up with ==.
How ever all of this has nothing to do with performance nor the reason I say that we must use != in this video it is all to avoid human error reading the code.
The backing to my claim is that when you use == or != on an object that is not a base type you are actually calling a function so when you say { foo == bar } conceptually your actually saying something like { foo.==(bar) } and the same with != and so because we are testing our code that overrides the operators == and != we need to make sure we are actually testing the right function. For example imaging we wrote all our tests with { !(foo == bar) } instead of { foo != bar } we would never actually test the method != that we are writing.
Also to be clear I am not asserting anything on the use of == over != in the normal flow of a program but because we are dealing with overloading those 2 ops in this test we must use both or we will not be testing our program correctly.
Please let me know if this makes sense?
If please tell me what does not make sense to you.
@@eforencreates548 oh, that makes complete sense. It's better in this case to have them completely independent since the testing of it needs to test each individual part rather than a culmination of parts.
@@lleytonmorris6305 Bingo! We need to make sure we test each part of it as in a vacuum as possible in it.
I don't understand your code
"Handle h = obj as Handle"
Could you explain more? Is this the same as namespace?
Its basically
Handle h = (Handle)obj;
The difference is that this code will throw an InvalidCastException if obj is not actually a Handle, where as "as" will not instead in the same situation as will simply return null instead of throwing an exception.
Does that make sense?
Eforen Creates Yes! Thank you
jonathan bodling awesome I am glad I could help :)