perl vs PHP objekt orientert programmering

[sam2]

Kan noen nevne noen likheter/ulikheter når det gjelder objekt orientert programmering i perl vs PHP. Hva er den største forskjellen mellom disse språkene når det gjelder oo-koding? Hvordan håndteres for eksempel arv i PHP?

 

[Dette skulle vel vært slengt inn i PHP forum, men..]

Vet at det finnes ørten tusen funksjoner i PHP. Er noen av disse "default" for PHP kodere? Dvs finnes det et utvalg (en liste) av funksjoner, a'la perls ~150 funksjoner, som holder for å få "jobben" gjort?

 

Takk.

[Gjest Slettet-df17e]

fjernet

Endret 2. mars 2005 av Slettet-df17e

[Stian_]

php tror jeg er oo.

du kan lage objekter i php. bruke klasser og metoder.

 

 

perl er mer egnet seg som oo synes jeg, men det kommer helt an på hva du skal gjøre.

 

vet ikke helt hva du mener med "arv"

[kaffenils]

vet ikke helt hva du mener med "arv"

Arv betyr at en klasse kan arve metoder,egenskaper, hendelser og variabler fra en annen klasse. Det sparer deg bl.a. for masse ekstraarbeid.

 

Eks (fra vb.net 2nd edition):

 

Du lager en klasse som heter Person. Person har egenskaper som kjønn, fødselsdato, navn osv.

 

Deretter lager du en klasse som heter Ansatt. Denne definerer du at skal arve Person klassen, og tryll, tryll, så er hele Person interfacet tilgjengelig i Ansatt, og du slipper å definere navn, fødslsdato og kjønn igjen. Istedet bygger du videre på Ansatt og legger til ansattdato, ansattnummer, lønn osv.

[superlaban]

php tror jeg er oo.

du kan lage objekter i php. bruke klasser og metoder.

 

perl er mer egnet seg som oo synes jeg, men det kommer helt an på hva du skal gjøre.

 

vet ikke helt hva du mener med "arv"

 

Pussig at du sprer meninger om oo-egenskaper i språk og deretter spør hva som menes med "arv"

 

Tre ting er viktige å forstå for å forstå oo: arv, innkapsling og polymofisme

(noen som har en god oversettelse av det siste?)

 

 

 

Ellers vil jeg si meg uenig med alle de som sier at språk så-og-så ER oo, men et annet språk ikke er det. Det er upresist å formulere seg slik.

 

OO er mer en programmeringstankegang enn at man bruker mekanismer i språk.

Man kan skrive oo i C, og man kan skrive ikke-oo i Java.

 

Forskjellen mellom språkene er hvor godt innebygd syntax

støtter oo-tankegangen.

 

Og noen språk påtvinger oo-tankegang mer enn andre: F.eks. simula, og delvis java.

 

Mens perl, C++ og andre gir folk større valgfrihet og mer ansvar for egen stil.

De har oo-støtte, men valgfritt om den brukes. (det heter at "perl gives you enough rope to hang yourselv")

 

Php kjenner jeg ikke så godt.

[Oracel]

Det er vanlig å bruke begrepet "polymorfi". OOP er forøvrig en vits i både Perl og PHP, og det inkluderer PHP5 også.

[sam2]

Oracel wrote:

OOP er forøvrig en vits i både Perl

 

Ikke det at jeg nødvendigvis er uenig i denne påstanden, men kan du Oracel begrunne denne påstanden slik at vi kan se at du fakktisk *kan* noe om OOP i perl.

 

Finnes endel moduler på CPAN som trekker OO funksjonalitet i perl ganske langt.

[Oracel]

Tillat meg å utdype. Perl er ikke objektorientert. Å bruke begrepet objektorientert programmering (oop) når man snakker om Perl er bare tøys. Perl har støtte for bruk av klasser og objekter og denslags hvis man vil blande inn konsepter kjent fra objektorienterte språk, men å si at Perl er objektorientert er som å kalle en spade for en teskje. Det samme gjelder for PHP5 og flere andre "objektorienterte" språk.

