Volgorde van variabele initialiseren aan object/class

[Hatsieflatsie]

PHP probeert zijn achterstand op Java in te lopen, en al enige tijd is OOP geïntroduceerd in PHP. Ik erger mij dood aan de volgorde van variabele - nieuwe object of klasse, dat ook dezelfde volgorde in C# of Java aanhoudt:

code:

$variabele = new Object();

Dan is het "die variabele is een nieuwe object". Het leest niet fijn, en klinkt nergens naar. . Ik struikel dan ook regelmatig over de volgorde. Ik zou liever willen hebben als : dat nieuwe object is voortaan een variabele. Dus zo:

code:

new Object () = $variabele;

Mijn vragen zijn:
1. Waarom is er gekozen voor de volgorde variabele -> object/klasse?
2. Bestaan er programmeertalen waar ze in de meer logische volgorde nieuwe object/klasse > toegewezen zijn aan variabele? Daar zou ik eens mee willen werken, lijkt mij stukken fijner zo.

[NMe]

Schrijf je ook 1 = $variabele;?

Ik ken geen enkele taal die de volgorde andersom heeft. Nogal wiedes ook. Op zijn Nederlands lees je de assignment operator als lvalue wordt rvalue. Oftewel: $variabele wordt een nieuw object. Ik zie niet hoe dat onlogisch zou kúnnen zijn.

[ Voor 76% gewijzigd door NMe op 24-10-2013 18:54 ]

[Verwijderd]

NMe schreef op donderdag 24 oktober 2013 @ 18:52:
Ik ken geen enkele taal die de volgorde andersom heeft.

Assembly met GAS syntax.

[Aloys]

In veel oudere pseudo code wordt er voor een toekenning een pijltje gebruikt:

code:

sum <- x+y

Ik vind het maar raar als de variabele achteraan staat, maar dat zal ook wel voor een groot deel komen omdat je dat gewend bent.

[NMe]

Verwijderd schreef op donderdag 24 oktober 2013 @ 18:56:
[...]

Assembly met GAS syntax.

Daar heb je geen operator en zeg je mov waarde, register, oftewel verplaats deze waarde naar dit register. Wat dáár weer wel een logische volgorde is.

Daarbij is het redelijk krom om een 3GL+ taal te vergelijken met assembly.

[ Voor 11% gewijzigd door NMe op 24-10-2013 19:00 ]

[Verwijderd]

PHP:

$order = new Order();
$order->date = time();
$order->amount = $cart->getTotalAmount();
$order->items = $cart->getItems();
$order->store($model);

PHP:

new Order() = $order;
time() = $order->date;
$cart->getTotalAmount() = $order->amount;
$cart->getItems() = $order->items;
$order->store($model);

Moet ik nog meer zeggen?

[.oisyn]

Hatsieflatsie schreef op donderdag 24 oktober 2013 @ 18:51:
dat nieuwe object is voortaan een variabele.

Ik snap op zich wel waar dat vandaan komt, maar dat betekent dat je eigenlijk niet helemaal snapt wat objecten en variabelen nou precies zijn. Je kunt helemaal niet zeggen dat het nieuwe object een variabele is (tenzij je het hebt over metaprogramming waarbij je een object hebt dat een specifieke variabele representeert). De variabele verwijst naar het object. Meerdere variabelen kunnen naar hetzelfde object wijzen, en het object kan ook bestaan zonder dat er een variabele is. En "dat nieuwe object wordt naar verwezen door een variabele" klinkt helemaal niet.

[ Voor 7% gewijzigd door .oisyn op 24-10-2013 19:36 ]

[Verwijderd]

NMe schreef op donderdag 24 oktober 2013 @ 18:59:
[...]

Daar heb je geen operator en zeg je mov waarde, register, oftewel verplaats deze waarde naar dit register. Wat dáár weer wel een logische volgorde is.

Alhoewel dat in natuurlijke taal inderdaad logischer klinkt, is de Destination, source notatie praktischer als je naar instructies met meerdere parameters gaat. Als je dan een lijst assembly hebt is het makkelijker te zoeken waar een bepaald register assigned wordt. Daarom gebruikte ik vroeger met assembly 16 spatie tabs, er zijn geen instructies die zo lang zijn, dus de meest linker argumenten zijn altijd aligned.

