Miért utáljam a php-t?

Internet: PHP, CGI, stb.

Úgy látom, hogy a php-t divat szidni mostanában (rosszul megtervezett, rossz szokásokra tanít, gányolásra ösztönöz..stb).

Számomra nagyon kézreálló és kényelmes, okos eszköz. Mielőtt még többet ölnék bele, szívesen meghallgatnék véleményeket, hogy miért is kéne kerülni.

Ha lehet konkrétumokkal, flame nélkül :)

  • 6173 megtekintés

( Nyosigomboc v | 2011. 08. 16., k – 06:20 )

Sokat mar kijavitottak ezek kozul.
Regen nem volt normalisan kezelheto OO. (ugy PHP5 kornyekere ezt rendeztek)

Magic quotes - le kellett volna torni a kezet annak, aki ezt kitalalta (bar teny, hogy ezzel megmentette nehany php ganyer segget, akiet viszont szet kellett volna rugni)
Mara mar kihalt/default off, es ahol megsem, ott is ki lehet kerulni

Register globals - ez a masik hulyeseg, amiert jobb helyeken letoltendot adnak - szerencsere ez is kihalt/nem tamogatott

Ami nekem nem tetszik az a kulon global kulcsszo, ha hozza akarok ferni egy globalis valtozohoz. Sokszor kenyelmesebb lenne konstans helyett hasznalni (mert pl. futas kozben valtozhat, de ritkan), de fv elejen megis fel kell venni egyesevel. Jobb lenne, ha nem kellene.

Egyeb gond vele meg, hogy a kor visual basic-e: vonzza a hulyeket. Meg a nagyobb/ismertebb projectek kozt is rengeteg ganyul van megoldva (pl. phpmyadmin).

--
Tudod te, mennyi lóvé fér egy Alstom-kocsi dobozába? :)) - laspalmas, VB

"Ami nekem nem tetszik az a kulon global kulcsszo, ha hozza akarok ferni egy globalis valtozohoz. Sokszor kenyelmesebb lenne konstans helyett hasznalni (mert pl. futas kozben valtozhat, de ritkan), de fv elejen megis fel kell venni egyesevel. Jobb lenne, ha nem kellene."

csinálj egy típus nélküli objektumot, abba pakold bele a változóidat és elég azt berángatni global keyworddel a függvényeid elején. esetleg asszociatív tömbbel ugyenez.

ha jól sejtem, azért van a global-os dolog, mert ha valahol $$valtozonevebennem fícsör kihasználása van, s ezt valaki kívülről manipulálni tudja, akkor se férjen hozzá az összes változóhoz, csak a lokálisakhoz.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Arra tokeletes egy statikus osztaly is. Amugy sostem ertetem igazan a global hasznat. Sztem ez is olyan "hekkeljunk mert az jo" tipusu felmegoldas.
Marmint jooooo par eve fejlesztek mar php-ban de sztem emg eletemben nem volt ra szuksegem.

------------------
http://www.youtube.com/watch?v=xnJwT_30p6k

altalaban olyan dolgokhoz szukseges, amiket manapsag inkabb csak antipatternkent tartunk szamon.
http://en.wikipedia.org/wiki/Coupling_(computer_programming)
http://en.wikipedia.org/wiki/God_object

bizonyos esetben azert lehet haszna (adott esetben gyorsabban ossze lehet dobni egy prototipust singletonokkal, meg factory pattern alkalmazasaval, mint "szepen", jol tesztelhetoen, dependency injectiont/Principle of Least Knowledge-t szem elott tartva).

igen, nem pont a globals -os felvetesedre valaszoltam, hanem altalanossagban a global state-re.

Tyrael

Jo ezzel nyilvan tisztaban vagyok, es hasznalom is. MOndjuk hozzateszem hogy unittesting miatt ezektol is meg kell am szabadulni ha lehet, kulonben pup az ember hatan. Konkretan a global kulcsszo hasznlatara lennek kivancsi hogy a 0 apasztalattal rendelkezo fejlesztokon kivul kinek milyen haszna lehet.