[sam2]

Oracel wrote:

men å si at Perl er objektorientert er som å kalle en spade for en teskje

 

Nå må du komme med noe argumenter for dine utsagn. Begynner å bli lei av din verdensmester holdning og påstander som du slenger rundt deg uten noen form for dokumentasjon/kildehenvisning eller begrunnelse.

[Oracel]

sam2, du står selvsagt fritt til å motbevise meg i mine påstander om at Perl ikke er et objektorientert språk. Selv føler jeg det er unødvendig å komme med "dokumentasjon" da enhver programmerer med litt fartstid kan bekrefte mine påstander. Vi snakker her om prinsipper og filosofiske vinklinger.

 

Men tillat meg å illustrere med et veldig grafisk eksempel som sikkert vil gi deg bedre forståelse av hva jeg snakker om.

 

Sett at du har en bil. La oss se for oss at denne bilen er Perl. Denne bilen ble opprinnelig designet for å frakte en person eller gjenstander fra punkt A til punkt B. Dette er noe bilen klarer svært godt, og bilen oppnår gedigen popularitet.

 

Se så for deg at du installerer et gedigent stereoanlegg i denne bilen. La oss kalle stereoanlegget "objektorienterte programmeringskonsepter". Man forsøker så å få stereoanlegget til å høres best mulig ut, man vil nemlig virkelig ha krystallklar high-end lyd fra dette stereoanlegget.

 

Men dessverre, uansett hvor hardt man prøver, så vil man aldri bli fornøyd med dette stereoanlegget, for det er tross alt et stereoanlegg i en bil, og high-end lyd er som kjent så godt som umulig å få til i en bil. Men dette til sides, så vil man nå kunne frakte personer og gjenstander fra A til B mens man hører på musikk og koser seg.

 

Og her er rosinen i pølsa: selv om bilen har et high-end stereoanlegg, så er ikke bilen en formidler av high-end lyd. Bilen er fortsatt en bil, uansett hvor fint eller høyt musikken spiller. Eller i oversatte termer, "selv om perl har mulighet for bruk av objektorienterte programmeringskonsepter, så gjør ikke dette perl til et objektorientert språk".

 

Håper dette ga deg en bedre forståelse av poenget jeg prøver å formidle.

[sam2]

"Oracel",

når jeg ber deg begrunne din utsagn om at "OOP er forøvrig en vits i både Perl",

så forventer jeg at du holder deg til saken og viser et minstemål av seriøsitet og faktisk viser at du *kan* noe som helst om OO programmering i perl.

 

Dine kommentarer (så langt) bærer preg av overfladisk kjennskap og nedarvede holdinger til perl og uvitenhet om hvilke muligheter som språket har.

[Torbjørn]

Konkretiser gjerne hva du savner av OOP i perl.

[søppel10]

problemet med perl er ikke så mye det det mangler, men mer det som foregår og hvilke løsninger og valg man mer eller mindre automatisk tar når man programmerer i språket.

 

It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done.

 

..et annet problem er at alt for mange av verktøyene i det etterhvert enorme utvalget ikke er implementert skikkelig.. ting som er fundamentalt enkelt og har lite regler leder ofte til flere muligheter og større robusthet og fleksibilitet, enn et system med masse regler og tråder her og der som man kan dra i for å få den-og-den effekten..

 

it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead

 

http://groups-beta.google.com/group/comp.l...p&q=perl+naggum

 

 

Det er lett å se at mye av det som blir sagt stemmer med realiteten, ta f.eks.:

 

Vært en stund siden noe perl kode hadde vært trykket..utrolig hvor fort en blir rusten..

 

also, very much unlike any other language I have ever studied, perl has failed to stick to memory, a phenomenon that has actually puzzled me, but I guess there are some things that are so gross you just have to forget, or it'll destroy something with you.  perl is the first such thing I have known.

 