Datzelfde argument gaat ook in mindere mate op voor de wat hogere programmeertalen. Door destination = source te gebruiken staat destination altijd vooraan in de regel.

code:

a = 1;
b = 2;
c = 3;
a = a + b;
c = a + b + c;

Je vaag je na dit stuk code af wat de waarde van b is. Je hoeft nu alleen maar de meest linker karakters te skimmen.

code:

1 -> a;
2 -> b;
3 -> c;
a + b -> a;
a + b + c -> c;

Nu gaat die theorie niet meer op. Met multi-line expressions wordt het nog erger.


Overigens zijn er ook basic dialecten die -> gebruiken als assignment. Dat vind ik om bovengenoemde redenen suboptimaal.

[Hydra]

.oisyn schreef op donderdag 24 oktober 2013 @ 19:34:
[...]

Ik snap op zich wel waar dat vandaan komt, maar dat betekent dat je eigenlijk niet helemaal snapt wat objecten en variabelen nou precies zijn.

QFT. Makes no sense.

[BasieP]

wel grappig dit topic, ik heb mij hetzelfde ook eens afgevraagd.

Wat wel typish is, is dat wanneer je vergelijkingen maakt, het wel andersom staat.

if (var == 3) { ... }
of
if (persoon == 'BasieP')

wanneer je zegt:
if (3 == var)
of
if ('BasieP' == persoon)
wordt er vaak gesproken over Yoda conditions


ow en hier is nog zo'n mooie site: http://www.dodgycoder.net...ns-pokemon-exception.html

[ Voor 14% gewijzigd door BasieP op 25-10-2013 00:40 ]

[Acid_Burn]

BasieP schreef op vrijdag 25 oktober 2013 @ 00:33:
wel grappig dit topic, ik heb mij hetzelfde ook eens afgevraagd.

Wat wel typish is, is dat wanneer je vergelijkingen maakt, het wel andersom staat.

if (var == 3) { ... }
of
if (persoon == 'BasieP')

Hoezo is dat andersom?
Bij de declaratie zeg je:
variabele = waarde
Bij de vergelijking
variabele == waarde

In beide gevallen staat de variabele aan de linkerkant van de operator.

@hats: Als je met wiskunde bezig bent staat de variabele toch ook aan de linkerkant en de waarde aan de rechterkant? Dat de waarde een instance van een object is of slechts een integer doet er dan niet toe.

[ Voor 17% gewijzigd door Acid_Burn op 25-10-2013 01:06 ]

[NMe]

BasieP schreef op vrijdag 25 oktober 2013 @ 00:33:
wanneer je zegt:
if (3 == var)
of
if ('BasieP' == persoon)
wordt er vaak gesproken over Yoda conditions

Behalve in Java, want daar word je met if (persoon.equals("BasieP")) al snel met een nullpointer-exception om de oren gegooid terwijl je daar met if ("BasieP".equals(persoon)) geen last van hebt.

Verder: met Acid_Burn: er staat bij jou geen vergelijking andersom? Vrijwel altijd staat de variabele vooraan en de constante achter, al is dat natuurlijk alleen bij assignments echt nódig.

[sig69]

BasieP schreef op vrijdag 25 oktober 2013 @ 00:33:

Wat wel typish is, is dat wanneer je vergelijkingen maakt, het wel andersom staat.

if (var == 3) { ... }
of
if (persoon == 'BasieP')

Bij jou misschien, maar bij mij niet hoor. Beetje raar om zomaar te stellen dat het bij vergelijkingen andersom staat. Is gewoon persoonlijke voorkeur.

[ Voor 4% gewijzigd door sig69 op 25-10-2013 01:38 ]

[Verwijderd]

NMe schreef op vrijdag 25 oktober 2013 @ 01:24:]

