ugrás a tartalomhoz

Please do not break our language

Hidvégi Gábor · 2015. Már. 24. (K), 18.00
Az új PHP bizonyos változásai értelmetlenek és károsak
 
1

Én már most azt mondom, hogy

Práger Ádám · 2015. Már. 25. (Sze), 19.45
Én már most azt mondom, hogy a régi array syntax kidobható :P... felőlem akár már PHP7 ben is, a projektekből már rég kidobáltuk.

A cikkről meg annyit, hogy úgy baromság ahogy van. A PHP egyetlen esélye hogy túllépjen a gyermekbetegségeken, hogy a BC breakek elfogadottak, sőt egyenesen kötelezőek legyenek új major esetén. Minél többet, minél gyakrabban. Majd akinek nincs ideje updatelni vár egy darabig.

Edit: meg egyébként is, php cs fixer-t nyugodtan ki lehetne nevezni official cuccnak, és ott lerendezni a migrationöket... vagy írni libet ennek mintájára.
4

Én már most azt mondom, hogy

Hidvégi Gábor · 2015. Már. 26. (Cs), 07.32
Én már most azt mondom, hogy a régi array syntax kidobható
Nincs mindenkinek ideje ilyenekre.

A cikkről meg annyit, hogy úgy baromság ahogy van.
A cikk írója legalább mindent alaposan megindokolt, de te meg sem próbálod, csak kinyilatkoztatsz. Ettől válsz igazán hitelessé.
7

array() -> []...ha erre nincs

blacksonic · 2015. Már. 26. (Cs), 08.33
array() -> []...ha erre nincs idő egy hosszabb projektnél akkor ott fenntartható kód írására sincs idő
De nem az ilyen kaliberű projekteknek kéne meghatározni egy nyelv fejlődését
15

Amin én dolgozok, abban ~65k

kuka · 2015. Már. 26. (Cs), 10.08
Amin én dolgozok, abban ~65k „array(” lecseréléséről volna szó. Mivel ezek lecserélésére nincs bevethető munkaerőnk, ebből következik, hogy az ~1.1m sor PHP kódunk fenntarthatatlan… Csak remélni tudom, hogy a cégtulajdonos nem fog veled egyetérteni és nem zárja be az boltot.
17

Mások már megírták, utána

bamegakapa · 2015. Már. 26. (Cs), 10.17
Mások már megírták, utána futtatod a teszteket és fél óra alatt végeztél is az egésszel. Lehet én egyszerűsítem túl a problémát, térítsetek észre, ha így van.
20

Lehet. Nálunk a teljes teszt

kuka · 2015. Már. 26. (Cs), 10.28
Lehet. Nálunk a teljes teszt futtatás nem fél óra, hanem egy hétvége.

Ettől függetlenül köszönöm a konverter hivatkozást, személyes célokra mindenképpen figyelembe fogom venni.
23

Masszív :). Sejtettem, hogy

bamegakapa · 2015. Már. 26. (Cs), 10.43
Masszív :). Sejtettem, hogy valamit figyelmen kívül hagyok.
37

Én továbbra sem értem. A

inf3rno · 2015. Már. 26. (Cs), 15.17
Én továbbra sem értem. A tesztek és a konvertáló is a háttérben futnak, mellette csinálhatsz bármit, amit akarsz. Ez miért lenne ember igényes?
40

Valóban, miután elolvastam a

kuka · 2015. Már. 26. (Cs), 15.38
Valóban, miután elolvastam a bamegakapa által ajánlott szkriptet, rájöttem, hogy a token_get_all() ismeretének hiányában túl borúlátó volt az elvárásom egy automatizált átírással szemben. Ennek fényében viszont tényleg elvárható, hogy emberi takarításra ne legyen szükség.

Még egyszer köszönöm. Éjszakára rá is uszítom majd egy kísérleti branch-re.
55

Valamennyi szükség lehet rá

inf3rno · 2015. Már. 26. (Cs), 22.18
Valamennyi szükség lehet rá így is, ha eval van a kódban, ami 'array(...)'-t dolgoz fel, de szerintem ez elég ritka.
59

Btw. doctrine annotations is

inf3rno · 2015. Már. 27. (P), 12.32
Btw. doctrine annotations is token_get_all()-t használ, én onnan ismerem.
60

Izgatottan várom az eredményt

bamegakapa · 2015. Már. 27. (P), 12.38
Izgatottan várom az eredményt :).
79

Node miért szánnál rá egy

Hidvégi Gábor · 2015. Már. 28. (Szo), 15.54
Node miért szánnál rá egy másodpercet is az életedből, ha semmilyen haszna nincs a dolognak? Kifizetik?
81

Hosszú projektnél a

blacksonic · 2015. Már. 28. (Szo), 16.44
Hosszú projektnél a refaktorálás kód karbantartása megtérül...persze nem azonnal. Vagy nézhetjük úgy is hogy ha az új verzió gyorsabb mint a régi kevesebb géppel is elmegy az alkalmazás.
82

Itt most a rövid

Hidvégi Gábor · 2015. Már. 28. (Szo), 17.05
Itt most a rövid tömbdefinícióra gondolsz? Mitől lenne gyorsabb a kód, ha használod, és mennyivel?
85

Az újabb PHP verzió miatt,

blacksonic · 2015. Már. 29. (V), 09.27
Az újabb PHP verzió miatt, viszont annak meg feltétele a tömbdefiníciók lecserélése
87

Ezt alá tudnád bármivel is

Hidvégi Gábor · 2015. Már. 29. (V), 09.54
Ezt alá tudnád bármivel is támasztani?
97

Google tele van ilyen

blacksonic · 2015. Már. 30. (H), 11.50
Google tele van ilyen cikkekkel. Peldaul ez is, vagy ez.
99

Pontosan honnan veszed, hogy

Hidvégi Gábor · 2015. Már. 30. (H), 12.27
Pontosan honnan veszed, hogy az új php verziók csak az újfajta tömbdefinícióval működnek?
83

A

inf3rno · 2015. Már. 28. (Szo), 17.58
A karbantartásért/fenntartásért általában fizetnek évi x összeget, legalábbis ennek kéne a normálisnak lennie.
88

Ki és mennyit profitál a

Hidvégi Gábor · 2015. Már. 29. (V), 09.55
Ki és mennyit profitál a váltásból?
89

Ha senki nem profitál az új

bamegakapa · 2015. Már. 29. (V), 10.14
Ha senki nem profitál az új PHP verziókból, meg a biztonsági frissítésekből, akkor mire fel az egész hiszti?
90

Ha nem érted a kérdést, akkor

