jorgis Skrevet 28. oktober 2008 Del Skrevet 28. oktober 2008 Hvordan nærmer de seg C++ med dette? Strengt tatt så nærmer de seg ingen, men går heller langt vekk fra eksisterende språk og gjør seg atter en gang mindre konsekvent. De nærmer seg kanskje ikke C++ direkte, men ligner på C++ sin tendens til å introdusere ny funksjonalitet ved å tilsette flere syntaktiske elementer og symboler, flere reserverte keywords og alternativ syntaks, som gjør koden fort voldsomt rotete og vanskelig å lese. Håper inderlig PHP-folka klarer å unngå at dette skjer... Lenke til kommentar
shaker Skrevet 29. oktober 2008 Del Skrevet 29. oktober 2008 De idiotene som fant på dette er så fornøyde med seg selv så de kommer nok ikke til å endre på det. Lenke til kommentar
Peter Skrevet 29. oktober 2008 Del Skrevet 29. oktober 2008 Hvordan nærmer de seg C++ med dette? Strengt tatt så nærmer de seg ingen, men går heller langt vekk fra eksisterende språk og gjør seg atter en gang mindre konsekvent. De nærmer seg kanskje ikke C++ direkte, men ligner på C++ sin tendens til å introdusere ny funksjonalitet ved å tilsette flere syntaktiske elementer og symboler, flere reserverte keywords og alternativ syntaks, som gjør koden fort voldsomt rotete og vanskelig å lese. Håper inderlig PHP-folka klarer å unngå at dette skjer... Kan du gi et C++-eksempel på dette? Lenke til kommentar
jorgis Skrevet 29. oktober 2008 Del Skrevet 29. oktober 2008 Hvordan nærmer de seg C++ med dette? Strengt tatt så nærmer de seg ingen, men går heller langt vekk fra eksisterende språk og gjør seg atter en gang mindre konsekvent. De nærmer seg kanskje ikke C++ direkte, men ligner på C++ sin tendens til å introdusere ny funksjonalitet ved å tilsette flere syntaktiske elementer og symboler, flere reserverte keywords og alternativ syntaks, som gjør koden fort voldsomt rotete og vanskelig å lese. Håper inderlig PHP-folka klarer å unngå at dette skjer... Kan du gi et C++-eksempel på dette? Når andre ender opp med å steppe inn og foreslå alternativ syntaks for å få språket mer ryddig, er noe gale. Eksempler? Det er bare å se på wiki-artikkelen om C++0x, og telle antall nye keywords (auto, decltype, constexpr, requires, concept, concept_map, nullptr, static_assert m.fl.) og mengde ny syntaks (ny alternativ syntaks for funksjonsdefinisjoner, f.eks.). Lenke til kommentar
qualbeen Skrevet 29. oktober 2008 Del Skrevet 29. oktober 2008 Dette må jo være en forsinka aprilspøk? Det går da ikke an.. Hva skjer hvis man leker seg med namespaces slik det er i dag, altså doble kolon? Selv har jeg litt dårlig med tilgang på php6, mao vanskelig å teste... Lenke til kommentar
shaker Skrevet 30. oktober 2008 Del Skrevet 30. oktober 2008 Problemet sånn som jeg forsto det var at dette kunne skape problemer: class Something { static function me() { } } namespace Something; function me() { } Vil Something::me() være metoden me i klassen Something eller funksjonen me i namespacet Something? Lenke til kommentar
OISNOT Skrevet 30. oktober 2008 Del Skrevet 30. oktober 2008 Det beste eksempelet på fjaset med dette her er at ingen namespaces lengre kan starte på n eller t, i så tilfelle må det bli \\n og \\t Logisk? Skeptisk Erm, escape virker bare innenfor dobbel quotes. "\n" !== '\n' I single quotes kan du escape single quote '\'' men ellers ingenting afaik. namespace no\name; //vil funke helt fint Det er bedre enn noen av de andre forslagene, slik som ~ Lenke til kommentar
Lokaltog Skrevet 30. oktober 2008 Del Skrevet 30. oktober 2008 Det dummeste med å bruke \ som tegn er etter min mening at det kun brukes til escaping. Når jeg ser f.eks. no\name, så leser jeg instinktivt \n for seg selv, som et escape-tegn. Hvorfor ikke bruke / hvis man skal organisere det slik? De fleste som kjører PHP gjør det vel på Linux, så argumentet om at "folk som programmerer i Windows vil kjenne igjen \ som separator" faller jo litt bort. Det tar ikke spesielt mye lengre tid å skrive / fremfor \ heller, men når førsteprioritet er IDE-kompatibilitet, så er det lettere å forstå hvordan noen kan ta denne beslutningen. Namespace\Class::method(); eller Namespace/Class::method();? Jeg synes det siste ser best ut, hvis man skal bruke slash som separator. Lenke til kommentar
OISNOT Skrevet 30. oktober 2008 Del Skrevet 30. oktober 2008 (endret) Akkurat nå så deler eg gjerne inn klasser slik som class No_Name_Test {} som {INCLUDEDIR}\No\Name\Test.php Dette vil nå bli namespace No\Name; class Test {} $t = new No\Name\Test(); Det blir jo da lik filstrukturen for meg. Synes i starten å bruke \ var ganske latterlig, men det har vokst på meg. Endret 30. oktober 2008 av OISNOT Lenke til kommentar
qualbeen Skrevet 30. oktober 2008 Del Skrevet 30. oktober 2008 greit poeng OISNOT, men igjen: filstruktur har som regel skråstreken andre veien.. Problemet sånn som jeg forsto det var at dette kunne skape problemer: namespace Something; function me() { } Vil Something::me() være metoden me i klassen Something eller funksjonen me i namespacet Something? Andre språk klarer namespace.Class.method(). Da burde jo PHP også klare støtte for det - hvis de virkelig ville. namespace.method() gir lite mening i mitt hode, men men... Lenke til kommentar
Peter Skrevet 30. oktober 2008 Del Skrevet 30. oktober 2008 De kunne brukt DIRECTORY_SEPARATOR når de først var igang. Dessuten tror jeg det er større sjanse for at windows-brukere kjenner igjen / som dir, i forhold til linux-folk som kjenner igjen \ som det samme. / brukes kun som separator, mens \ brukes som separator _og_ escape. æsj Drittspråk. Lenke til kommentar
shaker Skrevet 30. oktober 2008 Del Skrevet 30. oktober 2008 Andre språk klarer namespace.Class.method(). Da burde jo PHP også klare støtte for det - hvis de virkelig ville.namespace.method() gir lite mening i mitt hode, men men... Du kan det i PHP også. \some\long\nested\namespace\Class::staticMethod(); Lenke til kommentar
Ernie Skrevet 31. oktober 2008 Del Skrevet 31. oktober 2008 (endret) Dette må jo være en forsinka aprilspøk? Det går da ikke an..Hva skjer hvis man leker seg med namespaces slik det er i dag, altså doble kolon? Selv har jeg litt dårlig med tilgang på php6, mao vanskelig å teste... Det som skjer er nok at du er pent nødt til å endre til «backslash» når endringen havner i en build vel å merke. Dessverre er dette PHP 5.3-funksjonalitet, noe som betyr at det kommer til å ta litt tid før vi ser en større oppdatering av PHP og enda lengre til vi faktisk kan forvente at webhotelene har det Slik det er nå så blir det jo iallfall 2010 før PHP6 er interessant, sannsynligvis 2011-2012. Gøy Endret 31. oktober 2008 av Ernie Lenke til kommentar
jorgis Skrevet 31. oktober 2008 Del Skrevet 31. oktober 2008 (endret) greit poeng OISNOT, men igjen: filstruktur har som regel skråstreken andre veien.. Problemet sånn som jeg forsto det var at dette kunne skape problemer: namespace Something; function me() { } Vil Something::me() være metoden me i klassen Something eller funksjonen me i namespacet Something? Andre språk klarer namespace.Class.method(). Da burde jo PHP også klare støtte for det - hvis de virkelig ville. namespace.method() gir lite mening i mitt hode, men men... I hvert fall i PHP, hvor . ikke er bundet til noe i objekt-/namespace-kontekst fra før, burde dette vært en smal sak. . er fra før brukt som strengkonkatenering, men er vel bare enkelt og greit å definere betydningen til å være annerledes i objekt-kontekst (altså på venstreside av en expression og i en funksjons-/metode-/klasse-definisjon). Blir litt lik syntaks som på pakker i Java (Java sine namespaces), som burde være godt kjent blant PHP-utviklerne. Eks: namespace.Class::method(); import tree.binarytree; tree.binarytree.Eulertraversal::postOrderTraversal(); Jeg er veldig for å la PHP adoptere syntaktiske elementer fra Java, da jeg synes at Java er et veldig oversiktlig og letthåndterbart språk. Endret 31. oktober 2008 av jorgis Lenke til kommentar
Cucum(r) Skrevet 4. november 2008 Del Skrevet 4. november 2008 The solution to PHP namespace seperator issues. Lenke til kommentar
loathsome Skrevet 4. november 2008 Del Skrevet 4. november 2008 The solution to PHP namespace seperator issues. (-_-メ) Finn en annen tråd å poste den i. Lenke til kommentar
qualbeen Skrevet 4. november 2008 Del Skrevet 4. november 2008 Da har jeg mer tro på http://www.suspekt.org/2008/11/03/php-usb-...space-problems/ igrunn... Lenke til kommentar
Ernie Skrevet 5. november 2008 Del Skrevet 5. november 2008 Da har jeg mer tro på http://www.suspekt.org/2008/11/03/php-usb-...space-problems/ igrunn... Hahaha ... der har vi nok løsningen ja Btw: måtte bare teste ut en aldri så liten myte i dag: echo er raskere enn print. Kanskje ikke overraskende, men forskjellen er mikroskopisk for å si det mildt. Lenke til kommentar
qualbeen Skrevet 2. desember 2008 Del Skrevet 2. desember 2008 Finnes det egentlig noen god måte å beskytte seg mot session hijacking? Vha. javascript er det jo relativt lett å få uteverte cookies - så hvis jeg klarer å få deg til å besøke min side, vil jeg jo med ett sitte på samtlige av dine cookies.. Så jeg lurer på hvordan man egentlig kan beskytte seg mot sesjons-tyveri. Én løsning er såklart å kreve re-autentisering hver gang man vil gjøre noe på nettstedet (aka betaling i nettbank). Hvilket andre muligheter har man? Lenke til kommentar
Gjest Slettet+6132 Skrevet 2. desember 2008 Del Skrevet 2. desember 2008 Lagre IP i session og sjekke at den stemmer for hver gang? 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å