---

Hej

Jeg sidder og hygger mig med et privat projekt. Min oprindelige tanke
var, at skrive det til PHP4, med for øje at det relativt nemt kunne
skrives om til PHP5. Men jeg har ikke rigtigt kunnet holde fingrene væk,
og jeg er også lidt i tvivl, om det er noget pjat.

Jeg har snuset lidt rundt på nettet, og hvad jeg læser værende det
største problem, er manglende understøttelse hos webhoteller. Men de må
vel følge efterspørgslen, eller hvad.

Sagt på en anden måde. Kaster I også jer over PHP5 som sultne svin,
eller afventer I en version 5.1 og/eller billige webhoteller.


/Bent

---

>Jeg sidder og hygger mig med et privat projekt. Min oprindelige tanke
>var, at skrive det til PHP4, med for øje at det relativt nemt kunne
>skrives om til PHP5. Men jeg har ikke rigtigt kunnet holde fingrene væk,
>og jeg er også lidt i tvivl, om det er noget pjat.
>
>Jeg har snuset lidt rundt på nettet, og hvad jeg læser værende det
>største problem, er manglende understøttelse hos webhoteller. Men de må
>vel følge efterspørgslen, eller hvad.
>
>Sagt på en anden måde. Kaster I også jer over PHP5 som sultne svin,
>eller afventer I en version 5.1 og/eller billige webhoteller.

Jeg vil da mene at det kun er et spørgsmål om tid inden webhotellerne
begynder at understøtte PHP5. Men har du et site som skal op og køre
inden du finder (eller laver!) en server der kan, må du jo naturligvis
lave det i PHP4. Og så er forskellen jo heller ikke så voldsom så det
vil være snildt at opgradere senere. Hvis du bruger/laver masser af
egne funktioner (åh de er dejlige er de!) og strukturerer din kode
godt - og endda holder PHP5 i tanke - vil jeg mene det vil være en
temmelig snild sag at opgradere koden til PHP5.

---

Frowning Freezer wrote:
> Jeg vil da mene at det kun er et spørgsmål om tid inden webhotellerne
> begynder at understøtte PHP5. Men har du et site som skal op og køre
> inden du finder (eller laver!) en server der kan, må du jo naturligvis
> lave det i PHP4. Og så er forskellen jo heller ikke så voldsom så det
> vil være snildt at opgradere senere. Hvis du bruger/laver masser af
> egne funktioner (åh de er dejlige er de!) og strukturerer din kode
> godt - og endda holder PHP5 i tanke - vil jeg mene det vil være en
> temmelig snild sag at opgradere koden til PHP5.
>
Jah, det er hovedsageligt klasse-håndteringen der er forbedret i PHP5

Største forskel er at constuctoren nu hedder __construct() istedet for
klassens navn...
Derudover kan man nu lave private/public, ordenlig nedarvning og
interfaces...

Altså, hvis du ikke benytter mange klasser er forskellen på PHP4 og PHP5
ikke ret stor...

Morten Fangel / fangel /

---

On Thu, 17 Mar 2005 13:01:34 +0100, Morten Fangel wrote:

> Største forskel er at constuctoren nu hedder __construct() istedet for
> klassens navn...
> Derudover kan man nu lave private/public, ordenlig nedarvning og
> interfaces...
Og så lige huske, at hvis ikke private/protected explicit er angivet, er
alle attributter/metoder public.
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

>> egne funktioner (åh de er dejlige er de!) og strukturerer din kode
>> godt - og endda holder PHP5 i tanke - vil jeg mene det vil være en
>> temmelig snild sag at opgradere koden til PHP5.
>>
>Jah, det er hovedsageligt klasse-håndteringen der er forbedret i PHP5
>
>Største forskel er at constuctoren nu hedder __construct() istedet for
>klassens navn...
>Derudover kan man nu lave private/public, ordenlig nedarvning og
>interfaces...

Ja, og der er jo ingen der siger at man SKAL bruge classes - det er
langt fra altid at det er optimalt at bruge. Funktioner giver oftest
mere fleksible kode.

>Altså, hvis du ikke benytter mange klasser er forskellen på PHP4 og PHP5
>ikke ret stor...

Nej nemlig.

---

On 2005-03-17, Frowning Freezer <pub1@hverdag.dk> wrote:
> Ja, og der er jo ingen der siger at man SKAL bruge classes - det er
> langt fra altid at det er optimalt at bruge. Funktioner giver oftest
> mere fleksible kode.