Hidvégi Gábor · 2015. Már. 29. (V), 10.17
Ha nem érted a kérdést, akkor ne kukorékolj bele, légyszíves. Arról volt szó, hogy az új tömbdefinícióra való átírással mit nyerünk.
91

Tudom, miről volt szó, csak

bamegakapa · 2015. Már. 29. (V), 10.27
Tudom, miről volt szó, csak gondoltam, kivételesen nem rágok szájba mindent.

Az új tömbdefiníció egyelőre csak egy lehetőség. Egy nap lehet úgy döntenek a fejlesztők, hogy deprekálják a régit, mert semmi szükség rá és csak a nyelv komplexitását növeli. Aztán az eddigi stratégia alapján egy következő verzióban el is tűnik. Ekkor a biztonsági frissítésekhez nem fogsz hozzá férni, amíg nem írod át a kódodat.

A végén mindenki nyer (most ezt se rágom szájba miért, ha érdekel, csak sértegess minősíthetetlen stílusban, és türelmesen elmagyarázom).
92

Azt kérdeztem, hogy mit nyer

Hidvégi Gábor · 2015. Már. 29. (V), 10.40
Azt kérdeztem, hogy mit nyer azzal bárki is, ha lecseréli a tömbdefiníciót. Miért jössz egy teljesen hipotetikus érveléssel? Nem lehet kizárni, hogy megtörténjen, de egyelőre ilyenről szó sincs.

A kérdésem továbbra is áll.
93

Ha az a kérdésed, hogy mit

bamegakapa · 2015. Már. 29. (V), 14.07
Ha egy projektben lecseréljük a tömbdefiníciókat, egyelőre csak annyit nyerünk, hogy felkészülünk a jövőre, valamint a kódunk egységes lesz, hiszen új kódnál (pl. új funkciók) már nyilván az új változatot fogjuk használni (mivel praktikusabb).

Ha nem akarod lecserélni, nem kell. Csak akkor lesz szükséges, ha esetleg deprekálják a régi arrayt.

Mindketten tudjuk, hogy ezek az érvek nem fognak téged meggyőzni, mint ahogy bármi más érv sem, így feleslegesnek látom a kérdésed erőltetését.
94

Milyen jövőre készülsz fel?

Hidvégi Gábor · 2015. Már. 29. (V), 14.18
Milyen jövőre készülsz fel? Csak találgatás a részedről, hogy valaha is áttérne rá a php.

Ha egyáltalán nem cseréled le, akkor is egységes marad a kódod.
96

Mint írtam, addig nincs külső

bamegakapa · 2015. Már. 29. (V), 22.20
Mint írtam, addig nincs külső kényszer, hogy lecseréld, amíg nem deprekálják. Lehet, hogy nem is fogják. Én nem írtam, hogy ez biztosan bekövetkezik.

A kódod nem marad egységes, mert ha új funkciókat fejlesztesz, mint írtam, már kétféle szintaxis lesz benne ugyanarra (minek használnád a régit új kódnál?), ami felesleges komplexitás. Érdemes (vagy akár mondhatnám: bölcs dolog) tehát inkább lecserélni, mivel könnyen automatizálható folyamat.

De ahogy inferno írja, lecserélheted csupán igényességből is. Vagy szakmai érdeklődésből. Vagy úgy hagyod, amíg időszerűvé nem válik.
100

Miért ne használhatnám a régi

Hidvégi Gábor · 2015. Már. 30. (H), 12.29
Miért ne használhatnám a régi tömbdefiníciót új projektben? Te is írtad korábban, hogy még neked sem áll rá a szemed.
101

Pontosan, de ha dolgoznék

bamegakapa · 2015. Már. 30. (H), 12.53
Pontosan, de ha dolgoznék PHP-ben, biztos, hogy az új szintaxist használnám. A régi mellett csak a megszokás szól. Ettől függetlenül használhatja persze, akinek ez szempont.
102

Értelmetlen vitatkozás...

Gixx · 2015. Már. 30. (H), 15.15
Te a PHP4-et használod, mert az tetszik. Én a PHP 5.6-tal barátkozok egyelőre, aztán majd a 7-essel is, mert nekem az tetszik.

Mire gondot fognak okozni neked és a cikk szerzőjének a 7-es verzióban bevezetett újdonságok, addig nagyon sok idő fog eltelni.

Nincs értelme ilyen céltalan vitatkozásba bonyolódni. Hidd el, én megértelek. Én is szereteném, ha az utakon még mindig 1965-1975 közötti amerikai gépszörnyek cirkálnának, de nem teszik, mert elavultak. Már csak a fanatikusok és a gyűjtők birtokolják. És ahogy azokhoz is lehet találni specializálódott supporot, biztos lesz majd olyan, aki a visszafele kompatibilitás híve, és régi PHP-t futtató szervereket tart fent. Nem kell félni az újdonságoktól, de el kell fogadni a trendeket. A hiszti nem vezet semmire.

Én is beletörődtem, hogy megjelenésében ízléstelen és ronda, de technikailag kétségtelenül fejlett autók gurulnak az utcán.

Ez itt az én elvetett konstruktorom az autók programnyelvében:

103

Egyedileg biztosan rá lehet

inf3rno · 2015. Már. 30. (H), 15.28
Egyedileg biztosan rá lehet építeni egy modern kocsit erre a kasznira. Talán a törésteszt, ami hiányozni fog :P
104

Mindig azok a fránya

bamegakapa · 2015. Már. 30. (H), 15.32
Mindig azok a fránya biztonsági fejlesztések ;).
105

Egyedileg biztosan rá lehet

Joó Ádám · 2015. Már. 30. (H), 18.48
Egyedileg biztosan rá lehet építeni egy modern kocsit erre a kasznira.


A kezét letörném :)
107

+1

Pepita · 2015. Már. 31. (K), 17.27
Bizony én is. :)
Jól gondolom, hogy Ford Capri?
108

Jól gondolom, hogy Ford

Joó Ádám · 2015. Már. 31. (K), 18.04
Jól gondolom, hogy Ford Capri?


Buick Gran Sport.
109

Ford Mustang Fastbackből

blacksonic · 2015. Már. 31. (K), 21.47
Ford Mustang Fastbackből csináltak ilyet hogy modern elektronikával és biztonsági felszereléssel...de az ára nem összemérhető egy Ford Mustanggal :/
110

Nekem a Porsche 911 jobban

inf3rno · 2015. Ápr. 2. (Cs), 18.52
Nekem a Porsche 911 jobban bejön, de a Mustang is szép.
95

Rövidebb és jobban átlátható

inf3rno · 2015. Már. 29. (V), 18.57
Rövidebb és jobban átlátható lesz tőle a kód, ha lecseréljük.
98

Pedig ha erre a kerdesre