Behalve in Java, want daar word je met if (persoon.equals("BasieP")) al snel met een nullpointer-exception om de oren gegooid terwijl je daar met if ("BasieP".equals(persoon)) geen last van hebt.

Bijkomend voordeel van die Yoda conditions is dat als je een = te weinig tikt, je direct een waarschuwing krijgt van de compiler.

[Zyppora]

Verwijderd schreef op vrijdag 25 oktober 2013 @ 07:00:
[...]

Bijkomend voordeel van die Yoda conditions is dat als je een = te weinig tikt, je direct een waarschuwing krijgt van de compiler.

Dit dus. Ik schrijf in de meeste talen een vergelijking tussen een variabelen en een waarde als:

code:

if (value == variable) {

// Dus:
if (3 == $iTotal) {

// Of:
if ("Zyppora" == $strName) {

Omdat mocht je dan een = teken vergeten, dat je code dan error'd in plaats van vrolijk je variabele een andere waarde te geven en je conditional block uitvoeren terwijl dat misschien helemaal niet de bedoeling was.

Ik weet zeker dat ik niet de enige ben bij wie een vergeten = teken in het verleden wel eens voor infinite loops heeft gezorgd.

Bij assignment wordt uiteraard wel gewoon var = value aangehouden

[ Voor 7% gewijzigd door Zyppora op 25-10-2013 08:32 ]

[Sebazzz]

C# geeft een compile-time warning als je een assignment doet in een if clause.

[Janoz]

De werkelijke fout is eigenlijk al veel eerder gemaakt. De = in veel programmeertalen is een heel andere = als in de wiskunde. De wiskunde = is veel meer te vergelijken met wat in veel programmeertalen met '==' (of soms zelfs '===') wordt aangeduid.

In de wiskunde is echter wel een teken voor 'wordt', dit is ':='. Dit zie je bijvoorbeeld in Pascal, Delphi en Algol-60. Daarom kunnen ze in die talen wel gewoon de = gebruiken om twee waarden te vergelijken.

Lees je 'wordt' ipv 'is' dan is de toekenning gelijk een stuk duidelijker.

[.oisyn]

Maar desalniettemin mooi troll topic.

[H!GHGuY]

Verwijderd schreef op vrijdag 25 oktober 2013 @ 07:00:
[...]

Bijkomend voordeel van die Yoda conditions is dat als je een = te weinig tikt, je direct een waarschuwing krijgt van de compiler.

Een compiler die zichzelf respecteert geeft dan een warning.
Een developer die zichzelf respecteert behandelt warnings als errors.

Eindresultaat: Yoda conditions hebben op de dag van vandaag weinig nut meer. (Misschien met uitzondering van die Java Equals() en nog wat exotische use-cases.

Aan de TS kan ik maar 1 ding zeggen:
Kijk nog 1 keer naar programmeer- en scripttalen, draai je om en loop weg. Kijk vooral nooit terug.

(en verspil ook mensen hun tijd niet met dit soort troll-topics).

[Infinitive]

Bash:

echo "new object" | cat > variable

[Hydra]

H!GHGuY schreef op vrijdag 25 oktober 2013 @ 12:54:

(en verspil ook mensen hun tijd niet met dit soort troll-topics).

Jouw tijd is te waardevol voor dit soort topic maar je reageert wel?

[NMe]

H!GHGuY schreef op vrijdag 25 oktober 2013 @ 12:54:
[...]

Een compiler die zichzelf respecteert geeft dan een warning.
Een developer die zichzelf respecteert behandelt warnings als errors.

Scripttalen doen dat vrijwel allemaal niet. Editors vaak wel, maar tegelijkertijd zijn constructies als deze redelijk gangbaar in PHP:

PHP:

while ($row = mysql_fetch_object($result)) { ... }

...en die komt ook in de if-vorm nog wel eens voor. Ik heb zelf de warnings voor assignments in conditions om die reden uitgezet zodat ik niet steeds met geel gemarkeerde regeltjes krijg voor dingen die wél zo moeten.

[Blubber]

NMe schreef op vrijdag 25 oktober 2013 @ 13:44:
[...]

Scripttalen doen dat vrijwel allemaal niet. Editors vaak wel, maar tegelijkertijd zijn constructies als deze redelijk gangbaar in PHP:

PHP:

while ($row = mysql_fetch_object($result)) { ... }

...en die komt ook in de if-vorm nog wel eens voor. Ik heb zelf de warnings voor assignments in conditions om die reden uitgezet zodat ik niet steeds met geel gemarkeerde regeltjes krijg voor dingen die wél zo moeten.

Hij had het over compilers die zichzelf respecteren, dus niet PHP .

[.oisyn]

H!GHGuY schreef op vrijdag 25 oktober 2013 @ 12:54:
[...]


Een compiler die zichzelf respecteert geeft dan een warning.

Nonsens, er zijn zat mensen die in de if nog een assignment willen doen soms

C++:

SomeObject * o;
// ...
if (o = FindObject("foo"))
    o->DoSomething();

[NMe]

Precies, min of meer dezelfde constructie als in PHP dus, al had ik geen idee dat het in échte talen zoals C++ ook met enige regelmaat gebeurt.

[H!GHGuY]

.oisyn schreef op vrijdag 25 oktober 2013 @ 15:04:
[...]

Nonsens, er zijn zat mensen die in de if nog een assignment willen doen soms

C++:

SomeObject * o;
// ...
if (o = FindObject("foo"))
    o->DoSomething();

En dan kan een compiler (zoals gcc het doet) het volgende toelaten:

C++:

if ( (o = FindObject("foo")) )
  o->DoSomething();

De extra haakjes zorgen voor het suppressen van de warning _en_ zorgen voor een extra visuele indicatie aan collega's dat de assignment echt wel bedoeld was.

[ Voor 15% gewijzigd door H!GHGuY op 25-10-2013 18:42 ]

[Hatsieflatsie]

Thnx voor jullie reacties. Het is mij nu een stuk duidelijker.

En voor degenen die denken dat ik zit te trollen.. doe niet zo wantrouwig. Ik vroeg het mij gewoon af, mag dat ja?

[Verwijderd]

Begin je topic dan eens met een minder grote mond. Je "ergert je dood", het "leest niet fijn" en "klinkt nergens naar". Ik vind het niet zo gek dat mensen dan de conclusie trekken dat je heel weinig ervaring hebt, aangezien mensen met ervaring geen enkele moeite hebben met wat jij onlogisch noemt. En dan is het niet zo vreemd dat je met zo'n uitgesproken mening overkomt als een enorme troll.

Laat je overbodige exclamaties achterwege en je topic ziet er heel anders uit.

[Hatsieflatsie]

Thnx voor tip, goed punt. Zal het in gaten houden.

[Janoz]

NMe schreef op vrijdag 25 oktober 2013 @ 15:57:
Precies, min of meer dezelfde constructie als in PHP dus, al had ik geen idee dat het in échte talen zoals C++ ook met enige regelmaat gebeurt.

Komt natuurlijk ook meer omdat deze echte taal van oorsprong helemaal geen boolean type kent . Andere strong typed talen geven gewoon een error wanneer er geen boolean als conditie staat. Het voorbeeld van .oisyn zou dan worden

Java:

if ((o = FindObject("foo")) != null) 
    o.doSomething();

[Zoijar]

Janoz schreef op zaterdag 26 oktober 2013 @ 10:49:
Komt natuurlijk ook meer omdat deze echte taal van oorsprong helemaal geen boolean type kent . Andere strong typed talen geven gewoon een error wanneer er geen boolean als conditie staat. Het voorbeeld van .oisyn zou dan worden

Java:

if ((o = FindObject("foo")) != null) 
    o.doSomething();

Strict gezien is C++ ook hier strongly typed aangezien er een impliciete conversie naar bool wordt gedaan. Dus die != null vindt plaats in de constructor van bool: bool(void* x) {this->value = (x != nullptr);} Enige gotcha is dat voor deze specifieke impliciete conversie naar bool er ook naar 'explicit' conversies wordt gekeken.

[ Voor 8% gewijzigd door Zoijar op 26-10-2013 12:38 ]