Jump to content
php.lv forumi

2easy

Reģistrētie lietotāji
  • Posts

    1,980
  • Joined

  • Last visited

Posts posted by 2easy

  1. globālis + kad vēl viens tāds scripta simbolu skaitītājs savā f-jā fzdSt() izmantos globāli $gnTm, tad stundu gļuku meklēsiet :>

    un protams ir cilvēku kategorija, kuri meklē un prot izdomāt problēmas tur, kur viņas nav

     

    1) šādi globālie mainīgie ir ļoti, ļoti maz. patiesībā arī tos pāris, kas ir, es varēju ielikt vienā globālā masīvā un tad vsp būtu tikai viens vienīgs globālais mainīgais

    2) svešu kodu vispirms paskatās un pārbauda. īpašas nepieciešamības gadījumā to var analizēt arī automātiski ar custom parseri

  2. starp citu, codez, pilnīgi pareizi, ka šajā gadījumā bija jālieto static mainīgais ;)

    un labi, ka neļauj man tik ļoti apcelt oop, bet nāc to aizstāvēt. būtu vēl citi no tevis mācījušies un arī tā darījuši

     

    tomēr lai kā tu censtos, "static" keywordiņš nozīmē pp pēc būtības (parasts procedurālais kods ir ielikts iekšā klasē, nedaudz pieregulējot sintaksi oop stilā). un tā kā funkcijas arī tu izsauc kā statiskās metodes, tad tu šobrīd nodarbojies ar pp (tiesa gan tas ārēji ir nomaskējies kā oop). līdz ar to pats parādīji, kā ar procedurālo pieeju var nooptimizēt oop kodu. tiešām malacis!!! ja jau oop piekritēji savā oop kodā sāk lietot pp paradigmu, kas var būt vēl labāks :D:D:D kr4 visu izdarīji manā vietā... :P

     

    anyway oop tikai cenšas radīt ilūziju, ka pārāk cieši apvieno datus un metodes. bet reāli tas ir pārāk strikts ierobežojums un oop ir pilns ar visādiem workaroundiem, kā piemēram extend un static, lai mīkstinātu šos ierobežojumus un palaistu tos vaļīgāk. kr4 strict oop fails by design... :D:D:D

     

    starpība par labu OOP pieaug līdz ar koda arhitektūrisko sarežģītību, kad sāk parādīties jēga lietot dažādus populāros paternus

    par šo mēs vēl pacīnīsimies pie kādas mazāk triviālas "pp vs oop" applikācijas. taču lai cik jautri te forumā nebūtu ar jums pļāpāt un strīdēties, šobrīd ir svarīgākas lietas ko darīt...

     

    taču attiecībā uz šo tēmu es noteikti varu teikt "i'll be back"

    terminator_1.jpg

  3. Rezumē - labāk pārliecināts PP programmētājs, nekā nepārliecināts OOP programmētājs :)

    jebkurā gadījumā, izvēlies savu nostāju un tad pārliecinoši bliez tik uz priekšu. un tu redzēsi, cik daudz cilvēku, kuriem nav pašiem sava viedokļa, tev noticēs tikai tāpēc, ka tu pats esi 200% pārliecināts par sevi :D:D:D

  4. par to ūberdizainu. piekrītu - neesmu nekāds megadizaineris, bet meibī kādam ir idejas, kur kaut kādus sīkumus varētu pielabot?

    paskatoties pricelistā, kādus apaļus ciparus viņi kāš par stundu darba, kas tur vairumā gadījumu ir vnk blabla papļāpāšana (tipa konsultācija), imho, viņiem nebūtu problēmu mazliet padalīties ar kādu labu dizaineri. savādāk kkas neliekas kopā. ja jau grib par sevi radīt labu iespaidu, tad jau bik tajā lapā vajag ieguldīt arī $$$

     

    vai tev vismaz samaksāja kko?

  5. tas ka Tu, codez, ar __autoload() pieminēšanu pacēli tēmu par applikācijas inicializēšanas automatizēšanu un optimizēšanu, tas ir labi. taču tās lietas ir jāsalīdzina uz konkrētas nelielas veselas testa web applikācijas (apmēram kā Aleksejs ieteica), nevis uz viena atsevišķa koda fragmenta

     

    applikācijas inicializēšanu un include var dažādi noautomatizēt. kaut vai taisīt automātisku pārbaudi ar function_exists() un include on demand. arī funkcijas var izsaukt automātiski: $f = 'blabla'; $f();

    biežāk gan failu ar vajadzīgajām funkcijām inkludo atkarībā no konteksta: lapas adreses un padotajiem get/post parametriem. un to dara applikācijas init laikā, lai pēc tam nevienai funkcijai vairs nav "jādomā", vai kko vēl vajag inkludot vai nē. turklāt tā kā ar pp sanāk daudz mazāks un kompaktāks kods, tad arī inklūdot vajag mazāk, un php parserim arī ir mazāk koda jāparsē :))

     

    anyway klašu failu autoinklūds ar __autoload() nav nekāda oop fīča, bet tikai vēl viens php include mehānisms

     

     

     

    savukārt filozofija un prakse attiecībā uz tīru oop: objekta dati (property:value) pēc būtības ir asociatīvs masīvs (key:value), un ja šim masīvam vēl varētu piekabināt funkcijas ("metodes"), tad sanāktu objekts :)) (un tante būtu tramvajs :D)

     

    // pp
    $a = array();
    objDoSomething($a, 123);
    
    // oop
    $o = new Obj()
    $o->doSomething(123);
    

    kodējot procedurāli, man kolīzijas nosaukumos nerodas, jo funkcijas saucu "oop stilā": funkcijas nosaukums sākas ar "objekta" nosaukumu. piemēram, visas timer funkcijas http://php.lv/f/topic/16057-str-replace-un-rand-savienosana-tada-ka-cikla/page__view__findpost__p__125165 sākas ar "tmr" (saīsinājums vārdam "timer")

     

    tāpēc vajadzība pēc atsevišķa namespace nav aktuāla

     

    ok, uzrakstīšu to pašu funkcionalitāti gan pp, gan oop

    // šī ir vispārīga/generic palīgfunkcija un var noderēt vēl kkur, tāpēc to nav vērts bāzt iekšā kādā konkrētā klasē
    function tmu() {list($nSecU, $iSec) = explode(' ', microtime()); return $iSec + $nSecU;}
    
    // pp
    $gnTm = 0;
    function tmrSet() {global $gnTm; $gnTm = tmu();}
    function tmrGet() {global $gnTm; return tmu() - $gnTm;}
    function tmrEcho($sInfo = '') {printf('%s%.4f<br />', $sInfo, tmrGet());}
    
    // oop
    class Tmr {
    private $nTm = 0;
    public function set() {$this->nTm = tmu();}
    public function get() {return tmu() - $this->nTm;}
    public function show($sInfo = '') {printf('%s%.4f<br />', $sInfo, $this->get());}
    }
    
    // testējam... skaitam līdz miljonam un uzņemam laiku ar katru taimeri: pp & oop (pats laiks te nav svarīgs, jo tam for ciklam nav nekāda sakara ar pp/oop)
    
    // pp
    tmrSet();
    for ($i = 0; $i < 1000000; $i++);
    tmrEcho();
    
    // oop
    $oTmr = new Tmr();
    $oTmr->set();
    for ($i = 0; $i < 1000000; $i++);
    $oTmr->show();
    

    pirmkārt, šis piemērs lieliski demonstrē to, ka oop var būt vairāk kolīziju funkciju nosaukumos nekā pp. ja pp variantā es varēju lietot vārdu "echo" iekš tmrEcho(), tad oop gadījumā man to vajadzēja pārsaukt uz "show", lai izvairītos no kolīzijas ar php iebūvēto funkciju (valodas konstrukciju). un ievērojiet, ka php ir tūkstošiem funkciju! tāpēc kodējot pp un liekot funkcijas nosaukuma prefiksā atbilstošo "objekta" nosaukumu, Jums par kolīzijām un namespace vsp nebūs jādomā. kr4 vajag domāt objektorientēti, piešķirt nosaukumus objektorientēti, organizēt kodu modulāri, taču NEkodēt oop sintaksē! :D

     

    bet tagad saldais ēdiens...

     

    funkcionalitātes koda apjoms baitos un rindiņu skaits:

    pp: 192 byte, 4 rindiņas

    oop: 217 byte (+13%), 6 rindiņas (+50%)

     

    testa koda apjoms baitos un rindiņu skaits:

    pp: 56 byte, 3 rindiņas

    oop: 84 byte (+50%), 4 rindiņas (+33%)

     

    lūdzu, oop pilnīgi nevajadzīgais bloated overheads visā savā skaistumā! :D:D:D

    tas ir tas, ko es saucu par "pp liek iekšā oop vienos vārtos"

     

    kr4 ar oop Jūs iegūstat daudz apjomīgāku kodu, turklāt pilnu ar dažādiem ierobežojumiem (private/protected), kurus jums vēl pašiem ir jākodē! :P un pēc tam vēlreiz pašiem sev jāatļauj (jāmanto ar extend :D). tas viss maigi izsakoties ir neērti un es šādu muļķīgu tukšgaitas darbošanos un beztolka pašmenedžēšanu neatbalstu. turklāt pati ideja pārāk iekapsulēt datus, sakausējot tos kopā ar metodēm, rada pārāk statisku/masīvu kodu. tas ir apmēram tāpat kā kodēt lapas layoutu ar tabulām tā vietā, ka to 2x ērtāk un elastīgāk var izdarīt ar css. "css layout vs table layout" ir vēl viena tamlīdzīga "cīņa". labi vismaz, ka tur tauta ir saprātīgāka un atzīst, ka css ir krutāks. bet oop fanus tā oop muša ir tik stipri sakodusi, ka pat rādot klaji kliedzošus piemērus, tik un tā tie ietiepīgi turpina uzskatīt, ka oop ir labāks :D:D:D bet nju katram savs...

     

    vsp man priekš sevis ir ļoti skaidra definīcija vārdam "labāks". tas ir mazāks/kompaktāks ātrāk uzrakstāms/menedžējams kods

    1) kompaktumu es panāku ar pp + labu nosaukumu saīsinājumu izvēli (common/standard abbreviations)

    2) savukārt menedžējamību es panāku, pārdomāti sadalot applikācijas funkcionalitāti pa dažādām funkcijām, funkcijas sagrupēju pa moduļiem un moduļus pa failiem. un šai koda organizēšanai/arhitektūrai nav nekāda sakara ar pp/oop (kā jau uzrakstīju #21 postā)

     

    tobish man ir gan skaidrs mērķis, gan skaidri līdzekļi (darba metodoloģija), gan arī skaidrs pamatojums, kāpēc un ar ko konkrētā izvēle ir labāka

     

    vispār es šo visu rakstu ne jau priekš sevis, bet priekš Jums. es zinu, ka ir daudz iesācēju, kas vēl tikai brīnās un mācās kodēt. un viņi grib zināt "kā ir labāk" un "kā ir pareizi/āk". un tad daži nedaudz pieredzējušāki iesācēji viņiem mēdz ieteikt oop, tipa jo "tā ir krutāk", "tā ir modernāk", "visi tā dara" un cenšas pamatot savu ieteikumu vēl ar citiem tamlīdzīgiem tikpat nenopietniem argumentiem. manuprāt, oop ir tikai un vienīgi treniņam. tā ir vnk filozofija par datu ciešu apvienošanu ar šo datu apstrādes funkcijām (kuras oop sauc par metodēm). tā dažkārt ir izdevīgi domāt, un iespējams, mācoties kodēt, tā pat ir labi domāt, taču praksē visu kodēt oop sintaksē sanāk tāds koda overheads, ka maz neliekās. tāpēc profesionāli programmētāji (protams, ne jau visi) uz oop skatās ar smīnu. anyway, domājiet paši, kas jums ir izdevīgi. pārbaudiet konkrētu kodu vienā un otrā veidā. domājiet ar savu galvu un izdariet secinājumus...

  6. tur jau tā lieta, ka pp un oop ir tikai koda pieraksta sintakses, un ar pp ekvivalentu funkcionalitāti var uzkodēt ar mazāku koda apjomu nekā ja to pašu pieraksta oop stilā. un fīču pievienošana kkad vēlāk nav atkarīga ne no viena no šiem stiliem (pp, oop vai whatever), bet gan no tā, kā ir organizēts kods, tobish no applikācijas arhitektūras, kurai tādi pp vai oop pilnīgi pofig (tās jau ir tehniskās nianses). visu darbu tāpat dara pp funkcijas vai oop metodes. vienkāršība/sarežģītība slēpjas tikai un vienīgi kā tiek izvietots/organizēts applikācijas kods/funkcionalitāte/funkcijas/datu plūsmas, savstarpējās dependencies un tamlīdzīgas lietas... un ar konkrētu paradigmu (pp vai oop) tam nav nekāda sakara. tas ir atkarīgs no programmētāja, kurš prot domāt visas sistēmas līmenī. kr4 tas vairāk ir sistēmanalīzes jautājums, nevis pp/oop

     

    tāpēc visa šī "pp vs oop" cīņa ir tikai farss :D:D:D (nopietni)

  7. ehh "kad es būšu admins, un tu būsi spameris... tad es ar tev tā izdarīšu" :D:D:D

     

     

    un paldies, ka esi izveidojis jau visus 3 manus topikus šajā forumā! ;)

  8. neee! stop! no! Aleksej, tu atkal izjauksi dabisko diskusijas attīstību. ir svarīgs konteksts, kādā mēs runājam par šīm lietām!!!

     

    tu pārāk centies visu sakārtot, bet šajā gadījumā tu izjauc diskusiju...

    tāpat visu pp vs oop tu nesavāksi vienā vietā. anyway no tā labākajā gadījumā iznāks tikai kkāds bezkonteksta biezenis, līdzīgi kā ir darba sadaļas offtopikā

     

    kr4 tu pārcenties. liec atpkaļ tos postus, kur tie bija!!! ;)

  9. domā šo? http://php.lv/f/topic/15535-interesanta-diskusija-par-mvc/page__view__findpost__p__125068

     

    sākās kā mvc diskusija, bet panesās par oop... :D:D:D

    ok, pārmāciet mani lūdzu, lūdzu!!! ;)

     

    plz, good examples studijā! kā ar oop var izdarīt ātrāk un vienkāršāk, rakstot mazāk kodu, nekā ar pp

     

     

    un tad jau pie reizes arī senāki mani izteikumi/izsmiekls par oop:

    http://php.lv/f/topic/15568-problemas-ar-extends-class/page__view__findpost__p__119939

    http://php.lv/f/topic/14864-klases-vs-funkcijas/page__view__findpost__p__114794

    http://php.lv/f/topic/15423-noderigas-funkcijas/page__view__findpost__p__118663

  10. weblapu kodēšana arī ir vnkārša jau pēc definīcijas, kamēr neierodas visādi oop fani un to nesarežģī :D

     

    ok, par to kopīgo un atšķirīgo funkcionalitāti...

    tur vsp ir 3 līmeņi/iedalījumi:

    1) standarta/lib funkcijas, kas ir 100% vienādas visos saitos

    2) funkcijas, kas pamatā ir vajadzīgas vienmēr, taču var nebūt pavisam standarta - dažos saitos tās ir nedaudz custom. tb ir mazliet jāpielāgo atkarībā no situācijas

    3) pilnīgi custom funkcijas, kas ir tikai un vienīgi konkrētajā saitā

     

    kā kodu organizēt (sadalīt pa moduļiem/failiem), tas jau tālāk ir gaumes jautājums

    anyway ir vēlams izvēlēties vienkāršāko risinājumu/algoritmu konkrētajam uzdevumam un censties nesarežģīt šīs vienkāršās lietas

     

    kiss

  11. tieši tā! :D:D:D

     

    kāpēc kko extendot, ja var uzreiz izsaukt vajadzīgo funkciju? ;)

    protams, atnāks rATRIJS un teiks, ka tā ir vieglāk menedžēt :D:D:D

     

    galvenais, nodali tās funkcijas, kas noderēs visos saitos, no tām funkcijām, kas noderēs tikai dažos saitos...

    thats it! so simple!~ :P

  12. pirmais if ir bezjēdzīgs ;)

    (tajā sākotnējā kodā)

     

    nomaini tač $_SESSION['blocked_time'] == time()

    uz $_SESSION['blocked_time'] >= time()

     

    vai tu tiešām domā, ka useris uzklikos tieši precīzi tajā sekundē, kad beidzas timeout???

     

     

    lol, turklāt date funkcijai ir jāpadod viss laiks, nevis starpība

    un vēl atlikušo laiku rēķina no lielākā atņemot mazāko, savādāk sanāk negatīva laika starpība!

     

    kr4 padomā, kad kodē...

  13. v3... tavai zināšanai čata tekstā nav iekšā nick :P

     

    jā, jā viss pareizi :D

    /me jau anyway ir tikai jārepleiso...

     

    tipa dabā tas izskatās tā. ierakstu:

    hi every1
    /me wants to play a game

    parādās:

    2easy> hi every1

    2easy wants to play a game>

     

    lai to uzkodētu, pietiek ar elementārām string darbībām... replace, concat

  14. tiešām vilks, tev ir interesanta loģika. ko tad īrijas un anglijas latviešiem arī ieteiksi defaulto valodu uz co.uk domēna likt kā angļu??? vai tomēr latviešu, kurā viņi runā?

     

    kr4 vieta nav svarīga. svarīgi ir cilvēki ;)

  15. kanādiešu valodu un beļģu valodu :D:D:D

     

    ok, kanādā droši vien, ka franču. hmm, tomēr labāk angļu

    bet par beļģiju hvz

     

    šajā gadījumā būtu vērts nočekot to user agent stringu, jo tur browsera valoda arī bieži uzrādās. taču lv gadījumā no tā varētu būt maz tolka, jo daudzi lieto anglisko versiju, lai gan tā tendence mainās. skatos, ka tgd daudziem ir lv interfeisi, taču man angliski labāk patīk

  16. es pagaidīju, lai tu pasaki, ka ir ok, lai tev pateiktu, ka nav ok :D:D:D

     

    jo ja tu izmantosi [\s\S]+ tas paņems visus code uzreiz (ja būs vairāki [ code] tagi)

    tāpēc lai tas būtu pieticīgāks un apstrādātu katru [ code]...[/code] atsevišķi, galā vajag pielikt ? kr4 šādi [\s\S]+?

     

    (dažās vietās ieliku atstarpes, lai teksta/piemēra code nejuktu kopā ar foruma posta formatēšanu)

    function bbc($s) {return preg_replace('/\[code]([\s\S]+?)\[\/code]/', '<div class="code-field">\\1</div>', $s);}
    
    $s = '[code]
    aaa
    bbb
    [/code ]
    
    [code]
    111
    222
    [/code ]';
    
    echo bbc($s);
    

    pamēģini pats paexperimentēt ar/bez ?

     

    un tik vnkāršas funkcijas raksta vienā rindiņā ;)

×
×
  • Create New...