blacksonic · 2015. Már. 30. (H), 11.54
Pedig ha erre a kerdesre neked nem a valasz, vagy nem termel annyi hasznot az oldal h megerje a faradtsagot a frissitesre akkor egesz egyszeruen nem kell ra frissiteni.
35

Írsz egy rekurzív regex-et,

inf3rno · 2015. Már. 26. (Cs), 15.07
Írsz egy rekurzív regex-et, ami megkeresi a kódban az array()-t és átalakítja short syntax-ra. Maximum fél órás munka. Nem értem, hogy ebben mi annyira nehéz. IDE-vel is a nagyja kigyomlálható ugyanígy, csak az a nested array-nél nem fog működni.

szerk:
+1, bamegakapa, token parserrel is meg lehet oldani.
41

Nem kotelezo verziot

blacksonic · 2015. Már. 26. (Cs), 15.56
Nem kotelezo verziot frissiteni. 1.1m sor onmagaban is fenntarthatatlan.
2

Total off

Max Logan · 2015. Már. 25. (Sze), 20.39
Miért divat még 2015-ben is olyan honlapot publikálni, ami szétfolyik a képernyő teljes szélességére a szöveghasábok tekintetében? Ez nekem tipikusan WTF kategória…
43

pont ugyanez

Gixx · 2015. Már. 26. (Cs), 16.13
Pontosan ugyanezen járt az eszem, amikor már képtelen voltam követni a szöveget, mert elkezdtett zsibbadni az agyam és jojózni a szemem.

Átraktam a Chrome-ot, hogy emuláljon tabletet, de úgy meg reménytelenül hosszúnak tűnt, mint az igazgató tanévzáró beszéde az iskolában.
3

Nekem az jött át hogy ő nem

blacksonic · 2015. Már. 25. (Sze), 23.23
Nekem az jött át hogy ő nem akar nagyon haladni a korral
5

Nekem meg az, hogy nem

Hidvégi Gábor · 2015. Már. 26. (Cs), 07.34
Nekem meg az, hogy nem olvastad el és/vagy nem értetted meg az írást.
6

Minden ami új és még

blacksonic · 2015. Már. 26. (Cs), 08.31
Minden ami új és még egyszerűbb is a megszokásokkal jön, meg hogy nincs neki erre ideje
Egy tucat webshopnál lehet de 3-4 hónapnál nagyobb projektnél kellene rá időnek lenni.
8

Ő az egyszerűbb tisztább

blacksonic · 2015. Már. 26. (Cs), 08.36
Ő az egyszerűbb tisztább érthetőbb szintaxis és használhatóság miatt nem változtatna a nyelven (ezeket az indokokat vmiért lenézi), mert hát ilyen ez megszoktuk...akinek meg nem tetszik elmehet a...igazán pozitív hozzáállása van a figurának
11

Látom, egyáltalán nem

Hidvégi Gábor · 2015. Már. 26. (Cs), 08.47
Látom, egyáltalán nem értetted meg. Pont az ellenkezőjéről beszél, amit írsz.
10

BS

vbence · 2015. Már. 26. (Cs), 08.40
Én sajnos nem jutottam el az indoklásokig, mert a bullshit detektor bezárta a tabot ennél a pontnál:

Amongst their pathetic excuses are ...


Nem ártana valami minőségi kontroll a WL-re kitett blogmarkokkal kapcsolatban (gondolom ezért volt bevezetve a megerősítés). Attól mert valaki egy programozással kapcsolatos témáról éli ki a frusztrációját még nem lesz a cikk szamai.
12

Ha megpróbáltad volna

Hidvégi Gábor · 2015. Már. 26. (Cs), 09.03
Ha megpróbáltad volna továbbolvasni, kifejti, miért gondolja rossznak a felhozott érveket. Így viszont a te érvelésed gyenge, ami alapján minőséginek lehet elfogadni egy blogmarkot.

Egyébként mindent szó szerint értelmezel? Ha odaírják, hogy "és akkor most ugorj a kútba!", akkor te beleugrasz? Kit érdekel, hogy milyen töltelékszavakat használ bárki más? A PHP fejlesztői szentek, nem hozhatnak fel rossz érveket, nem hozhatnak rossz döntést?

A Microsoftnak sikerült, máig szenvednek a rossz döntésük miatt.

Egyébként pedig a fenti idézeted alapján úgy tűnik, nem tudod, mit jelent a bullshit. Akkor meg miről beszélünk?
19

+1

bamegakapa · 2015. Már. 26. (Cs), 10.23
Én kitartóan tovább olvastam a sokadik minősítgetés után is, de minek.

Viszont úgy látszik, már csak az ilyen színvonalú cikkek váltanak ki kommentelési ingert, mert ezt már azért nem lehet szó nélkül hagyni :).
9

Belenéztem az oldal

blacksonic · 2015. Már. 26. (Cs), 08.39
Belenéztem az oldal forrásába...bár ne tettem volna...már 10 éve is elavult volt amit ott látok
13

És ez kit érdekel?

Hidvégi Gábor · 2015. Már. 26. (Cs), 09.11
És ez kit érdekel?
42

Mi masrol papolna mint az uj

blacksonic · 2015. Már. 26. (Cs), 15.59
Mi masrol papolna mint az uj dolgok ellen ha 10 ev alatt nem fejlodott a korral es elment mellette az ido?
45

Van egy tartalomkezelő

Hidvégi Gábor · 2015. Már. 26. (Cs), 16.16
Van egy tartalomkezelő rendszere, ami több mint tíz éve tökéletesen működik, böngészőkben jól megjelenő kimenete van. Minek változtasson rajta? Pont erről szól az írás is, ha valami működik, azon nem kell változtatni.
46

A jol megjeleno nem egyenlo a

blacksonic · 2015. Már. 26. (Cs), 16.35
A jol megjeleno nem egyenlo a megjelennek a karakterekkel....nem egy kellemes latvanyt nyujt, de ezt nem csak en mondom itt
47

Ez szubjektív, és igazából

Hidvégi Gábor · 2015. Már. 26. (Cs), 16.38
Ez szubjektív, és igazából senkit sem érdekel. A mondanivaló a lényeg.
22

Láttam már rosszabbat. Az

bamegakapa · 2015. Már. 26. (Cs), 10.38
Láttam már rosszabbat. Az ilyen arcok már csak elvből sem fognak HTML4-nél újabbat használni, arra mérget vehetsz :).
14

Konstruktor

Hidvégi Gábor · 2015. Már. 26. (Cs), 09.37
A legszebb az egészben, hogy például JS-ben is a PHP4 konstruktorához hasonlóan hozunk létre objektum prototípusokat.

function Objektum() {
  this.valtozo = 5;
}

var objektum = new Objektum();