------------------
http://www.youtube.com/watch?v=xnJwT_30p6k

ha tobbszor hivatkozol ra, akkor rovidebb leirni a $foo-t mint a $GLOBALS['foo']-t, de egyreszt berakhatnad lokalis valtozoba (copy-on-write miatt csak a zval refcount-ja none egyel, nem foglalna tobb memoriat), masreszt en jobban szeretem, ha az ilyen kulson eroforrasra minnel latvanyosabban felhivjak a figyelmemet.
egy 80 soros fuggvenynel ha a tetejen a valtozo deklaraciok/inicializaciok kozott van eldugva egy global $foo, majd 50 sorral lejebb hivatkozva ra, akkor nem biztos, hogy elsore rajovok, hogy ott most eppen a globalis nevterre hivatkozik a kod.
mig a $GLOBALS['foo'] eseteben ez nyilvanvalo.

Tyrael

( Dacr (nem ellenőrzött) | 2011. 08. 16., k – 06:43 )

Konkrétumokba nem megyek bele, inkább egy alapvető kérdést feszegetnék:

mire akarod használni, mi a cél? Ha weblap programozáshoz, akkor tanuld meg. Nem lesz lehetőséged minden szerveren a kedvenc interpretált nyelvedet használni. Kapsz egy php + mysql kombót, s csinálj vele, amit akarsz. A legtöbb helyen így megy. A másik, hogy ha állásszerzés a cél, ott hatványozottabban igaz, hogy a webes projektek java része ebben íródik. Innentől kezdve nem kérdés, hogy megtanulod-e, vagy sem. Vannak hibái, igen (mint minden nyelvnek), de azt gondolom, hogy a gány kód nem feltétlen csak a nyelv sajátosságai miatt vannak, hanem a programozók időhiányából fakadó trehányságból is származtathatók.

Ha nem ez a cél, hanem hogy valami használható nyelvet tanulj, vagy csak hobbiból hajt a tudásvágy, akkor c/c++ (valami keretrendszerrel karöltve, mondjuk Qt), perl, java (én speciel nem rajongok érte, de sokan jól megélnek belőle), vagy esetleg C#, ha van kilátásod Windows-os vonalra. De hobbinak sem elvetendő a php, főleg, ha hobbid az, hogy jól tanuld meg a kiszemelt áldozatot.

( Esc | 2011. 08. 16., k – 07:25 )

Ne kerüld, csak mellé tanulj meg egy másik programozási nyelvet is, különben idővel lehet úgy jársz, hogy egy leszel az állástalan php-sek közül, akikkel már most Dunát lehet rekeszteni.
Két nő jobb mint egy, három meg még jobb.. a php + egy másik nyelv jobb mint a php.. matematikailag: 0 + 1 több mint 0.:) (Vicc volt:).. mármint a három nő:)

( Jason v | 2011. 08. 16., k – 08:22 )

Több okból is utálják sokan, néha alaptalanul, néha nem:

1. Interpretált nyelv - ez sokaknál alapból kiveri a biztosítékot, annak ellenére, hogy némelyik ilyen fikázó perl/python buzi.
2. a standard függvénykönyvtár (ha szabad így nevezni a beépített függvényeket :-) elnevezési konvenciója...nincs. Lásd: strpos vs str_replace. Mivel már OO-szerű, jó lenne áttérni totál arra és valami jobban megtervezett nyelvet alapul venni.
3. Nincs mögötte tervezés, ami valóban nincs, mert jódarabig csak beledobálták az fícsöröket, majd amikor kijött, hogy hoppá, hazsnálhatónak is kéne lennie, jöttek a mindenféle frameworkök meg PDO-szerű classok (majd a PDO, ami állítólag szar, de erre is vannak külön flémerek).
4. OO utólag van beépítve, rá a procedurális alapgondolatra, ezért nem true OO (mintpl az Ada vagy Smalltalk), tehát fúj.
5. A response mint stdout átirányítás sokaknak szúrja a szemét, ha nem használsz output buffert, ami egyszer kiment az kint is marad, nem olyan "fejlett" mint pl a jsp/jsf, ahol mindenféle absztrakciós szinteken át megy a válasz vissza, ahova hook-okat meg callback-eket meg szűrőket tudsz beszúrni meg minden.