dette er én ting - men det nevnes flere ting også - og det han (Naggum) sier stemmer ofte utrolig bra .. legg merke til at han har brukt perl, og det han sier er ikke basert på utenforstående observasjoner, men relevant praksis og erfaring

 

jeg har ikke brukt Perl selv - men har brukt lignende språk som C/C++ og PHP (så i grunn gjelder denne ranten flere språk enn Perl); og det er lett å trekke paraleller når man merker at de kjappe (alt for ofte idiotiske) løsningene man tok tidlig gjør at kompleksiteten begynner å bobble opp til overflaten ettersom koden øker i omfang og størrelse (man må forsøke å anslå på forhånd hvor stort prosjektet er - og så velge rett verktøy til rett jobb) .. altså dette gjelder både i C/C++, PHP og Perl; erfaringen min fra de to første stemmer veldig godt med det jeg hører andre si om Perl - så jeg forstår og har erfart problemet under tilsvarende omstendigheter ..

 

edit: ..og jeg har funnet en bedre løsning kallt Lisp - og kan se tilbake på problemet som var

 

edit2:

http://nostdal.org/phpBB/viewtopic.php?p=84#84

Endret 14. mars 2005 av søppel10

[Torbjørn]

Igjen, kan ikke noen konkretisere problemene med perl?

 

hvis jeg søker etter "php sucks" får jeg opp hundretusener av sider. samme med java, c++ og whatver.

 

ingen i tråden som gjør annet enn å liste opp svært grunne generaliteter.

 

jeg sier ikke at dere tar feil, jeg sier "vis oss problemene".

[søppel10]

hva tenker du på? er du ute etter et (kode)eksempel på manglende funksjonalitet eller noe slikt?

 

det vil ikke vise det jeg skal frem til uansett - for det er ikke der problemet sitter, mener jeg ..

 

edit:

man kan muligens sammenligne problemet med et tilsvarende et; Windows API'et ..

 

Windows API'et er fundamentalt og designmessig ødelagt ( http://www.theregister.co.uk/2002/08/07/wi...d_irredeemably/ ) .. det er som en sil man stadig må lappe og teipe utenpå (gjerne selv, i egne applikasjoner), og man kan ikke bytte ut sila med en bøtte .. for bakoverkompatibiltet er hele nøkkelen til MS's økonomiske suksé ..

 

http://bugs.perl.org/ 5 år gammle bugs er fortsatt i åpen status .. jeg har ingen forutsetning for å komme med noen konkrete utsagn basert på dette, men det kan virke som om det er ting som er "umulig å fikse" - omtrent på samme vis som med win. api'et

Endret 14. mars 2005 av søppel10

[Torbjørn]

hvorfor ikke det? hvordan kan det være problemer/ankepunkter mot perl som ikke er relevant for perlkode og som kan illustreres ved kodeeksempler eller reelle manglende features?

 

Alt jeg ser i denne tråden er synsing og referanser til andre sin synsing.

 

EDIT: Hvorfor lansere en perl5-bugs sammenligning med brekt windows API og deretter si at du ikke har noe grunnlag for å sammenligne disse to fenomenene?

 

Dette henger ikke på greip. Får jeg be om at du modererer dine påstander eller kommer med noe konkret.

Endret 14. mars 2005 av Torbjørn

[søppel10]

vel .. se på det slik da, hva er det egentlig som er så ødelagt med goto-bruken i gammle Basic-programmer?

 

bare se på koden - altså perlkoden .. den taler for seg; det er(blir) kjappe hacks -- og det passer ikke til større prosjekter og sammenhenger (akkurat som med goto) .. må man komme med eksempler?

 

edit2:

Hvorfor lansere en perl5-bugs sammenligning med brekt windows API og deretter si at du ikke har noe grunnlag for å sammenligne disse to fenomenene?