Kedves Práger Ádám, blacksonic és vbence, majd ha az ecmascript fórumain ott látlak titeket harcolni ez ellen, akkor majd lesz miről beszélnünk. Addig is, úgy látszik, előbb lőttök, és utána kérdeztek, és akkor nagyon finoman fogalmaztam.
16

Nem teljesen mindegy, hogy a

bamegakapa · 2015. Már. 26. (Cs), 10.12
Nem teljesen mindegy, hogy a Javascriptben milyen a konstruktor? A vita nem arról szól, melyik a kívánatosabb formája a konstruktorok elnevezésének, az általad nevesített személyek sem erről beszéltek.
21

Egy igazi trollnak ez

dropout · 2015. Már. 26. (Cs), 10.34
Egy igazi trollnak ez mindegy, csak szoljon a lemez, mindig ujra es ujra.
24

Bár a JS szintaxisa nem értem

Endyl · 2015. Már. 26. (Cs), 10.45
Bár a JS szintaxisa nem értem, hogy jön ide, de nem kell harcolni :)

class MyClass() {
  constructor(foo) {
    this.foo = foo;
  }
}
18

Rant, rant, rant

bamegakapa · 2015. Már. 26. (Cs), 10.19
Részemről nem adnék teret az ilyen szintű irományoknak. Az értelmes tartalom pár bekezdésben összefoglalható (kis jóindulattal), a többi csak arra jó, hogy két bekezdésenként változatos jelzős szerkezetekkel illessen mindenkit, aki nem ért egyet vele vagy bármi köze volt a nagyon-nagyon sérelmes történésekhez.

Amúgy nyilván nem jó gyakorlat, hogy csak úgy kivesznek egy funkciót egy olyan eszközből, amit rengetegen használnak. Amikor még követtem a PHP világának történéseit, ilyenkor előbb deprekálták, valamint ha használtad, sűrű warningokat dobált a rendszer. Aztán idővel el is távolították, ami nyilvánvalóan kívánatos és szükségszerű lépés.

Egyébként teljesen valószínűtlennek tartom, hogy a PHP7-ben csak úgy töröljék ezt az ősi konstruktoros megoldást, hirtelen ezt találtam, ami azt támasztja alá, hogy a fejlesztők is abban a megoldásban gondolkoznak, hogy 7-esben deprekálás, 8-asban viszlát (a szavazás pár hete zárult le).

Talán abból lehetne tanulni, ha rossz példaként állítjuk a cikk szerzőjét. Azzal az idővel és energiával, amit az iromány (szerintem felesleges) megalkotására fordított, simán készíthetett volna egy kis scriptet, ami az összes projektjében lecseréli a régi szintaxist az újra, merthogy amennyire én látom, ez baromira nem bonyolult feladat (jó ideje nem PHP-ztam). Esetleg ezt a kis eszközt meg is oszthatta volna az általa hangoztatott közösséggel. Biztos vagyok benne, bár nem néztem utána, hogy volt, aki ezt tette (szerintem már akkor, amikor a PHP5 megjelent), így a probléma megoldása még egyszerűbb. Mire lesz PHP 7, a PHP 4 támogatásával már nem éri meg foglalkozni - már ma sem nagyon lelhető fel sehol (eszerint 2% alatt van). Ha mégis ez a szíve vágya, hasonlóan kicsi szkriptekkel könnyen készíthet két különböző verziót a projektjéből.

(tényleg zárójelben: ha ezt tette volna, utána büszkén írhatott volna róla egy egész másfajta, pozitív irományt, ami után biztos vagyok benne, hogy ő is sokkal jobban érezné magát - fortyogó düh vs jól végzett munka és másokon segítés öröme)

Szerintem fejlesztőként, bármit is használunk, nekünk is van felelősségünk. Ha arra építjük a munkánkat, amit mások ingyér bocsátanak rendelkezésünkre, minimálisan elvárható, hogy alkalmazkodunk, követjük a változásokat és nem pedig elvárjuk, hogy mindenki más a mi hitvány kis kódbázisainkhoz alkalmazkodjon, amíg világ a világ. Ha egy projektet úgy készítünk el, hogy az nem fenntartható és magasról teszünk mindenre, ami ezt elősegítené (tehát eleve eldobhatóra készítjük, ami bizonyos esetekben persze a megfelelő döntés), nem várhatjuk el, hogy a kis projektünk évek múlva is ugyanúgy működni fog, miközben a környezet, amire épül, fejlődik. Ez szimpla önzés. Attól, hogy a közösségben rengeteg a hasonlóan önző stratégiát követő ember, a közösség érdeke még nem az lesz, hogy minden, ami működött a PHP 4-ben, működjön a PHP 22-ben is. A közösség érdeke az, hogy a fejlesztők továbbra is örömmel és hatékonyan dolgozzanak azon, hogy a termék minél faszább legyen. Bár a közösséget szolgálják, nem a közösség szolgái.

Mint már feltűnhetett, nem a visszafelé kompatibilitás ellen érvelek. Szerintem is fontos, hogy meglegyen a megfelelő stratégia, amivel szép lassan kivezetik az elöregedett, feleslegessé vált funkciókat.
25

Látszik, hogy nem értetted

Hidvégi Gábor · 2015. Már. 26. (Cs), 11.20
Látszik, hogy nem értetted meg az érvelését, emiatt a tied is nélkülöz minden alapot.

Vegyünk egy egyszerűbb példát a tömbökkel. Amikor a php értelmező a script beolvasásakor eljutott a következő sorig: $tomb = array('1', '2');, akkor nyilvánvaló volt a számára, hogy létre kell hoznia egy tömböt. Amikor bejött az új szintaktika, a $tomb = ['1', '2'];-nél megtehetik azt, hogy csendben átírják az első formára, és a program futása ugyanott folytatódik.

Ugyanez a helyzet a konstruktorokkal, a szintaktikai ellenőrző szintjén meg lehetne oldani a problémát.

Már sokan leírták, és erre hivatkozik az írás is, hogy egy nyelvi eszközt akkor kell kidobni, ha használata megakadályoz minket újabb dolgok bevezetésében. Mivel ilyenről ebben az esetben szó sincs, teljesen fölösleges megszabadulni a régi konstruktortól, ráadásul az új konstruktor semmilyen nyilvánvaló előnnyel nem jön a régihez képest.

Azzal az idővel és energiával, amit az iromány (szerintem felesleges) megalkotására fordított, simán készíthetett volna egy kis scriptet
De ha nem érted meg az írást, akkor miért hozod fel rossz példának?

