marmint melyik lepes a logikus?
csak mert leirod, hogy logikus, utana leirod, hogy nem erted, hogy miert volt elbaszva, utana pedig egyetertesz, hogy nem 5.3.3-nal kellett volna kivenni a feature-t.
ujra elolvastam a topicot, es akkora epic facepalm.
amit linkeltem level: Ralph javasolta, hogy ha egy osztalyon belul elobb van definialva a __construct, akkor ne dobjon az engine "Redefining already defined constructor for class" hibat, hiszen az osztalynevvel megegyezo metodus csak akkor lehet konstruktor, ha nincs __construct az osztalyban.
ezt jol lehurrogtak, es megszavazta az a 2-3 ember, hogy ki kell venni a namespace-ekbol a classnev tipusu konstruktort, mert az megoldja a problemat.
erre Stas egyszercsak rajon, hogy a hibakent bejelentett viselkedes ("Redefining already defined constructor for class" E_STRICT uzenet, ha van egy osztalyban mindketfele konstruktor, amugy ha jol emlekszem pont Stas vezette be ezt a figyelmeztetest anno), minden korabbi verzioban igy mukodik, namespaceektol fuggetlenul.
ezt megerositi Ralph is, felre volt konfigolva a tobbi instalja, ezert hitte azt, hogy ez a viselkedes most lett bevezetve.
ez igy ennyiben marad, kiszedik a namespacekbol a classname construktort.
erre 2 honappal kesobb egy masik core fejleszto (Felipe) egy tok fuggetlen hibajegy kapcsan megvalositja az eredetileg kert valtoztatast:
https://bugs.php.net/bug.php?id=52160
nevezetesen, hogy ha elobb van definialva a __construct, akkor ne dobjon E_STRICT-et az engine.
szoval kiszedtek a featuret, bevallaltak a BC breaket micro verzioval, bevallaltak az inkonzisztenciat(atraksz egy class-t namespace-be es maskepp/nem fog mukodni), csak azert hogy ne dobjon egy E_STRICT-et az ilyen viszonylag ritka edge case-ekben az engine, elutasitva az egyszerubb sokkal kevesbe intrusive megoldast, amihez patch is volt, majd ket honap mulva masvalaki megjavitotta az eredetileg javasolt, de elvetett modon a problemat.
EPICFAIL!
Tyrael