[Ishra]

Ursprungligen postat av orreborre

Ja, du missuppfattade vad jag menade.
Jag menade att det känns som en dålig lösning att ha en switch-/if-sats i __get och __set.
Min lösning visar ett sätt att slippa det.

Din lösning är inte speciellt bra, det enda du har åstadkommit är 20 extra rader för att göra alla klassens egenskaper till public eftersom man med din kod kommer åt alla private variabler, och ifall man gör det så kan man väl likagärna sätta dom till public direkt?

Det är enligt mig självklart att man ska ha en switch/if i en get/set för att styra vad som händer, annars öppnar du ju upp klassen helt, och det kan ju inte vara tanken med get/set-metoderna.

[orreborre]

Ursprungligen postat av Ishra

Din lösning är inte speciellt bra, det enda du har åstadkommit är 20 extra rader för att göra alla klassens egenskaper till public eftersom man med din kod kommer åt alla private variabler, och ifall man gör det så kan man väl likagärna sätta dom till public direkt?

Det är enligt mig självklart att man ska ha en switch/if i en get/set för att styra vad som händer, annars öppnar du ju upp klassen helt, och det kan ju inte vara tanken med get/set-metoderna.

Fast det beror ju på vad målet med det hela är.
Som jag uppfattade det var målet att det inte ska gå att sättaegenskaper som objektet inte redan har. Alla som finns ska kunna sättas/hämtas.

[Ishra]

Ursprungligen postat av orreborre

Fast det beror ju på vad målet med det hela är.
Som jag uppfattade det var målet att det inte ska gå att sättaegenskaper som objektet inte redan har. Alla som finns ska kunna sättas/hämtas.

Ja, om det är syftet så gör ju din kod det den ska, tycker väl ändå att det är lite onödigt kanske, men den kritiken kan jag inte rikta mot din kod :=)

Hämta egenskaper som inte finns, det går väl aldrig (dom finns ju inte?), och ifall man sätter en egenskap som inte finns egentligen så gör väl inte det så mycket?
Håller med om att är "lite fult" såklart att kunna sätta egenskaper som inte finns egentligen, men klassen borde ju inte fråga efter den egenskapen ändå så borde inte påverka något, eller missar jag något?

[goose]

Ursprungligen postat av Ishra

Hämta egenskaper som inte finns, det går väl aldrig (dom finns ju inte?), och ifall man sätter en egenskap som inte finns egentligen så gör väl inte det så mycket?
Håller med om att är "lite fult" såklart att kunna sätta egenskaper som inte finns egentligen, men klassen borde ju inte fråga efter den egenskapen ändå så borde inte påverka något, eller missar jag något?

handlar väl om att det kan bli en bugg om man råkar stava en property fel av misstag. i ett kontrollerande språk får man ett felmeddelande direkt av kompilatorn, men i php så skapas en ny property med en felstavad property och man måste jaga buggen.

[Nerix]

Ursprungligen postat av goose

handlar väl om att det kan bli en bugg om man råkar stava en property fel av misstag. i ett kontrollerande språk får man ett felmeddelande direkt av kompilatorn, men i php så skapas en ny property med en felstavad property och man måste jaga buggen.

Ja, eller så ser man till och skriva ordentliga tester enligt BDD eller TDD.

[goose]

Jobbigt att skriva enhetstester för att täcka upp enkla slarvfel som kompilatorn snappar upp direkt tycker jag, därför jag håller mig till c# istället för php. Php har säkert en del styrkor och man ska nog inte försöka förändra dess natur genom att försöka få den att emulera ett mer strikt språk som Conny verkar vilja göra här.

[Nerix]

Ursprungligen postat av goose

Jobbigt att skriva enhetstester för att täcka upp enkla slarvfel som kompilatorn snappar upp direkt tycker jag, därför jag håller mig till c# istället för php. Php har säkert en del styrkor och man ska nog inte försöka förändra dess natur genom att försöka få den att emulera ett mer strikt språk som Conny verkar vilja göra här.

Tror inte riktigt jag hänger med. Hur skulle en kompilator se att du använt fel metodnamn? Jag menar, du skriver ett test som gör det möjligt att te.x skriva och läsa ett namn-attribut i en user-klass. Skulle du stava fel här så finns det ingen kompilator som säger till.

Kompilatorn fångar, av egen erfarenhet, upp fel som nybörjare ofta begår; syntax fel. Erfarna utvecklare missar sällan semikolon eller har ett mellanslag på fel ställe. Vi gör istället logiska fel, fel som inte en kompilator kan hitta.

[Conny Westh]

Ursprungligen postat av orreborre

Fast det beror ju på vad målet med det hela är.
Som jag uppfattade det var målet att det inte ska gå att sättaegenskaper som objektet inte redan har. Alla som finns ska kunna sättas/hämtas.

Det var ett av målet, just pga brister i php, men den huvudsakliga anledningen är att ha getters och setters som man kan sätta i andra objektorienterade språk.

Dvs exempelvis som i C# där man kan ha en metod för att validera värden när de sätts till en metod, 'är värdet utan för det giltigas gräns så kan man endera låta bli att lagra värdet i klassen eller göra en Throw Exception("Med ett vettigt felmeddelande")....

När man läser av ett värde så kan man exempelvis ha en automatisk konvertering, formatering, lagring av accessstatistik eller inläsning från någon extern källa. detta utan att programmeraren som använder egenskapen behöver bekymra sig över hur det går till.