Alex Moran Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 echo Array(1, 2, 3)[0]; ^ Syntax error. PHP parseren forstår ikke det uttrykket, og PHP vil ikke engang prøve å kjøre koden. Dereferencing ble lagt til i PHP 5.5, så den koden kjører dermed helt fint og spytter ut det korrekte svaret 1. Lenke til kommentar
GeirGrusom Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 (endret) Dereferencing ble lagt til i PHP 5.5, så den koden kjører dermed helt fint og spytter ut det korrekte svaret 1.Dereferencing er ikke lagt til. Det er bare en unnskyldning de har for å ikke rette en bug i programmeringsspråket. PHP driver ikke med dereferencing da de har ikke den type referanser. echo (array(1, 2, 3))[0]; Parse error: syntax error, unexpected '[', expecting ',' or ';' in <b>[...][...] on line 1(edit: dette er PHP 5.5.5. utifra changeloggen kan jeg ikke se at dette er rettet) Sett parantes rundt og implementasjonen deres feiler. Rett og slett amatørmessig. Vitner om en kodebase som utviklerne ikke klarer å vedlikeholde. Endret 14. januar 2014 av GeirGrusom 3 Lenke til kommentar
Gjest Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 (endret) Ruby On Rails Ikke et språk. Django Ikke et språk. Jeg er fult klar over at Ruby on Rails er et rammeverk, men det er bygget på Ruby, det var det jeg ville frem til Djano er jo Python forøvrig, ikke jobbet med det noen gang, beklager. echo Array(1, 2, 3)[0];^ Syntax error. PHP parseren forstår ikke det uttrykket, og PHP vil ikke engang prøve å kjøre koden. $resultat = $udeklarertVariabel * PI;vil derimot fungere helt fint og returnere det flotte tallet 0. PHP 5.5.x echo [1, 2, 3][0]; Du får ut: 1 pi() gir forsatt 3.14, men man kan ikke gjøre operasjoner med en deklarert variabel, det vil jo gi en feilmelding og som du sa, svaret blir 0. Så man kjører gjerne isset() EDIT: Etter å faktisk brukt PHP noen år, på hobby basis ønsker jeg gjerne å sjekke ut andre språk som brukes i forbindelse med web (backend gjerne). Har tenkt en del på Ruby og bruke Ruby On Rails som en start. Andre med innspill på hva jeg burde kikke på? Endret 14. januar 2014 av Gjest Lenke til kommentar
GeirGrusom Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 (endret) PHP 5.5.x echo [1, 2, 3][0]; Du får ut: 1 PHP 5.5.x: echo ([1, 2, 3])[0]; Du får ut: Parse error: syntax error, unexpected '[', expecting ',' or ';' in [...][...] on line 1 Feilen vedvarer. De bare rettet et symptom på at noe er alvorlig galt med PHP sin parser. edit: De har spesielle syntaktiske regler for når indeksering er lovlig... unnskyld jeg mener "dereferencing", noe som er helt på jordet. Det er fordi parseren inneholder en ALVORLIG programmeringsfeil, fordi dette er helt grunnleggende funksjonalitet. Da de rettet feile... unnskyld, jeg mener da de implementerte featuren, så rettet de ikke problemet. De så en bug request feature request og implementerte den uten å faktisk rette opp i selve problemet. Så lenge et uttrykk har en returverdi så burde det være syntaktisk gyldig å indeksere resultatet fordi det er syntaktisk gyldig å indeksere alle objekter i PHP. Uavhengig om det er resultatet fra et funksjonskall, variabel eller whatnot. De har derimot bæsjet kraftig på leggen med PHP sin parser. Den er helt gal på en rekke områder. Her påpeker jeg én ting av mange som er galt med PHP sin parser, og dette er strengt tatt en cornercase, men det peker på at det er noe alvorlig galt med kildekoden til PHP når de for det første gjør dette feil i første omgang, og deretter ikke klarer å rette det på en skikkelig måte. Endret 14. januar 2014 av GeirGrusom 1 Lenke til kommentar
Matsemann Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 Ser ikke hva alt dette har med den originale påstandene din å gjøre? "Fast, secure, professional PHP framework". Knis! Som om de tingene er mulig i PHP. Uansett er disse diskusjonene maks uinteressante. Kom i det minste med synspunkter som er relevante i den virkelige verden og som påvirker en som bruker språket. Lenke til kommentar
GeirGrusom Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 (endret) Ser ikke hva alt dette har med den originale påstandene din å gjøre?Du ser ikke hvordan et amatørmessig utført programmeringsspråk virker uproffesjonelt og at en compiler som ikke genererer et abstrakt syntaks tre kan ansees som tregt? Eller hvorfor et run time som har serialize of unserialize funksjoner som bevarer referanser ansees som utrygt? Språket og run-time er helt stappet til randen med feller for nybegynnere. De fleste merker det bare ikke fordi det skal så mye til før PHP faktisk sier ifra. Uansett er disse diskusjonene maks uinteressante. Kom i det minste med synspunkter som er relevante i den virkelige verden og som påvirker en som bruker språket. json_decode returnerer null ved feil (om det faktisk feilet krever at du kaller json_last_error ettersom null er gyldig resultat for et json dokument) json_encode derimot returnerer FALSE dersom den feiler, og en string dersom alt gikk i orden. Det er tusenvis av slike ting. Umulig å ramse opp, men hensikten med rammeverkene som er bygget er for å lage et anti-corruption layer på toppen av makkverket som heter PHP. edit: kom igjen! Hva er bra med PHP? Hva gjør PHP bedre enn andre språk annet enn å være enklere å lære seg? Hvorfor bruke PHP? Så godt som alle alternativer er bedre enn PHP. Endret 14. januar 2014 av GeirGrusom 3 Lenke til kommentar
Lycantrophe Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 edit: kom igjen! Hva er bra med PHP? Hva gjør PHP bedre enn andre språk annet enn å være enklere å lære seg? Hvorfor bruke PHP? Så godt som alle alternativer er bedre enn PHP. b-but it's so easy to get shit done 1 Lenke til kommentar
Matsemann Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 Du ser ikke hvordan et amatørmessig utført programmeringsspråk virker uproffesjonelt og at en compiler som ikke genererer et abstrakt syntaks tre kan ansees som tregt? Eller hvorfor et run time som har serialize of unserialize funksjoner som bevarer referanser ansees som utrygt? Språket og run-time er helt stappet til randen med feller for nybegynnere. De fleste merker det bare ikke fordi det skal så mye til før PHP faktisk sier ifra. Påstanden din: "Fast, secure, professional PHP framework". Knis! Som om de tingene er mulig i PHP. PHP er "raskt nok" for veldig mye. Og nå snakker vi om et rammeverk her. Da er det snakk om hvor relativt raskt det er i forhold til tilsvarende rammeverk og/eller sammenlignet med å gjøre det i stock PHP. Selve PHP er trygt nok bare man ikke er idiot. Samme prinsippene gjelder som med tilsvarende språk, at man ikke skal stole på brukerinput osv. Og igjen, det er snakk om rammeverket. Har du prøvd det? Hva konkret med det gjør at det ikke er profesjonelt? Om alt du kan si er at det er bygget på PHP er det bare fjas. json_decode returnerer null ved feil (om det faktisk feilet krever at du kaller json_last_error ettersom null er gyldig resultat for et json dokument) json_encode derimot returnerer FALSE dersom den feiler, og en string dersom alt gikk i orden. Det er tusenvis av slike ting. Umulig å ramse opp, men hensikten med rammeverkene som er bygget er for å lage et anti-corruption layer på toppen av makkverket som heter PHP. Tja, slik er det vel i alle språk? Kunne ikke tenkt meg å skrive Java uten å bruke biblioteker som Guava, f. eks. (og nå begynner dere vel å rakke ned på Java... ) Ang. json er det jo ikke verre enn å bruke en knøttlite bibliotek, eller skrive det selv, som kaster exceptions istedet for disse feilkodene. edit: kom igjen! Hva er bra med PHP? Hva gjør PHP bedre enn andre språk annet enn å være enklere å lære seg? Hvorfor bruke PHP? Så godt som alle alternativer er bedre enn PHP. Jeg synes ikke selv PHP er så fantastisk bra. Har brukt det i jobbsammenheng, men vil ikke bruke det om jeg absolutt ikke må. Men det er langt fra så forferdelig som mange skal ha det til. Virker mest som om folk har lest seg opp enkelte corner cases og melker dem alt de kan, uten å ha kodet noe særlig PHP. Men premisset her er feil. PHP må ikke være bedre enn andre språk, det holder at det er godt nok for hva man ønsker å uttrette. 1 Lenke til kommentar
Lycantrophe Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 Selve PHP er trygt nok bare man ikke er idiot. Samme prinsippene gjelder som med tilsvarende språk, at man ikke skal stole på brukerinput osv.:--------------------------------------------D Lenke til kommentar
Matsemann Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 (endret) EDIT: Etter å faktisk brukt PHP noen år, på hobby basis ønsker jeg gjerne å sjekke ut andre språk som brukes i forbindelse med web (backend gjerne). Vel, jeg har prøvd NodeJS på et prosjekt nå som backend. Veldig lett å komme igang, men føles fortsatt litt umodent. Mange av bibliotekene vi brukte hadde bugs og ofte dårlig dokumentasjon. Det er masse biblioteker å velge i, men felles for mange er at de er skrevet av enkeltpersoner og blir dårlig vedlikeholdt. Jeg synes mengden callbacks ble slitsom. Men anbefaler å prøve ut for å få et annet synspunkt på hvordan ting kan løses. Ellers har jeg et annet prosjekt nå med Java, der Spring brukes. Også en backend, en REST service, så har ikke prøvd templating og slikt særlig. Her er alt statisk typa og litt corporate, så en veldig overgang fra NodeJS/PHP. Men masse bra dokumentasjon og solide rammeverk. :--------------------------------------------D ? Endret 14. januar 2014 av Matsemann Lenke til kommentar
Lycantrophe Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 (endret) Wait, du er seriøs? Ok, get this. Når man snakker om sikkerhet, både i runtime og (statisk) verifisering under utvikling, er ikke PHP på listen engang. Endret 14. januar 2014 av Lycantrophe Lenke til kommentar
Matsemann Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 Wait, du er seriøs? Mer seriøs enn en som ikke gjør annet enn å sitere innlegg og slenge på tullete ting Nå snakker du om en annen type sikkerhet enn jeg tenkte på. Som sagt, dette var snakk om et rammeverk som påstod det var sikkert. Sett i sammenheng som at det ikke skal være sikkerhetshull som lar brukere av webtjenesten få tilgang til å gjøre ting de ikke var ment. Lenke til kommentar
Lycantrophe Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 Mer seriøs enn en som ikke gjør annet enn å sitere innlegg og slenge på tullete ting Shots fired. Nå snakker du om en annen type sikkerhet enn jeg tenkte på. Som sagt, dette var snakk om et rammeverk som påstod det var sikkert. Sett i sammenheng som at det ikke skal være sikkerhetshull som lar brukere av webtjenesten få tilgang til å gjøre ting de ikke var ment.Og "selve PHP" sikter til rammeverk, går jeg ut ifra? Lenke til kommentar
Djn Skrevet 14. januar 2014 Del Skrevet 14. januar 2014 (endret) Tja, slik er det vel i alle språk? Kunne ikke tenkt meg å skrive Java uten å bruke biblioteker som Guava, f. eks. (og nå begynner dere vel å rakke ned på Java... ) Ang. json er det jo ikke verre enn å bruke en knøttlite bibliotek, eller skrive det selv, som kaster exceptions istedet for disse feilkodene. Java er på mange måter mye bedre - språket er veldefinert og noenlunde kompetent implementert, det er til og med flere separate implementasjoner som er noenlunde enige. Standard-libraryet er ikke absolutt konsekvent, men det er fortsatt langt mer forutsigbart enn PHP, spesielt når man holder på med funksjoner som logisk "hører sammen". Ja, Java er ordrikt og ganske kjedelig å skrive - men det er så mye ryddigere skrudd sammen at det er flaut. Endret 14. januar 2014 av Djn 1 Lenke til kommentar
GeirGrusom Skrevet 15. januar 2014 Del Skrevet 15. januar 2014 (endret) Nå snakker du om en annen type sikkerhet enn jeg tenkte på. Som sagt, dette var snakk om et rammeverk som påstod det var sikkert. Sett i sammenheng som at det ikke skal være sikkerhetshull som lar brukere av webtjenesten få tilgang til å gjøre ting de ikke var ment. Åja, slik som at PHP sin strcmp returnerer 0 dersom et argument ikke er en string, noe dokumentasjonen ikke sier en dritt om og som kan benyttes for å omgå passordvalidering? Løsningen her er å bruke === 0 istedet for == 0, men en må alltid huske på det. Endret 15. januar 2014 av GeirGrusom 1 Lenke til kommentar
tomsi42 Skrevet 16. januar 2014 Del Skrevet 16. januar 2014 Det er vel på sin plass å gratulere Tcl med 25-år's dagen? For de som lurer på hva Tcl er, så synes jeg dette er en fin beskrivelse: In other words, Tcl as a language is what would happen if Lisp and csh met at a party, got way too drunk, hooked up, got pregnant, and kept drinking throughout the pregnancy. Lenke til kommentar
Gloria Skrevet 2. mars 2014 Del Skrevet 2. mars 2014 (endret) Jeg har nå sett gjennom en 7 timer lang videoserie om det fundamentale i C# (http://channel9.msdn.com/Series/C-Sharp-Fundamentals-Development-for-Absolute-Beginners) Jeg lurer nå på hva som er den beste måten for å gå videre. Har tenkt litt på en av disse bøkene: http://www.amazon.co.uk/Microsoft-Visual-2010-Step-Package/dp/0735626707 http://www.amazon.co.uk/5-0-Nutshell-The-Definitive-Reference/dp/1449320104 http://www.amazon.co.uk/Pro-NET-Framework-Professional-Apress/dp/1430242337 Men jeg vet ikke helt. Endret 2. mars 2014 av Relio Lenke til kommentar
torbjørn marø Skrevet 3. mars 2014 Del Skrevet 3. mars 2014 Jeg har nå sett gjennom en 7 timer lang videoserie om det fundamentale i C# (http://channel9.msdn.com/Series/C-Sharp-Fundamentals-Development-for-Absolute-Beginners) Jeg lurer nå på hva som er den beste måten for å gå videre. Har tenkt litt på en av disse bøkene: http://www.amazon.co.uk/Microsoft-Visual-2010-Step-Package/dp/0735626707 http://www.amazon.co.uk/5-0-Nutshell-The-Definitive-Reference/dp/1449320104 http://www.amazon.co.uk/Pro-NET-Framework-Professional-Apress/dp/1430242337 Men jeg vet ikke helt. Du har sett gjennom 7 timer på channel 9 - det er imponerende. Ikke glem at du må kode, kode, kode, øve, øve, øve. Lese litt eller se en liten video, og så kode, kode, trene og kode igjen Det er kun én måte å virkelig bli en dyktig utvikler, og det er å gjøre det. Men for å kunne gi råd om bøker - hva er programmeirngsnivået/erfaringen din? Og hva ønsker du å oppnå (som i: du vil lære alt som er å lære om .NET-platformen, eller du vil kunne lage webløsninger, eller du vil rett og slett lære å programmere)? Lenke til kommentar
Gloria Skrevet 3. mars 2014 Del Skrevet 3. mars 2014 Jeg har nå sett gjennom en 7 timer lang videoserie om det fundamentale i C# (http://channel9.msdn.com/Series/C-Sharp-Fundamentals-Development-for-Absolute-Beginners) Jeg lurer nå på hva som er den beste måten for å gå videre. Har tenkt litt på en av disse bøkene: http://www.amazon.co.uk/Microsoft-Visual-2010-Step-Package/dp/0735626707 http://www.amazon.co.uk/5-0-Nutshell-The-Definitive-Reference/dp/1449320104 http://www.amazon.co.uk/Pro-NET-Framework-Professional-Apress/dp/1430242337 Men jeg vet ikke helt. Du har sett gjennom 7 timer på channel 9 - det er imponerende. Ikke glem at du må kode, kode, kode, øve, øve, øve. Lese litt eller se en liten video, og så kode, kode, trene og kode igjen Det er kun én måte å virkelig bli en dyktig utvikler, og det er å gjøre det. Men for å kunne gi råd om bøker - hva er programmeirngsnivået/erfaringen din? Og hva ønsker du å oppnå (som i: du vil lære alt som er å lære om .NET-platformen, eller du vil kunne lage webløsninger, eller du vil rett og slett lære å programmere)? For øyeblikket har jeg egentlig bare lyst til å mestre C#, og lage et spill ved hjelp av for eksempel Unity når den tid kommer. Er ikke noe mer enn et hobbyprosjekt. Det jeg kan av C# er vel det du ser i den videoserien. Jeg har hvertfall bestilt denne boken: http://www.amazon.com/Introduction-Joes-Pros-Exam-70-536/dp/1451581718/ Ser den bra ut? Lenke til kommentar
torbjørn marø Skrevet 8. mars 2014 Del Skrevet 8. mars 2014 Jeg har hvertfall bestilt denne boken: http://www.amazon.com/Introduction-Joes-Pros-Exam-70-536/dp/1451581718/ Ser den bra ut? Jeg har aldri hørt om den boken der, men den er helt sikkert en grei introduskjon til alt det mest grunnleggende. I tillegg til å lese om C# bør du kjøpe en bok som forteller deg litt mer generelt om hva som er viktig når man programmerer. Anbefalte bøker som lærer deg gode praksiser er blant andre: Clean Code Code Complete The Pragmatic Programmer Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå