Fnugus..Du skulle ikke have haft point.:-( :-( De var til Christian.. Christianjeg opretter lige et point spørgsmål som tak for hjælpen. Fnugus din tyv :-)
Hvad skal du bruge det til, og bruger du $month_engl_array til andet?
Hvis du ikke har nogen speciel grund til at struktureret dit array som i spørgsmålet, er din løsning i #3 klart bedre.
Du ville også kunne bruge [url=http://dk1.php.net/manual/en/function.in-array.php]in_array[/b], men den er heller ikke særlig effektiv. #3 er stadig den bedste =)
Jamen jeg bruger $month_engl_array til noget andet, men jeg havde brug for at få Index'et til andet brug. Så jeg oprettede spørgsmålet da min gamle knark af en hjerne ikke lige kunne frembringe en løsning før jeg havde ramt "opret".. Så kom ideen selvfølgelig. Mem jeg tror også jeg bruger egen løsning i #3 .
Det lyder fornuftigt. Hvad er det i øvrigt for månedsnavne - engelske eller danske? Jeg undrer mig bare over may og okt, hvor 'y' og 'k' peger i hver sin retning *o)
Ole, hvis du ser med stadig.. Kan du så ikke svare på, hvordan det kan være strtotime("$date $month $year") Fungere, men strtotime($date $month_engl_index[$month] $year") giver 01-01-1970 ??
Endnu engang tak for din forklaring, ved ikke hvorfor den ikke ville.. Det jeg havde brug for... Var da jeg angiver $month som "apr" at få nummeret på den, for der efter igen at konvertere den til "apr" med følgende $month_engl_array[$month_engl_index[$month] +1 ] Sådan at jeg netop kunne tælle den op/ned.
@arne_v: Hvad skyldes anbefalingen.. Er det noget ressource mæssigt?? Men tak for dit indlæg. Kigger da lige på den funktion der.
Selvtak. Arnes forslag giver afgjort en enklere kode. En native funktion afvikler uden tvivl 'væsentligt' hurtigere - men det er næppe væsentligt ved få kald til den =)
Man lærer en masse ved at skrive funktioner selv, men når der findes indbyggede alternativer, bør man bruge dem i produktionskode
Hej.. Ja..Det er jo netop det der er min filosofi.. At skal man have tingene gjort må man gøre dem selv. Nej, nu kommer jeg nok ikke i produktions øjemed. Arbejder på hobbyplan. Så det går nok.
Og.. ja man lærer mere ved at skrive selv...Og så kan du vel også give mig ret i man på sigt slipper for "Deprecated".
Principielt er jeg enig, men finder det måske lidt bombastisk i den givne situation =)
1) Man har jo altid valget at sige nej til en opgave, hvis man mener, det vil kræve dårlig kode (= kode, som er usikker eller medfører unødig brug af ressourcer i målbare mængder).
2) Nu er der vel hverken tale om kode, som er usikker - eller som bruger unødige ressourcer i væsentlig (målelig) grad.
Til gengæld er der tale om ikke særlig vedligeholdelsesvenlig kode - hvilket altid er problematisk. På den anden side, må bør man nok også være lidt realistisk, og tidligere tråde tyder på, det faktisk er ret mange udbydere (naturligvis specielt de meget billige), som ikke understøtter locals.
Vi er nogle, som ikke behøver beskæftige os med den slags udbydere, men vi er nok et ret lille fåtal på et site som Eksperten. Virkeligheden for de fleste ser nok lidt anderledes ud *o)
Ja..Nu kan jeg se de "Point Mæssige "- Kloge, får sig en lille diskution.
@arne_v: Jeg vil selvfølgelig kigge på dine kode forslag. Men "For Satan" , Hvor vil jeg gerne selv lave koden. Og er Ny i faget. Så måske, når jeg bliver klogere..Så bruger jeg bare den kode andre har lavet.
@olebole: "2) Nu er der vel hverken tale om kode, som er usikker - eller som bruger unødige ressourcer i væsentlig (målelig) grad. " .... Og hvordan måler man så det??
Paa mange maader er jeg mere bekymret for den her slags end for daarlig performance.
Daarlig performance er ret synlig og medmindre problemet er startet allerede i arkitekturen saa kan det typisk rettes et enkelt sted eller nogle faa steder.
Hvis man skal igang med at i18n'e et presentation layer og det viser sig at business logic layer har en masse kode som ikke er i18n venlig, saa kan man have et stort problem. Det kan vaere meget svaert at finde alle problemerne ved test. Og der skal maaske rettes i rigtig meget kode.
Og det har ikke noget med indbygget funktionalitet vs egen kode at goere. Jeg tror ikke at forskellen i antal linier der skal skrives er stor.
Men hvis man konverterer navn->nummer for input og nummer->navn i output i presentation layer, saa er man langt bedre rustet til at haandtere internationalisering, forkortelser vs fulde navne, nummer vs navn.
Jamen, jeg betvivler ikke dig eller din kode. Kigger så afgjort på dine eksempler. Men du kender det jo nok godt, lysten til selv at ville lære noget :-)
NielsErik, det er ikke 'enten eller'. Du kan sagtens lege med den slags funktioner i et isoleret miljø for at lære. Det er bare ikke hensigtsmæssigt at bruge på et site, der skal virke. Funktionaliteten ligger ikke det logiske sted og koden bliver svær at vedligeholde.
i18n er en forkortelse, dannet efter bedste 'gangstermønster' - ligesom AK81. 'i' og 'n' er første og sidste bogstav i ordet 'internationalization' - og der er 18 tegn imellem dem =)
Nej, okay. Og jeg leger videre. Men forholder mig selvfølgelig til det i siger.
Tak for forklaringen, ole :-)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