Ha arra építjük a munkánkat, amit mások ingyér bocsátanak rendelkezésünkre, minimálisan elvárható, hogy alkalmazkodunk, követjük a változásokat és nem pedig elvárjuk, hogy mindenki más a mi hitvány kis kódbázisainkhoz alkalmazkodjon, amíg világ a világ
Ha nem értesz meg valamit, akkor miért okoskodsz? A kérdéses eszközt a php fejlesztői adták a kezünkbe, és sokan éltek vele. Mint fentebb rámutattam, az újfajta konstruktornak semmilyen előnye nincs a régihez képest, akkor miért zavar ez bárkit is? A szintaktikai értelmezőt/php futtatót egyszer kellett megírni, ami kezeli az eseteket, és utána el lehet felejteni, az idők végezetéig működhetne. Miért írjam át a kódom akkor az új konstruktorra?

Nincs olyan, hogy ingyenleves. A php fejlesztői jó pénzt kapnak (akár közvetve) a munkájukért, méghozzá azért, mert mi olyan sokan használjuk az eszközüket. Nem ők tesznek nekünk szívességet azzal, hogy dolgozhatunk az ő játékszerükkel. Semmi értelme egy ilyen változással plusz munkát csinálni nekünk.

a közösség érdeke még nem az lesz, hogy minden, ami működött a PHP 4-ben, működjön a PHP 22-ben is
Mert PHP 4-ben nem lehetett jó programot írni? Mert mindig csak a legújabb a legjobb? Ha bejön egy újabb divathullám, akkor írjam át a programomat, hogy a közösség boldogabb legyen? Miért nyúljak egy működő dologhoz? Ráadásul ha olyan kinézeti dolgokba akarnak belenyúlni a tisztelt fejlesztők (mint ez a konstruktoros példa), aminek semmilyen pozitív hozománya nincs, csak negatív, akkor annak mi az értelme?

A közösség érdeke az, hogy a fejlesztők továbbra is örömmel és hatékonyan dolgozzanak azon, hogy a termék minél faszább legyen.
Ez baromság. Mi köze a közösségnek az én működő termékemhez? Miért nyúljak bele a kódba, ha az jó? És miért ne tudjam belenyúlás nélkül frissíteni a php verziót a legújabbra, hogy ezzel megkapjam a biztonsági frissítéseket is? Ki fizeti ki nekem a kód módosítását, tesztelését? Te? A php fejlesztői?
26

Látom sikerült felvenned a

bamegakapa · 2015. Már. 26. (Cs), 11.33
Látom sikerült felvenned a cikkíró stílusát :).

Mielőtt energiát fektetek a válaszba, komolyan gondolod mindezt? Különösen a hozzáállást az ÉN-közösség-fejlesztők háromszöghöz.
36

Nekem ebből az egészből csak

inf3rno · 2015. Már. 26. (Cs), 15.14
Nekem ebből az egészből csak annyi jött le, hogy Gábor egyedül a világ ellen, ismét. Ö izé most már ketten, mert ő egyetért a blog írójával. Egyébként nem olvastam el a cikket, megnyitottam, de nem szeretem az olyan programozásról szóló írásokat, amikben nincs se kód se folyamatábra se semmi ilyen látványos dolog. Általában ezeknek nem szokott jó minőségük lenni.
49

Nekem csak annyi a kérdésem, hogy...

Gixx · 2015. Már. 26. (Cs), 16.48
KI A RÁK HASZNÁL MÉG PHP4 KONSTRUKTORT?!?!?!?

Amikor 2005-ben a Carnation-ben kezdtem dolgozni, ott akkor kezdtek áttérni a PHP5-re, és egyből dobtuk is a PHP4 konstruktorokat az új fejlesztéseknél. Áprilisban lesz ennek pontosan 10 éve. A régi PHP4-es oldalak kikoptak. Legalább 5 éve nagyon illendően nem lenne szabad léteznie aktív kódban szerintem.

Másrészt viszont, ha jól értem, akkor a PHP7-et ekézi. Könyörgöm abba bele se gondolt, hogy mennyi időnek kell eltelnie, hogy elterjedjen? (Nem olvastam végig, nem bírom a felesleges szócséplést, de az itteni kommentekből erre következtettem)

Teszemazt egy natur, trükközésmentes
apt-get install php
mikor fog PHP7-et telepíteni alapból? 5 év, 10 év múlva? Mert a rendszergazdák többsége nem az a kifejezetten kalandvágyó, kísérletezős tipus, hanem ellenkezőleg, sokkal inkább "majd ha megjön csomagban"-tipus.

Ha addig is még mindig PHP4 konstruktort akar használni, akkor majd meg is érdemli, hogy szenvedjen.
51

Ha elolvasnád az írást, akkor

Hidvégi Gábor · 2015. Már. 26. (Cs), 17.08
Ha elolvasnád az írást, akkor nem tennél fel értelmetlen kérdéseket. A többiek nem értették meg, ezért írkálják azt, amit.

A tFPDF például PHP4 konstruktort használ.
53

Komolyan mondom, szomorú ránk

bamegakapa · 2015. Már. 26. (Cs), 17.34
Komolyan mondom, szomorú ránk nézve, hogy rajtad kívül senki nem képes értelmezni ezt az irományt :).
56

Ez van, a magyarok többsége

inf3rno · 2015. Már. 26. (Cs), 22.23
Ez van, a magyarok többsége funkcionális analfabéta, úgyhogy én már ezen sem lepődöm meg. Egyébként nekem sem ment, meg se próbáltam, esélytelen.
61

Nem hiszem, hogy velünk van a

bamegakapa · 2015. Már. 27. (P), 12.40
Nem hiszem, hogy velünk van a baj.
64

Az FPDF 2011-es

Gixx · 2015. Már. 27. (P), 15.30
Az FPDF 2011-es. Egyrészt elég szégyen, hogy még akkor sem voltak hajlandók refaktorálni a kódjaikat, másrészt vannak már jobb és hatékonyabb megoldások is, mintsem PHP-val generálni RTF-alapú PDF doksikat.

Nekem mostanában a kedvencem a wkhtmltopdf.

As the name implies, it converts HTML documents to PDFs using WebKit.
71

Farok csóválja

bamegakapa · 2015. Már. 27. (P), 23.48
Pár dolgot hozzátennék, mert szerintem káros ez a hozzáállás. Nem lehet elvárni, hogy az egész közösség és a PHP fejlesztői is úgy táncoljanak, ahogy szűklátókörű, önző programozók fütyülnek.

Mi az már, hogy a PHP fejlesztői ne nyúljanak bele a saját munkájukba, ne tegyék jobbá, csak azért, mert néhányan nem képesek rendesen végezni a munkájukat? Tényleg pistike tesz szívességet azzal, hogy a PHP-t használja méltóságos barkácsolmányához? Hogyne lenne már ingyenleves... Te mikor fizettél érte? Vagy csak tőlem nem kértek soha semmit? Basszus, beülnek a jóba, aztán máris követelőznek, mintha nekik járna, hogy onnantól, hogy valamit összebarmolnak, az már működjön mindörökké. Mert az az ő szentséges "terméke"! Komolyan mondom, eszem megáll.

