I like the two different method call notations. Clear separation of calls to static methods and instance methods.
Not sure what you're driving here, but if someone can't do OO design then what can i say? If you're talking about global functions like in_array() then i agree. Yes they are bad. But frankly, do they really differ that much from static method calls like Array.map() or Math.max()?
Let's say that you are new to PHP and you are bugfixing someone else code. There is a lot of overhead understanding what belongs to global, to user functions and classes. This is not clean. While a class in other languages specifies all namespace in its header, in php you can come to a fall of includes that you need to drive back until you find where the function is. Namespace are actually more clean, easy to debug and extending.
Ah, now i see. Yes, this is incredibly bad practice.
PSR-4 autoloading with Composer is really the only sensible way to deal with imports. There should only be a couple of script files in a project that are not classes. Maybe some bootstrapping script if vendor/autoload.php doesn't cut it and a front controller. Most frameworks also ship some sort of console script to run different commands. That should be enough.
There should be no need for require()s or include()s in other parts of the application.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@tux0r Imo, don't prefix, don't use hungarian notation.
If we get typed properties in PHP 7.4 (or any later version) there's very little ground to cover that isn't typed.
Using type hints everywhere with
declare(strict_types=1)fixes a lot of these issues.@lucafabbri
I like the two different method call notations. Clear separation of calls to static methods and instance methods.
Not sure what you're driving here, but if someone can't do OO design then what can i say? If you're talking about global functions like
in_array()then i agree. Yes they are bad. But frankly, do they really differ that much from static method calls likeArray.map()orMath.max()?Let's say that you are new to PHP and you are bugfixing someone else code. There is a lot of overhead understanding what belongs to global, to user functions and classes. This is not clean. While a class in other languages specifies all namespace in its header, in php you can come to a fall of includes that you need to drive back until you find where the function is. Namespace are actually more clean, easy to debug and extending.
Ah, now i see. Yes, this is incredibly bad practice.
PSR-4 autoloading with Composer is really the only sensible way to deal with imports. There should only be a couple of script files in a project that are not classes. Maybe some bootstrapping script if vendor/autoload.php doesn't cut it and a front controller. Most frameworks also ship some sort of console script to run different commands. That should be enough.
There should be no need for
require()s orinclude()s in other parts of the application.