Kan du underbygge din påstand om at "det langt fra altid er optimalt"
med klasser og at funktioner er mere fleksible?

--
Med venlig hilsen
- Jacob Atzen

---

>> Ja, og der er jo ingen der siger at man SKAL bruge classes - det er
>> langt fra altid at det er optimalt at bruge. Funktioner giver oftest
>> mere fleksible kode.
>
>Kan du underbygge din påstand om at "det langt fra altid er optimalt"
>med klasser og at funktioner er mere fleksible?

Ja - fordi de forskellige funktioner du ønsker at udføre oftest er
individuelle, dvs. der er ikke nogen stram sammenhæng mellem dem på
den måde at hvis du kalder én funktion så er det også sandsynlig at du
kalder en anden funktion der arbejder med de samme variabler. Med
classes får du et ekstra niveau at skulle igennem for at komme til din
funktioner, hvilket jeg oftest ser som unødvendigt besvær.

Plus at det er enklere at kalde en funktion end først skal til at
oprettet et objekt.

Undtagelserne er selvfølgelig f.eks. en class der håndterer WML output
eller f.eks. en login class der holder styr på login, logud osv. Men i
det tilfælde er det netop praktisk og nyttigt fordi flere funktioner
arbejder med de samme variabler.

Derudover kan valget af classes også ligge i det ene faktum at du ikke
arbejder i "global scope" og derfor ikke behøver tænke lige så meget
over hvordan du navngiver dine funktioner.

Og jeg må jo hellere sige det inden nogen begynder at brokke sig:
Selvfølgelig handler classes ikke bare om en samling af funktioner,
men har selvfølgelig også andre fordele. Men jeg finder at det er ikke
så ofte jeg har brug for de fordele i min PHP kode - når jeg bare
strukturerer min kode ordentligt.

---

On 2005-03-20, Frowning Freezer <pub1@hverdag.dk> wrote:
>>Kan du underbygge din påstand om at "det langt fra altid er optimalt"
>>med klasser og at funktioner er mere fleksible?
>
> Ja - fordi de forskellige funktioner du ønsker at udføre oftest er
> individuelle, dvs. der er ikke nogen stram sammenhæng mellem dem på
> den måde at hvis du kalder én funktion så er det også sandsynlig at du
> kalder en anden funktion der arbejder med de samme variabler. Med
> classes får du et ekstra niveau at skulle igennem for at komme til din
> funktioner, hvilket jeg oftest ser som unødvendigt besvær.

Jeg er uenig. Det kommer naturligvis ganske an på, hvilken slags PHP
programmer man laver og hvordan man vælger at strukturere sin kode. Jeg
har i øvrigt ikke kunnet finde noget i dit indlæg, der underbygger, at
funktioner er mere fleksible. Du har argumenteret for, at de kan være
nemmere at bruge, men ikke at de er fleksible.

Jeg synes det er ærgeligt, når folk afskriver objekter så kategorisk.
Objekter gør livet nemmere for programmøren ligeså snart et program
bliver bare den mindste smule komplekst. Desuden kan man gøre visse ting
betydeligt pænere med objekter end man kan med rene funktioner. Det
kræver naturligvis, at man lærer at tænke objekt orienteret, hvilket
godt kan være ganske svært.

Min påstand er, at de fleste af dem der afskriver OOP er folk, der
aldrig har brugt den nødvendige tid og energi på at forstå, hvad OOP i
virkeligheden kan give af fordele.

--
Med venlig hilsen
- Jacob Atzen

---

Frowning Freezer wrote:

> Jeg vil da mene at det kun er et spørgsmål om tid inden webhotellerne
> begynder at understøtte PHP5.

Jeg forudser nu ikke nogen generel opgradring til PHP5 i hele
webhotel-branchen inden for kort tid. Opgraderingen til PHP5 medfører
stadig en del problematikker for eksisterende kode.

Plus, den større og større fokus der er kommet på sikkerhedsaspekter
velsagtens heller ikke advokerer til at opgradere sålænge der bliver
udsendt jævnlige vedligeholdelses versioner af PHP4-serien.

Og med webhotelpriser på 7-10 kr. pr. domæne giver det endnu mindre
grund til at opgradere til en problematisk ny version af PHP. Det er
meget svært at forudsige antallet af problemer dette vil generere på op
mod 500-1000 domænekunder på en enkelt server...