Mi alapján döntöttek vajon az urak a PHP mellett? Mivel borzasztóan felelősségteljes szakemberekről van szó, legalábbis az alapján, másokon mennyire kérik ezt számon, és mivel hosszú távra terveztek a projektjükkel, nem akartak hozzányúlni soha többé, bizonyára gondos elemzés eredményeként választottak eszközt. Biztos látták ezt és ezt, vagy hasonló oldalakat, tanulmányozták a fejlesztők stratégiáját, tájékozódtak több nyelvvel kapcsolatban. Aztán valamiért mégis a PHP-t választották. Hogy miért? Én annó azért, mert máshoz kurvára nem értettem. Rajtam kívül mindenki más bizonyára nem ezért, gondolom :).

Egyébként éppen emiatt a PHP fejlesztőinek nem kell aggódnia, hogy a tömegek elpártolnak tőlük. Még mindig itt a legalacsonyabb a belépési küszöb. Még mindig itt lehet működőnek látszó dolgokat összebuherálni a legkevesebb tudással. És bármennyire fájnak is a fejlesztések egy rétegnek, ők nem fognak váltani, mert ahhoz meg kéne tanulniuk valami mást.

Akinek nem inge, persze ne vegye magára, meg ilyenek...
73

+1, anno én is lustaságból

inf3rno · 2015. Már. 28. (Szo), 13.15
+1, anno én is lustaságból maradtam PHP-nál sok évig, és szerintem sokan vannak ugyanígy vele. Én támogatom, hogy mindenki tanuljon meg más nyelveket is, hátha valamelyik jobban bejön. A többség nem szokott leragadni az első barátnőnél, akkor miért tennénk ezt a programozási nyelvekkel?!
75

Már csak azért is érdemes

bamegakapa · 2015. Már. 28. (Szo), 13.36
Már csak azért is érdemes elsajátítani egy új nyelv megtanulásának a képességét, mert különféle feladatokhoz különféle eszközök valók. Fontos lépés az eszköz kiválasztása, ami nem mindig szerencsés, ha kimarad, mivel úgyis csak a PHP-hez értek.

Ráadásul egy ilyen konstruktoros változtatás, amiről itt szó van, el se kéne érje az ingerküszöböt, mivel ha már PHP-val dolgoztam, és hosszú távra szántam a rendszert, akkor bizonyára úgy terveztem meg, hogy könnyen módosítható legyen ilyen esetekben. Vagy nem terveztem semmit (ez voltam én), mint az egyszeri gazda, aki ártérre építette a házát, aztán rázza az ég felé az öklét, amikor elmossa a folyó.
76

Pedig már eltelt jópár nap,

Hidvégi Gábor · 2015. Már. 28. (Szo), 14.37
Pedig már eltelt jópár nap, mióta megjelent ez a blogmark, és még mindig nem értetted meg, de ez szemmel láthatólag nem zavar abban, hogy itt okoskodj. Ráadásul az sem, hogy egyik hozzászólásoddal ellentmondasz a másiknak.
78

Jobb így

bamegakapa · 2015. Már. 28. (Szo), 15.27
Sokunknak írtad ezt, de mivel nem tervezed elmagyarázni, és én sem tervezem, hogy még egyszer beleolvassak ebbe az irományba, ez már így is fog maradni.

Az ellentmondás nem tűnt fel, ha fontos lenne, bizonyára rámutatnál.
80

A 25-ben már kifejtettem, de

Hidvégi Gábor · 2015. Már. 28. (Szo), 16.06
A 25-ben már kifejtettem, de te azóta is ugyanazokat a lózungokat ismétled.
27

Fontos

Hidvégi Gábor · 2015. Már. 26. (Cs), 11.38
Az írásban van egy másik nagyon fontos gondolat:

There are some developers out there who think that a project is never complete but always "work in progress" that needs constant refactoring. They assume that when a new version of the language is released that all developers will revisit existing code to see if it can be upgraded to include any new functionality, or simply to achieve the same result in a different way. This is *NOT* how things happen in the real world. Once a unit of work has been delivered to and accepted by the customer then that unit should be left alone until there is a very good reason to go back to it. I deal with enterprise applications which contain 2,000+ units of work, and if you think that I am going to examine all of those units each time a new PHP release comes out then you are seriously deluded. Taking time out to "fix" code which doesn't need fixing is non-productive and therefore not appreciated by the paying customer who wants improvements in the application that he can actually see.
28

?

BlaZe · 2015. Már. 26. (Cs), 13.07
Support? Security fixek? Valamint ki akar hozzányúlni bármihez, ami nem élő project? Ami élő project, az pedig "work in progress". Vagy ez a fickó dolgozik úgy valamin, hogy közben nem dolgozik rajta?
30

Komolyan nem értetted meg,

Hidvégi Gábor · 2015. Már. 26. (Cs), 13.56
Komolyan nem értetted meg, amit idéztem?
31

Szerintem érti és nem ért

winston · 2015. Már. 26. (Cs), 14.01
Szerintem érti és nem ért egyet vele. :) Egyénként én sem értek vele egyet, főleg azért nem, mert számos kifutású projekt van, erős ezt általánosságában kijelenteni. Persze vannak olyan kódok, amik egyszer készülnek el, aztán kalap-kabát, de saját tapasztalataim szerint a legtöbb esetben igenis együtt kell élj a kóddal egy darabig (vagy más a te kódoddal, vagy te más kódjával), ami bizony azt jelenti, hogy "lezárt" kódokon matatsz, és nem puszta passzióból, hanem új igények, változások, bugfixek miatt.
32

Szerintem nem értitek.

Hidvégi Gábor · 2015. Már. 26. (Cs), 14.10
Szerintem nem értitek. Olvassátok el az elejétől, aztán jön ez a mondat:
Once a unit of work has been delivered to and accepted by the customer then that unit should be left alone until there is a very good reason to go back to it
Az aláhúzott rész pont lefedi a support és biztonsági javítások körét.
33

Én a részemről értem, erről

winston · 2015. Már. 26. (Cs), 14.20
Én a részemről értem, erről biztosíthatlak ;) Ellenben ez meg hozzáállás kérdése, és megint csak azt tartom: erős ilyen általánosságokat ennyire kerek perec megmondani. Az én szemléletemben egy kódrész elég sokáig "work in progress", pont azért, mert a saját tapasztalataim alapján életszerűtlen az egyszer átadom és kész. A "very good reason" bekövetkezése sokkal inkább business as usual, mint kivételes eset. És mielőtt a kákát keresnéd a csomón: nem állítanék olyat, hogy minden projekt ilyen, és ez az egy igaz út. Én azt mondom, ez a tapasztalatom, azok alapján a projektek alapján, amiken én dolgoztam.
34

