I thought so too. But, when someone is afflicted with the Dunning-Kruger effect (as I call it crainiuminanusitis), they tend to shrug intelligent people off as unqualified or dogmatic.
Scott
3 Likes
- Flawless and completely lacking in defect of any sort.
- Not lacking of any essential quality.
The first definition is the one people always think of when asked, but the second one is usually more relevant. A hammer is the perfect tool for driving in nails, but that same hammer may be rusty and pitted from years of use.
I don’t think anyone is going to find code fitting the first definition. As for the second, most of us consider interoperability with code provided by other vendors to be essential, and to do that the code must follow standards and best practices that have been agreed on by the community.
I actually think this definition is somewhat applicable. We can identify defects: Things that introduce negative effects in the code such as tight coupling, action at a distance, global state. As long as you identify the negative traits it’s then possible to objectively state “By this metric, solution a is ‘more perfect’ than solution B”. Which, funnily enough was what I was trying to explain to tony when he kept using the terms “less appropriate” and “inappropriate” I find it amusing he’s asking for a definition of a similar abstract concept even though he has consistently failed to do the same when asked.
Since when is changing code just to do the same thing but in a different way an “improvement”? My aim is to produce code which is functional, not fashionable, and that means writing code which fulfils a function which my customers are willing to pay for.
According to your logic as soon as the short array syntax was introduced in 5.3 I should have gone through my entire codebase just to change all usages of the “old” syntax to the “new” form just because it was new and fashionable. What benefit would my users see? Absolutely nothing. Such a complete waste of effort cannot be justified in the real world.
Incorrect, as usual. A “problem” creates issues whereas a “solution” removes them. My use of include statements does not create any issues, therefore there is no problem, and if there is no problem there is no need for a solution.
As I already said, you’ve proven yourself incapable of understanding simple concepts. I’m not going to try to teach you any more. You can either go back and read what I said then come back with any sensible questions you have or you can stop. Until you understand what an autoloader is for and the difference between a problem and a solution there’s no point at all continuing. Hint: require_once is one of many solutions to a problem, it doesn’t cause a problem.
Well done, you got your way. You managed to stop the conversation getting as far as “An autoloader is better than require_once because…”, which of course is your primary goal.
It’s quite sad really. All this “I don’t have the problem”, “This concept is bad because” is all just a smokescreen to stop people accidentally criticising your framework because they say “X is a better approach than Y” and your framework implements Y. This is http://en.wikipedia.org/wiki/Confirmation_bias You actively argue against any technique that could improve your code because you don’t already use it.
The difference between me and you tony is this:
I haven’t yet made use of the password_hash() function because there is some work in doing that and its infeasible for existing projects as it requires updating hundreds of thousands of passwords across a well over a hundred websites (and the only way to do that is to get each of those users to log in!). However, I am happy to admit the authentication system I use would improved by using it and at some point I will update it for use in new projects.
Whereas you will say “I don’t have the problem password_hash() solves” in order to stop any discussion about the merits of different password storage techniques before it can start. You get defensive as soon as anyone even begins to suggest there is a better alternative to something you’re already doing and you invent reasons that it’s not better, then if that fails, you use weasel words and wrongly claim that you don’t have the problem that the better alternative solves.
Just because I say something which you do not like does not make it a lie. I did not use an autoloader in my codebase for the simple reason that it was written years before autoloaders existed. I no longer have to write any new include statements as everything is handled within the framework, so there would be absolutely no benefit in changing my code to switch from doing it the “old” way to the “new” and “fashionable” way.
I will refactor my code if it improves its functionality, but certainly not to make it fashionable.
You did lie.
True: It’s handled by the framework
True: You have updated the framework in the last 5 years with additional include/require statements (A more than sensible window for everyone to have adopted PHP5, I’m looking at the code here and it’s demonstrably true)
So yes, by saying you don’t have to write any new require_once lines is a lie.
“Using include statements” is not the same as “having a problem with include statements”. My usage of include statements has been dealt with in the “old fashioned way”, so I do not have any compelling reason to waste effort on changing my code to deal with it in a different way
As I already said, you’ve proven yourself incapable of understanding simple concepts. I’m not going to try to teach you any more. You can either go back and read what I said then come back with any sensible questions you have or you can stop. Until you understand what an autoloader is for and the difference between a problem and a solution there’s no point at all continuing. Hint: require_once is one of many solutions to a problem, it doesn’t cause a problem.
Well done, you got your way. You managed to stop the conversation getting as far as “An autoloader is better than require_once because…”, which of course is your primary goal.
It’s quite sad really. All this “I don’t have the problem”, “This concept is bad because” is all just a smokescreen to stop people accidentally criticising your framework because they say “X is a better approach than Y” and your framework implements Y. This is http://en.wikipedia.org/wiki/Confirmation_bias You actively argue against any technique that could improve your code because you don’t already use it.
The difference between me and you tony is this:
I haven’t yet made use of the password_hash() function because there is some work in doing that and its infeasible for existing projects as it requires updating hundreds of thousands of passwords across a well over a hundred websites (and the only way to do that is to get each of those users to log in!). However, I am happy to admit the authentication system I use would improved by using it and at some point I will update it for use in new projects.
Whereas you will say “I don’t have the problem password_hash() solves” in order to stop any discussion about the merits of different password storage techniques before it can start. You get defensive as soon as anyone even begins to suggest there is a better alternative to something you’re already doing and you invent reasons that it’s not better, then if that fails, you use weasel words and wrongly claim that you don’t have the problem that the better alternative solves.
Could you properly address @RavenVelvet’s point from post #126? Surely this is an issue that your use of includes has?
Just because you say it is a problem does not make it so.
There is nothing wrong with using the $GLOBALS array, just as there is nothing wrong with using the $GET, $_POST, $_SERVER or $_SESSION arrays.
Called it.
1 Like
I repeat, for the umpteenth time, that although I have include statements in my framework they do not cause any sort of problem, so they do not need any sort of solution. I have dealt with all these include statements in the old fashioned way, so I don’t need to change my code to do exactly the same thing but in a different way.
As I already said, you’ve proven yourself incapable of understanding simple concepts. I’m not going to try to teach you any more. You can either go back and read what I said then come back with any sensible questions you have or you can stop. Until you understand what an autoloader is for and the difference between a problem and a solution there’s no point at all continuing. Hint: require_once is one of many solutions to a problem, it doesn’t cause a problem.
Well done, you got your way. You managed to stop the conversation getting as far as “An autoloader is better than require_once because…”, which of course is your primary goal.
It’s quite sad really. All this “I don’t have the problem”, “This concept is bad because” is all just a smokescreen to stop people accidentally criticising your framework because they say “X is a better approach than Y” and your framework implements Y. This is http://en.wikipedia.org/wiki/Confirmation_bias You actively argue against any technique that could improve your code because you don’t already use it.
The difference between me and you tony is this:
I haven’t yet made use of the password_hash() function because there is some work in doing that and its infeasible for existing projects as it requires updating hundreds of thousands of passwords across a well over a hundred websites (and the only way to do that is to get each of those users to log in!). However, I am happy to admit the authentication system I use would improved by using it and at some point I will update it for use in new projects.
Whereas you will say “I don’t have the problem password_hash() solves” in order to stop any discussion about the merits of different password storage techniques before it can start. You get defensive as soon as anyone even begins to suggest there is a better alternative to something you’re already doing and you invent reasons that it’s not better, then if that fails, you use weasel words and wrongly claim that you don’t have the problem that the better alternative solves.
You are correct, for once. I do not have that problem, so I don’t need that solution.
I will only refactor my code if it adds an improvement in its functionality, not to make it fashionable.
You said that, I didn’t.
Rather than trying to just dismiss what he’s saying, are you actually aware of why he’s saying that could be a problem?
1 Like
I’m betting tony will just say “I don’t have that problem” or something along the lines of “when used appropriately” and dismiss it again.