Jeg gætter på at et generelt løft i branchen først som minimum kommer i
løbet af 6-12 måneder når det for alvor er blevet en konkurrence
parameter at kunne tilbyde PHP5 (læs: når der er så meget PHP-software
på markedet der kræver PHP5 at det er nødvendigt at opgradere).

--
Med venlig hilsen
Geert Lund - www.gld.dk

---

Geert Lund wrote:

> Og med webhotelpriser på 7-10 kr. pr. domæne giver det endnu mindre
> grund til at opgradere til en problematisk ny version af PHP. Det er
> meget svært at forudsige antallet af problemer dette vil generere på op
> mod 500-1000 domænekunder på en enkelt server...

Backporten af PHP5-kode ifm. Zend-delen (hvilket bl.a. påvirkede fx Zend
Optimizer og ionCube) til PHP 4.3.10 gav en lille forsmag på hvilke
problemer der let kan opstå - jeg tror det er den mest problematiske
opgradering jeg til dato har set af en update der "blot adresserer
sikkerhedsproblemer".

PHP 4.3.10 har givet mange udviklere, support-fora, support-funktioner
osv. mange timers ekstra arbejde og grå hår i hovedet. På trods af at
problemet var velkendt (og dokumenteret) og en løsning var temlig nem at
overskue (opgradér din Zend Optimizer/ionCube) - men alligevel kom det
bag på rigtig - rigtig - mange mennesker grundet de mange komplet
mystiske fejl der pludselig opstod i "helt uskyldig og simpel" PHP-kode.

--
Med venlig hilsen
Geert Lund - www.gld.dk

---

On Thu, 17 Mar 2005 17:05:31 +0100, Geert Lund
<glund-news@post.tele.dk> wrote:

>Jeg forudser nu ikke nogen generel opgradring til PHP5 i hele
>webhotel-branchen inden for kort tid. Opgraderingen til PHP5 medfører
>stadig en del problematikker for eksisterende kode.

Jeg tvivler nu på at det almindelige webhotel har så mange kunder,
hvor en opgradering overhovedet vil give problemer.

Jeg tror, at de tilfælde, hvor der er risiko for at kode knækker, i
forvejen er setups, hvor folk vedligeholder deres egne systemer.

Den største grund til den manglende opgradering er ikke alene
fornuftig konservatisme (i forhold til mulige opgraderingsproblemer),
men unødvendig konservatisme, dovenskab og uvidenhed.

Jeg har oplevet flere webhosting-firmaer bruge gamle travere som
manglende argument til at opgradere fra PHP3 til PHP4. Derimod havde
de færreste betænkeligheder ved fx at opgradere hen over PHP3.0.7, der
medførte at rand() opførte sig anderledes.