Elfogadom, amit írsz; nem

Hidvégi Gábor · 2015. Már. 26. (Cs), 14.28
Elfogadom, amit írsz; nem tudom, ez mennyire általános. Nekem jópár munkám van, ami elkészült, és utána évekig használták gond nélkül. Csak akkor nyúltam hozzájuk, ha szükség volt rá, magamtól semmi refaktoring, ilyesmi.
39

A very good reason az, hogy

BlaZe · 2015. Már. 26. (Cs), 15.36
A very good reason az, hogy élő a project. Nyilván nem kell minden új verzióra azonnal ráugrani, de ha nagyon visszamaradsz és nem update-elsz tervezetten, akkor könnyen egy komoly technical debt-ben találod magad amit akkor kell megfizetned, amikor legjobban fáj. Pl pont akkor nem tudsz reagálni egy secfixre, ügyféligényre, vagy bármire, amikor kéne, mert elmúlt a kompatibilitásod és először azon kell átrágnod magad.

Amire ki akartam lyukadni, hogy olyan nincs, hogy futó project, de nem élő kód. Élő kódot pedig ésszerű karban tartani. Ezért én értelmetlennek találom az idézetet.

Aki pedig nem élő kódot refaktorálgat... annak sok az ideje, és túl sok bevétele van :)
44

Teljesen szubjektív, amit a

Hidvégi Gábor · 2015. Már. 26. (Cs), 16.14
Teljesen szubjektív, amit a technical debtről írsz. Én például csak azért váltok újabb és újabb php verziókra, mert biztonsági réseket foltoznak be, egyébként semmilyen újításnak tartott dolgot az 5.0 óta nem használok, mert nélkülük is lehet gyors, biztonságos, karbantartható és jó programot írni.

Minden újabb nyelvi eszköz növeli a hibázás lehetőségét, valamint az átláthatósághoz szükséges időt. Ezért célszerű a kódot a lehető legegyszerűbb eszközökkel elkészíteni.
48

Teljesen szubjektív, amit a

BlaZe · 2015. Már. 26. (Cs), 16.41
Teljesen szubjektív, amit a technical debtről írsz. Én például csak azért váltok újabb és újabb php verziókra, mert biztonsági réseket foltoznak be, egyébként semmilyen újításnak tartott dolgot az 5.0 óta nem használok, mert nélkülük is lehet gyors, biztonságos, karbantartható és jó programot írni.
Mosni is kézzel mosol bádogteknőben, és csak foltozod ha kilyukad? :)

Minden újabb nyelvi eszköz növeli a hibázás lehetőségét, valamint az átláthatósághoz szükséges időt. Ezért célszerű a kódot a lehető legegyszerűbb eszközökkel elkészíteni.
Vannak erősen ellentétes tapasztalataim, de ne menjünk bele, ilyen jellegű és megalapozottságú állításokkal nem látom értelmét vitatkozni.
52

Nyilván a bonyolódó

Hidvégi Gábor · 2015. Már. 26. (Cs), 17.26
Nyilván a bonyolódó eszközkészlet miatt választották a processzorgyártók a RISC architektúrát.
58

RISC

pythonozok · 2015. Már. 27. (P), 07.51
Konkrétan melyik proci gyártóra gondolsz?
Mert a legelterjedtebb szerver-desktop-notebook procik(Intel/AMD) tudtommal a mai napig CISC-nek számítanak még akkor is, ha belül RISC jellegű architektúrát használnak.
Az ARM... hát az névleg RISC, de... hol a határ CISC és RISC között?
Egyébként ez a RISC téma hogy kapcsolódik az előző hozzászóláshoz?
62

Egyébként ez a RISC téma hogy

BlaZe · 2015. Már. 27. (P), 13.39
Egyébként ez a RISC téma hogy kapcsolódik az előző hozzászóláshoz?
Biztos valami RISC proci assembly nyelvén fejleszt weboldalt, mert az egyszerű eszközkészlet csökkenti a hibázási lehetőségeket :)

Értem amúgy amit mondasz HG, de rossz következtetés. Nem véletlenül mondják, hogy ha RISC procira fejlesztesz, nagyon ki vagy téve a compilernek.
63

Én viszont egyre kevésbé

pythonozok · 2015. Már. 27. (P), 14.22
Én viszont egyre kevésbé értem az analógiát.
A RISC procikat azért találták ki, mert felfedezték, hogy a programozók magas szintű nyelveken fejlesztenek, a fordítónak mindegy, hogy mire generál kódot, viszont a processzor felépítése lényegesen egyszerűbb lesz és gyorsabban tud működni.
65

Lásd Occam borotvája, két

Hidvégi Gábor · 2015. Már. 27. (P), 16.07
Lásd Occam borotvája, két megoldás közül az egyszerűbbet célszerű választani. Ha folyamatosan nő az eszközkészlet, a végső kód nehezebben karbantartható lesz, mint ha fix alacsonyan tartod.
66

Az én tapasztalataim ezzel

bamegakapa · 2015. Már. 27. (P), 16.24
Az én tapasztalataim ezzel ellentétesek. A kevesebb nem mindig az egyszerűbb.
67

Beautiful is better than

Poetro · 2015. Már. 27. (P), 16.47
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.

The Zen of Python
68

Na de ez itt PHP... ;))

pythonozok · 2015. Már. 27. (P), 19.51
Na de ez itt PHP... ;))
69

Ezekre a mondatokra van

BlaZe · 2015. Már. 27. (P), 21.37
Ezekre a mondatokra van valami generátorod? :) Ha igazad lenne, logikai kapukat programoznánk, annál elemibb eszközkészlet nem nagyon van. De a csavaros elméjű emberek nem hagyták magukat itt leragadni, a logikai kapukat összerakva egyszercsak építettek processzorokat, majd feltalálták a programozási nyelveket, hogy bonyolultabban oldhassák meg ugyanazokat a problémákat. Amikor pedig már majdnem nem volt hova tovább, valami eretnek feltalálta az absztrakciót, és azóta bűnhődünk :)
70

Hidvégi generátor, olyan,

inf3rno · 2015. Már. 27. (P), 22.14
Hidvégi generátor, olyan, mint a fluxuskondenzátor, csak erősebb. :D (bocs, nem hagyhattam ki)