Több is van még, de azt googleben megleled.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

a PDO mint otlet nem lenne rossz, az implementacio lett elszurva kicsit, nem eleg rugalmas a belso apija:
https://wiki.php.net/internals/pdo/brainstorming

amugy gyakran elokerul az az erv a pdo mellett, hogy igy konnyeden tudsz valtani masik adatbazisra, de ez egyreszt nem tul gyakori igeny, illetve ha megis megleped, akkor sem lesz fajdalommentes a valtas, ha pdo-t hasznalsz, kiveve, ha csak key-value store-nak hasznaltad a db-t, akkor meg mar inkabb nosql-re kellene valtani, ahhoz meg nincs pdo interface.

http://www.php.net/manual/en/intro.pdo.php

PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility.

csak hogy mondjak egy ket peldat, olyan alapveto dolgokat nem fed el a pdo mint a limit(top) vagy az autoincrement(sequence), tehat akarva, akaratlanul, de db specifikus kodod lesz pdo-val is.

Tyrael

( lx | 2011. 08. 16., k – 10:39 )

Különösebb érzelmeim nincsenek a php irányába, de arra kíváncsi volnék, hogy az miért van, hogy a regkift idézőjelezni kell, miközben perjelekkel határolni is.

Gondolom azért, mert nem a nyelv támogatja szintaxis szinten, hanem függvények, amiknek a paramétert mint stringet adod át. Szerintem ez nem gáz, mert így egyszerűen lehet változó szabályokat csinálin, javascriptben meg vagy fix reguláris kifejezés, vagy külön regexp objektum (vagy mi) ami macerás. Nem?

Perl Compatible Regular Expressions

így tudod paraméterezni (matching modes):
'/bla+bla/i' <-- i = ignorecase, azaz case insensitive, de van még, m:multiline, s:singleline, meg mások

szerk:
http://php.net/manual/en/reference.pcre.pattern.modifiers.php

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( wwrreecckk | 2011. 08. 16., k – 12:28 )

Nálam ez verte ki a biztosítékot:

Example #2 Constructors in namespaced classes
<?php
namespace Foo;
class Bar {
public function Bar() {
// treated as constructor in PHP 5.3.0-5.3.2
// treated as regular method as of PHP 5.3.3
}
}
?>

getallheaders van/nincs attól függően, hogy fcgi/mod_php...

"For backwards compatibility, if PHP 5 cannot find a __construct() function for a given class, it will search for the old-style constructor function, by the name of the class."

Tehát mégis.

Mert a sok amateur képtelen volt felfogni, hogyha metódusnév === osztálynév, akkor az konstruktor...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Nem erről van szó, hanem a namespacekkel esetén történő működésről:
"As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor. This change doesn't affect non-namespaced classes."

Éljen a jól tervezett nyelv, ahol al-al-alverziókban nem változtatnak a nyelven.....

Ezen én is kiakadtam, de PHP 5 elején már deprecated volt, egyszerűen csak dobták php 5.3.3-tól. Az oka nagyon egyszerű: nem lehetett meghívni a szülő osztály konstruktorát, ha nem volt ismert az osztály neve. Így viszont:


parent::__construct();

Tulajdonképpen érthető... Csak már dobni kellett volna 5.3-ban, nem egy al-alverzióban.