Der er få webhosting-udbydere, hvor de ansvarlige for
opgraderingspolitikken rent faktisk tjekker changelogs (og ikke bare
desperat leder efter undskyldninger for at de ikke skal opgradere, "af
hensyn til kunderne"). De fleste kan i mine øjne fordeles på:

- De Forhippede Opgraderere. Udbydere, der tror, at cutting edge altid
er det mest hensigtsmæssige. Bruger bl.a. sikkerhed som argument, uden
at have kendskab til backports, der ville være langt mere
hensigtsmæssigt.

- De Clueless Måhellerefølgemedere. Udbydere, som nu og da opgraderer
når tilpas mange kunder er utilfredse. De har ikke kendskab til PHP
eller følger med på PHP-fronten, og bliver derfor overrasket, når en
ny udgave af PHP har ændret i en default-indstilling.

- De Fortabte Konservative. Udbydere, der holder sig til en vilkårlig
defekt udgave af en gammel version, for "Hvad nu hvis kunderne
forventer at tingene virker på den her måde?". De bruger argumentet
med at de har malet sig op i et hjørne som en god ting. De to-tre
kunder, der tilfældigvis stadigvæk er blevet hængene fra den gang, er
tilsyneladende vigtigere end hundredevis af kunder, hvis scripts ikke
kan komme til at fungere ordentligt.

Dertil kommer at det er de færreste, der i det hele taget har en
hensigtsmæssig konfiguration (open_basedir, safe_mode,
session.save_path, etc.).

Dog, folkene bag PHP gør det heller ikke ligefrem lettere at bestyre
et sikkert og hensigtsmæssigt setup.

--
- Peter Brodersen

---

Peter Brodersen wrote:

> Jeg tvivler nu på at det almindelige webhotel har så mange kunder,
> hvor en opgradering overhovedet vil give problemer.

Det er da klart at visse ting kan klares i opgraderingsfasen serverside
af teknikeren der opgraderer. Og at det derfor ikke vil medføre
ændringer set fra kundens synspunkt - umiddelbart.

Du nævner selv rand() som et af de underlige ændringer der gennem tiden
har været - jeg kan selv nævne andre (ikke dokumenterede via changelogs)
ændringer som har haft konsekvens - altså funktioner der ændrer opførsel
gennem versionerne.

Jeg argumenterer heller ikke for at man skal lade være med at opgradere
fordi nu forventer kunderne det virker sådan eller sådan - med et 7-12
kr. webhotel ville jeg faktisk nærmest hellere argumentere med "opgrader
da endelig og holder noget op med at virke som forventet - er det bare
ærgeligt - du får hvad du betaler for" [i bedste Mogens J. stil].

Men jeg tror altså ikke man skal have udviklet meget i PHP/MySQL før man
opdager at vilkårlige opgraderinger ikke bare glider glat - men ofte
kræver ændringer i settings, kodning og statements.

Så i forhold til opgradering af fx 10 maskiner med hver 500 webhoteller
- vil det - bare få procent af kunderne oplever problemer - give et
voldsomt ryk på support-funktionen og jeg tror simpelthen ikke ret mange
webhotel-udbydere er gearet til support-mæssigt at håndtere det - og det
kan være et argument for ikke blot at opgradere for at opgradere.

Men jeg tror også at markedet på det område er meget reguleret af udbud
og efterspørgsel. Så dovenskab, udvidenhed osv. kan ikke tillægges hele
grunden for den (pt.) manglende opbakning af PHP5 - netop af den grund
du selv nævner (og som jeg startede med at citere) - hvis 95-98% af dine
kunder ikke har behov for PHP5 og dine konkurrenter heller ikke har
udrullet det - hvorfor så bruge tid og ressourcer på at opgradere?


--
Med venlig hilsen
Geert Lund - www.gld.dk

---

On Thu, 17 Mar 2005 17:53:48 +0100, Peter Brodersen
<usenet2005@ter.dk> wrote:

>On Thu, 17 Mar 2005 17:05:31 +0100, Geert Lund
><glund-news@post.tele.dk> wrote:
>
>>Jeg forudser nu ikke nogen generel opgradring til PHP5 i hele
>>webhotel-branchen inden for kort tid. Opgraderingen til PHP5 medfører
>>stadig en del problematikker for eksisterende kode.
>
>Jeg tvivler nu på at det almindelige webhotel har så mange kunder,
>hvor en opgradering overhovedet vil give problemer.

well... det er _meget_ afhængigt af hvem der er kunder på de
respektive boxe.

9 ud af 10 boxe er opgraderet til php5 hos os i dag... enkelte boxe
hænger tilbage, pga. (og her nævner jeg ingen navne) "ikke optimal
php-kodning". Php4 er simpelthen et krav fra de pågældende kunder og
disses slutkundeløsninger.

På de boxe hvor vi har egne slutkunder har vi simpelthen bruteforced
php5 igennem. Dette gjorde vi ved at annoncerer en opgradering måneder
før det skete, sende remindere m. jævne mellemrum om at folk burde
teste i lokalt udviklingssetup (det har mange af vores kunder - men
det er ganske givet ikke typisk for mange "alm. webhotelkunder".

Umiddelbart før opgradering sendte vi en heads up m. links til det
mest gængse fejl.

Efter opgradering gnuflede vi nogle one-liner perlhacks som fixede de
meste generelle bugs i folks kode... og derudover bad vi folk surfe
deres sider igennem, samtidig m. at vi tailede errorlogs og fremsendte
til slutkunder, m. anmodning om "fix venligst".

Alt i alt en ikke helt triviel proces - og uanset hvad en proces som
fordrer en relativt stor og aktiv indsats af udbydere - m. mindre man
er sand bofh og blot sværger til at folk skal skrive anstændig kode i
fortid, nutid og fremtid.

--
vh
thomas, som normalt ikke hænger ud i denne gruppe, men blot blev
henledt af ham der peter