ProgrammeringsBaren! Småprat, om det du elsker!

[worseisworser]

Stevey ( Stevey's Drunken Blog Rants ) ranter igjen; https://raw.github.com/gist/933cc4f7df97d553ed89/24386c6a79bb4b31fb818b70b34c5eab7f12e1ff/gistfile1.txt .. alltid noe interessant IMHO.

 

Their code base is a disaster, with no engineering standards whatsoever except what individual teams choose to put in place.

Endret 12. oktober 2011 av worseisworser

[torbjørn marø]

... Det har også skjedd så mye bra på JavaScript-fronten de siste årene, ...

Det er vel ikke JavaScript det har skjedd så mye med, snarere biblioteker etc?

Språket har ikke utviklet seg nei, men bruken av det, inkludert biblioteker, bedre commonality mellom browsere, utnyttelse på andre områder, mobilplattformer med JavaScript-støtte, hurtigere VM, kompilering til maskinkode, andre språk og rammeverk som bruker JavaScript i bunn m.m.

[GeirGrusom]

... Det har også skjedd så mye bra på JavaScript-fronten de siste årene, ...

Det er vel ikke JavaScript det har skjedd så mye med, snarere biblioteker etc?

Språket har ikke utviklet seg nei, men bruken av det, inkludert biblioteker, bedre commonality mellom browsere, utnyttelse på andre områder, mobilplattformer med JavaScript-støtte, hurtigere VM, kompilering til maskinkode, andre språk og rammeverk som bruker JavaScript i bunn m.m.

Kanskje. Men jeg har lest igjennom utkastet til Dart, og jeg synes det ser generelt ut som en god idé. En ting jeg liker spesielt godt er at det både er støtte for dynamisk og statisk typesystem. Dog det er tenkt at det statiske typesystemet er ment for å gjøre feilsjekking, og skal ikke hindre eksekvering av script.

[dabear]

Språket js har utvikla seg ganske mye og har fått Array/string generics, generatorer,iteratorer, bedre scoping, generator expressions, og vi har fått strict mode .

Men dessverre kan en nok ikke ta i bruk de fleste av disse features fordi eldre nettlesere ikke støtter det. Laveste felles multiplum er noe dritt.

 

 

Ellers er ikke javascript så galt. Det er ikke javascript som må fikses, men det er inkonsistensen i implementasjonene av DOM som bør fikses. Syns John resig sa det bra:

Why is Google putting time and effort into changing JavaScript when the DOM is what needs fixing?

http://twitter.com/#!/jeresig

[asicman]

R.I.P. Dennis Ritchie

 

Google Plus

[Gjest Slettet+9871234]

Det er den andre store som dør på en uke.

[worseisworser]

$(..).is(:checked) ===> undefined ... men ... $(..)is.(":checked") ===> true/false

 

GRRR.

 

 

(..savner type warnings alá SBCL. Ja, en kan ha type warnings i dynamiske språk, også.)

 

edit:

..men :blah gir vel ikke noen mening i JS i utgangspunktet; brainfart sånn sett. Det gir mening (kan brukes som verdi omtrent på samme vis som "literal strings") i andre språk.

Endret 13. oktober 2011 av worseisworser

[torbjørn marø]

$(..).is(:checked) ===> undefined ... men ... $(..)is.(":checked") ===> true/false

 

(..savner type warnings alá SBCL. Ja, en kan ha type warnings i dynamiske språk, også.)

Med syntax coloring fanger du vel opp feil som det der?!

 

Måtte forresten lese hele posten din før jeg så problemet. Hang meg opp i en annen feil du har gjort når du i forargelsen skrev koden din her. For dette gir jo ikke mening:

$(..)is.(":checked")

[worseisworser]

Jepp, manglet en . når jeg skrev av (fremfor å copy/paste) dette.

 

edit: Syntax coloring ville fortalt meg at "dette ikke er en streng"; that's it. Den ville ikke fortalt meg at den forventet en streng.

Endret 13. oktober 2011 av worseisworser

[Blåbær]

Stevey ( Stevey's Drunken Blog Rants ) ranter igjen; https://raw.github.com/gist/933cc4f7df97d553ed89/24386c6a79bb4b31fb818b70b34c5eab7f12e1ff/gistfile1.txt .. alltid noe interessant IMHO.

 

Their code base is a disaster, with no engineering standards whatsoever except what individual teams choose to put in place.

 

Her er svaret på hvorfor Amazonsjefen tok de valgene. Dessverre er vedkommende som skrev artikkelen eposten død, han tok sitt eget liv denne uken.

 

http://mail.gnome.org/archives/banshee-list/2008-March/msg00050.html

Endret 14. oktober 2011 av Blåbær

[torbjørn marø]

edit: Syntax coloring ville fortalt meg at "dette ikke er en streng"; that's it. Den ville ikke fortalt meg at den forventet en streng.

Jeg tror syntax coloring hadde fortalt meg at noe skurret. Fargene gir deg en følelse for hvordan riktig kode ser ut, og avvik "føles ikke bra". Men det er slevsagt langt fra idiotsikkert

[Matsemann]

Kjapt spørsmål ang. initialisering av variabler. Hva blir praktisk forskjell på disse to:

public class TouchProcess {
public Vector vector1;
public Vector vector2;

public TouchProcess() {
	vector1 = new Vector();
	vector2 = new Vector();
	/* annet*/
}
}

public class TouchProcess {
public Vector vector1 = new Vector();
public Vector vector2 = new Vector();

public TouchProcess() {
	/*annet*/
}
}

(java)

 

Altså, ting som bare må initialiseres ved opprettelse av objekt, men helt uavhengig av andre verdier.

evt. om de er ekvivalente, hva er da best practice?

Endret 15. oktober 2011 av Matsemann

[Johan]

Det er best å opprette nye objekter i konstruktøren, siden du kan ha flere konstruktører i en klasse. Dette dekobler en hel del. Hvis du oppretter objektene i selve felt-deklarasjonen kan du ikke enkelt redefinere hvordan disse skulle opprettes ved behov.

 

Tenk deg at du har en klasse

 

public class Foobar {
 Collection zot;
 Collection quux;

 public Foobar() {
   zot = new Vector();
   quux = new Vector();
 }
}

 

Siden oppdager du at vector ikke var ideelt for alle brukene av Foobar, i et par kritiske brukstilfeller er det mye bedre å en lenka liste. Da kan vi jo bare lage en ny konstruktør slik at brukeren av klassen kan initialisere zot og quux med de datastrukturene som måtte passe best. I det originale tilfelle (uten konstruktør) hadde mye mer kode måtte endres. Summa summarum gir konstruktører deg en mye bedre styring på hvordan objektet ditt initialiseres. Det er et spesielt poeng at konstruktører kan overlastes, akkurat som vanlige metoder. Derfor er det dumt å putte initialiseringskode utenfor dem.

 

 public Foobar(Collection zot, Collection quux) {
   this.zot = zot;
   this.quux = quux;
 }

[tomsi42]

Det er best å opprette nye objekter i konstruktøren, siden du kan ha flere konstruktører i en klasse. Dette dekobler en hel del. Hvis du oppretter objektene i selve felt-deklarasjonen kan du ikke enkelt redefinere hvordan disse skulle opprettes ved behov.

Godt råd - dette er nok noe som mange ikke tenker på.

[torbjørn marø]

... I det originale tilfelle (uten konstruktør) hadde mye mer kode måtte endres. Summa summarum gir konstruktører deg en mye bedre styring på hvordan objektet ditt initialiseres. Det er et spesielt poeng at konstruktører kan overlastes, akkurat som vanlige metoder. Derfor er det dumt å putte initialiseringskode utenfor dem.

Jeg er ikke helt sikker på om jeg kjøper denne argumentasjonen - må tenke litt på det.

 

Som regel putter jeg initialisering i konstruktøren hvis jeg har en. Har jeg ingen grunn til å opprette den default konstruktør så initialiserer jeg felt inline. Å ha flere konstruktører (så sant de gjør noe annet enn å kalle en hovedkonstruktør) ser jeg dessuten på som en uting.

 

Med små klasser som kun har ett ansvar (SRP) er det lett å holde oversikt over hva som skjer, antall felt er alltid lavt, og mengden kode som må redigeres ved en eventuell endring som du snakker om er uansett liten.

 

Men som antydet, jeg er åpen for at det er en "best practice" her som jeg ikke har tenkt på.

[Johan]

Vel, det går jo an å misbruke teknikken også, akkurat som alle andre tommelfinger-regler. Akkurat hvordan konstruktørene settes sammen blir litt opp til stilen (skal man bruke statiske hjelpere?) og hva klassen egentlig er ment å representere. Se for eksempel på collections i java, der er det flittig bruk av overlastede konstruktører. Men hvis man har to konstruktører som gjør totalt urelaterte ting er det nok et tegn på at noe rart er fatt.

 

Jeg lager alltid konstruktører, med mindre klassen kun "egentlig" er en struct, det vil si bare en gruppering av datastrukturer.

 

Et generelt prinsipp jeg liker å følge er at alle objekter _alltid_ skal være i en gyldig tilstand etter at new() har blitt kalt.

[thelomen]

En stor fordel ved initialisering i konstruktøren er at det gir mulighet til å injisere mocka (fake) objekter under enhetstesting. Du mister ellers denne kontrollen over klassen.

[torbjørn marø]

En stor fordel ved initialisering i konstruktøren er at det gir mulighet til å injisere mocka (fake) objekter under enhetstesting. Du mister ellers denne kontrollen over klassen.

Ja, enig, i de tilfellene hvor man ønsker å sende inn avhengighetene så bruker man en konstruktør (property injection er et alternativ). Men det som ble sammenlignet her var tilfelle med parameterløs konstruktør vs. inline initialisering av felt. De løsningene er i utgangspunktet like, men det argumenteres her for at med konstruktør har man gjort bedre klar for potensielle endringer.

[thelomen]

Jeg argumenterer for det samme, og bruker testing som eksempel :-)

 

Har gjerne fortsatt en parameterfri, default konstruktør som initialiserer objektene det gjelder og sender de videre til en konstruktør med parameter.

 

Forøvrig merker jeg at å delta i slike diskusjoner på norsk, via mobil, fort føles klumsete :-)

[torbjørn marø]

Har gjerne fortsatt en parameterfri, default konstruktør som initialiserer objektene det gjelder og sender de videre til en konstruktør med parameter.

Jepp, har en del av dem. Stammer fra før vi tok i bruk dependency injection containere.