Many PHP features should be language constructs, but they were made as
language hacks.
__construct is evil, as like any other language hack
It does not provides a safe fundation to build safe abstractions, reusable
and extendibles components, which leads to the lack of PHP libraries.
Let's suppose there is a library that provides an utility class, which has
no super class nor constructor.
// lives in library.phar
class Utility { }
A client uses this class by extending it
// includes library.phar
class Client extends Utility {
function __construct() {
// client initialization code here
}
}
At that point the Utility class can not add __construct safely, and if it
does Client will break it, it's not calling the constructor.
but what happen if Utility provides a __constructor
class Utility {
function __construct() {
// Utility initialization here
}
}
class Client {
function __construct() {
// some code
parent::__construct(); // as good client call the super class
// and then more code
}
}
In this case the Utility is forced to keep the __construct, if it's removed
the Client call will fail as parent::__construct will not exists.
In both cases there were no API changes, only the way the objects are
initializated was what changed.
My point is that the language does not provide solid fundations (aka
language constructs) for systems and libraries to evolve in a safe way.
Martin Scotta
On Wed, Jan 19, 2011 at 4:58 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi!
>
>
> I think the point is that the php language itself does not provide solid
>> construct for writing rock-solid code. Yes, there are many
>> programmers/hackers that can, but the effort they put is huge.
>>
>
> I think this is completely untrue.
>
>
> In Java you are free to extend a class --yours or imported-- without
>> worries
>> about it's internal implementation. Is that possible in PHP? nope.
>> __construct breaks that.
>>
>
> Could you please explain what you mean? How __construct breaks extending a
> class?
>
>
> IMHO, as a simple PHP programmer, the language should provide the simplest
>> language construct and the engine should handle all the complexity under
>> the
>> hood.
>>
>
> I see no way of hiding threads complexity "under the hood" - if you want
> threads, you'll need to deal with synchronization, locking, race conditions,
> etc. Do you see any way to avoid it?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