..fordi jeg kjenner mer til win.-apiet enn jeg gjør til perl ... men som sagt så minner f.eks. de problemene Naggum snakker om i sammenheng med Perl om det jeg /har/ mulighet til å si noe konkret om; altså C (win.-apiet, men også språket generellt sett)..

 

edit3:

..om du mener noe annet; "perl passer til større prosjekter" -- kan ikke jeg si noe på det ..

Endret 14. mars 2005 av søppel10

[Torbjørn]

Fortsatt bare synsing..

 

"bare se på koden - altså perlkoden .. den taler for seg; det er kjappe hacks"

 

hva mener du med dette? det finnes masse kode som ikke er kjappe hacks. det er et problem med programmereren, ikke programmeringsspråket.

 

Goto er spaghettikode. Det finnes det gode begrunnelser for. Jeg ønsker likevel at du trekker fram problemer med perl. Gjerne på nivå med goto i basic.

 

jeg tittet litt rundt, her er en bugliste fra kernel.org:

http://bugzilla.kernel.org/reports.cgi?pro...banner=1&quip=0

 

Av totalt 1300 bugs i kernel 2.6, er det 1100 som ikke gjøres noe med. Det høres jo helt horribelt ut.

 

Se på PHP:

http://bugs.php.net/search.php?cmd=display...&phpver=&by=Any

 

her er det flust av røde og mørkerøde bugs, opptil flere år gamle, som det ikke er gjort noe med. Totalt over 400 elemlenter i lista. Er dette bra eller dårlig?

 

Jeg vet ikke. Jeg kan ikke vurdere dette antallet og alvosligheten i dem. Jeg vil derfor heller ikke trekke fram intetsigende tall/statistikk i en slik debatt.

[søppel10]

jeg er ikke sikker på om det faktisk er hos programmereren problemet altid sitter.

 

ta f.eks. c++ (jeg er nødt til å snakke om ting jeg har greie på) .. der blir man tvunget (av språket!) til å ta tidlige avgjørelser -- dette skaper himmla med problemer siden (goto-analogi)

 

jeg tror det er noe ála det samme, men man blir kanskje ikke tvunget til det i perl (edit2: og i grunn php) - man blir bare "belønnet" (edit: altså når man velger lettvinnte løsninger, goto er en (tilsynelatende der og da) lettvinnt løsning)

 

edit3:

grunnen til at jeg føler at jeg i det hele tatt kan uttale meg - er at det Naggum sier om perl stemmer veldig godt i sammenheng med lignende språk som php; spesiellt dette med "belønnelse av (tilsynelatende) lettvinnte løsninger" .. spesiellt når ting begynner å øke i størrelse og kompleksitet, merker man at dette med "tilsynelatende" kommer frem .. jeg har altså opplevd nesten akkurat det samme med php - som Naggum snakker om i sammenheng med perl (det er umulig å forstå andres (eller sine egne, siden) php-hack...akkurat som det er umulig å forstå spaghetti-kode)

Endret 14. mars 2005 av søppel10

[Torbjørn]

å kode uforståelig er et problem.

å ta feil avgjørelser er et problem.

 

at perl ikke er snilleste barnet i klassen er jeg enig i.

 

perl er ikke typet. dette var et bevisst valg med de konsekvenser det medfører.

 

jeg har selv bakgrunn i python, perl og php hva skriptespråk angår, og java på andre siden.

 

jeg har ingen problemer selv, føler jeg, med å bruke perl i hvilket prosjekt det skulle være, hva oop eller kodekompleksitet eller flerutvikler-organisering angår.

 

at andre synes perl kan være vanskelig og at for dårlig kompetanse ikke straffes like tidlig som i andre språk vil jeg heller ikke nekte for.

 

men den debatten dreier seg mer over for hvor man skal legge lista hva holde-programmereren-i-lanken angår.

 

For å dreie tilbake til perl oop - jeg har fortsatt til gode å se problemer i perl sin oop implementasjon presentert av deg