"nem lehetett meghívni a szülő osztály konstruktorát, ha nem volt ismert az osztály neve"
Nyelvi hiányosság.
C#-ban: base kulcssó az inicializációs listában
Java: super kulcsszó
FreePascal: inherited kulcsszó.
PHP: miért nem a parent(paramétere) forma terjedt el? Gratulálok a Zendnek a nyelv okos, mérnöki megtervezéséért.

1, nem volt deprecated es meg most sem az.(nem dob E_DEPRECATED hibat ha hasznalod)
2, nem tavolitottak el 5.3.3-tol, hanem ahogy a peldaban is irtak, csak annak a lehetosege szunt meg, hogy namespaced kodban hasznalhasd a classnev tipusu konstruktort, tovabbra is hasznalhato maradt a globalis namespace-ben az ilyen tipusu konstruktor elnevezes.
3, nem az volt az oka, hanem ez: http://www.mail-archive.com/internals@lists.php.net/msg45832.html
4, micro verzioban nem lett volna szabad ilyen lepest meghozni(nem visszafele kompatibilis valtoztatas), raadasul inkonzisztens viselkedes, van egy mukodo osztalyod, berakod namespace-be, es mar nem mukodik.

Tyrael

Szerintem ez a lepes teljesen logikus, bar en bevallom, nem hasznaltam meg namespace-eket. Viszont nem tudom, default namespace-ben miert nem lehetett ugyanigy megcsinalni, mert ez igy elegge fucked up. A masik meg az, hogy 5.3.x valtasnal tenyleg gaz ilyet betenni. 5.4-be smooth-abb lenne.

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

Ugy ertem, maga az, hogy class Foo-ban ne legyen a Foo fuggveny konstruktor, ha mar van __construct (bar igazabol szerintem semmikeppen se kellene, hogy legyen), az logikus. De hogy miert csak namespace-ben van igy, es hogy miert 5.3.3-ban veszik ki, miert nem 5.4-ben, na az mar facepalm.

Na en eleve ezt nem ertem a PHP-ben. Egy programozasi nyelv nem demokracia, hogy kozfelkialtassal szavazzuk meg a feature-ket. Kell valaki, aki atlatja a logikat, es ramondja dolgokra, hogy igen, ez jo lesz, vagy nem, ez hulyeseg.
Es ez annyi helyen elojon. A namespace szeparator szavazas egy vicc volt, de ugyanigy humoros az alap framework tobb eltero konvenciot tartalmazo fuggvenyei, a parameterek sorrendje, satobbi. Mind mogott van logika, a gond az, hogy senki nem kenyszeritette ki az egyseges logikat.
Komolyan mondom, hogy nem lattam meg PHP-t programozo embert ugy dolgozni, hogy ne lett volna kinyitva mellette a php.net valamelyik - egyebkent alap - fuggvenynel, hogy na akkor itt most hogy van a parameterezes meg a visszateres. Pedig egyebkent nem lenne egy bonyolult nyelv.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Több hibát is találtam benne:

RoR 3-as verziótól escapeli a view-ben található stringeket

Az Internationalization részben nem értem, miért kapott No-t a RoR, hiszen van neki alapból is és gem-ként is elérhető több fajta megoldás.

XMLRPC szintén

Egyébként jónak tűnik ez a web2py, egyszer ha megtanulom a Python-t, ezt is megnézem.

( Panther v | 2011. 08. 17., sze – 00:17 )

Doksi szerint: "Array()", kódban tipikusan "array()". Gondolkodtam, mi lehet, merthogy C-stílusú nyelv, ergo muszáj, hogy kis- és nagybetűket megkülönböztesse. Hát nem. De bezzeg autoloadkor már baj van.

Mondjuk: LDAPServer és LdapServer a kódban ugyanaz az osztály, de Unix rendszeren tipikusan nem ugyanaz a fájl, amiben vannak: LDAPServer.class.php és LdapServer.class.php.

Beteg egy nyelv. Az említett namespace operátor is lol, mert eredetileg :: volt ez is, utána lett backslash...