Egyébként ha már szóba került ez a legegyszerűbb megoldás a helyes, erre van bármilyen bizonyíték? Én pl sejtbiológiánál, élettannál csak az ellenkezőjét látom, iszonyatosan bonyolult rendszerek. Egyébként ha jól tudom, akkor egyáltalán nem is ilyen kontextusban szokták alkalmazni a mondást, hanem ha van két lehetséges megoldásod/elméleted egy problémára, akkor valószínűleg az egyszerűbb az, ami helyes. Jelen esetben viszont egyáltalán nem elméletekről beszélgetünk, hanem létező programozási nyelvekről, megközelítésekről, módszerekről, amire ez a mondás biztosan nem érvényes.
77

Kissé izzadságszagú, amit

Hidvégi Gábor · 2015. Már. 28. (Szo), 14.56
Kissé izzadságszagú, amit írsz. Mivel minden absztrakció szivárog, ezért célszerű a legalacsonyabban tartani a számukat. Egyik kirívó esete a programozásnak, ami azt mutatja, hogy nagyon nagy baj van, nemrég történt meg velem, amikor egy szűz Windows 8.1-es gépen elindítottam az album alkalmazást. Bár nem volt egy fájl sem, amit meg tudott volna jeleníteni, azaz a program teljesen üres, száz megabájt memóriát foglalt le ehhez. A tizenöt éves ACDSee 32 elindítás után eszik ötöt. Ezek után miről beszélünk?
84

FastStone

Gixx · 2015. Már. 29. (V), 09.25
ajánlom a FastStone Image viewert. Ingyenes, gyors, nagyszerű.
86

Kit érdekelnek a

Hidvégi Gábor · 2015. Már. 29. (V), 09.53
Kit érdekelnek a képmegjelenítők? Bármilyen más szoftvert is hozhattam volna fel példának, nem ez a lényeg.
106

Feltűnően agresszív vagy

Joó Ádám · 2015. Már. 30. (H), 18.50
Feltűnően agresszív vagy mostanában. Gondoltam szólok.
50

Viccnek, poénnak szánom, nem sértésnek

Gixx · 2015. Már. 26. (Cs), 16.55
Gáborom, te vagy a webfejlesztők Amish-a :D
57

rofl :D

inf3rno · 2015. Már. 26. (Cs), 22.25
rofl :D
38

+1, security fix,

inf3rno · 2015. Már. 26. (Cs), 15.22
+1, security fix, sebességbeli növekedés, mindkettő indokolhatja az új verzióra váltást. Ha fizetnek a karbantartásért, akkor elvárható mindez.
29

A legacy rendszereket

MadBence · 2015. Már. 26. (Cs), 13.32
A legacy rendszereket továbbra is lehet futtatni, ha ősrégi kódokat kell futtatnod, megteheted. Ha szeretnéd használni a PHP újabb verzióit, akkor viszont oldd meg magadnak az integrációt, ilyen egyszerű. Az ezer éves COBOL kódokat sem dobják ki, viszont ne várd el, hogy az magától kompatibilis legyen bármivel.

Amúgy: egyszerűbb nyelv -> könnyebben tudja más is implementálni, illetve maga az implementáció is egyszerűbb lesz.
54

comments

Pepita · 2015. Már. 26. (Cs), 22.04
Az itteni hozzászólások 100x érdekesebbek a cikknél... :)

Azért tényleg kicsit gáz 3 fő verzióval korábbi dolgokért sírni. Bár az array () nekem megszokott.
72

Érdekes, mert ha néha-néha

bamegakapa · 2015. Már. 27. (P), 23.57
Érdekes, mert ha néha-néha írok egy kis PHP snippetet, én is automatikusan array()-t használok. Pedig tudni tudom, hogy lehetne egyszerűbben, régebben még vártam is, mikor hozzák már be a []-t.

A megszokás rohadt nagy úr, még akkor is, ha nem tápláljuk.
74

Nekem változó. Ha

inf3rno · 2015. Már. 28. (Szo), 13.17
Nekem változó. Ha javascript-ben kódoltam egy hónapot, aztán tértem vissza PHP-ra, akkor automatikusan a [] állt kézre, utána meg mivel error-t dobott, ezért egy idő után rászoktam megint az array()-re. Most már valszeg nem lenne így.
111

<Empty>

tóthika · 2015. Ápr. 3. (P), 22.41
Nem akarok belekontárkodni, de ha kiveszik az
array()
nyelvi definíciót, akkor az azután nem fog létezni -> ergó ennyi lenne minden php oldal elején:

<?php

function array()
{
     $temp = get_func_get_args();
     $out = [];
     foreach($temp as $element)
     {
          array_push($element);
     }
     return $out;
}

?>
Bár azt nem mondom, hogy praktikus lenne így megoldani... Csak egy kerülőút...
112

function array(){ return

inf3rno · 2015. Ápr. 3. (P), 22.55

function array(){
    return func_get_args();
}
Egyébként jogos, elég olcsó megoldani a backward compatibility-t egy ilyen polyfill-el, bár ezeket általában fordított irányban szokták használni.

A probléma inkább az asszociatív tömböknél fog jelentkezni, mert ott is array()-t használnak. Nem tudom az ilyen nevesített paraméter átadás mennyire van megtámogatva, nem mélyültem bele a php újabb fejlesztéseibe.
113

<Empty>

tóthika · 2015. Ápr. 3. (P), 23.09
Például ez?

    <?php  
      
    function array()  
    {  
         $temp = get_func_get_args();  
         $out = [];  
         foreach($temp as $key => $element)  
         {  
              $out[$key] = $element;  
         }  
         return $out;  
    }  
      
    ?>  
Nekem ez így működik PHP ~5.6 alatt


Ja, igen...
Előbbi kód hibás volt:

array_push($element);
Helyett

array_push($out, $element);
Asszociatív tömbbe effajta kulcs-érték értékadást meg szerintem már támogat a PHP 4 - de ez szigorúan SZVSZ :)
114

Hát én még nem láttam olyat,

inf3rno · 2015. Ápr. 4. (Szo), 01.20
Hát én még nem láttam olyat, hogy

myfunc('a' => 1, 'b' => 2);
de egy ideje nem foglalkozom php-vel, szóval lehet, hogy azóta hozzácsapták a név szerinti paraméterezést.

Btw. csak arra akartam rámutatni, hogy teljesen felesleges bejárni a tömböt, a func_get_args() ugyanúgy tömböt ad vissza, nem objectet.
115

teljesen felesleges bejárni a

kuka · 2015. Ápr. 6. (H), 09.57
teljesen felesleges bejárni a tömböt, a func_get_args() ugyanúgy tömböt ad vissza
Az bizony igen, viszont a tóthika által használt get_func_get_args() visszatérési értékéről nem sokat tudunk. (Legalábbis a PHP dokumentációból…)