[JAVA] Operator Overloading (was: parseInt)

[TuLPMaN]

Ik probeer een oefenopgave te maken voor een tentamen morgen. De opdracht luidt:

In de klasse Integer is een statische methode parseInt beschikbaar, die een string die uit cijfertekens bestaat omzet in de overeenkomstige int.
Schrijf deze methode zelf, waarbij je uiteraard de al bestaande methode parseInt niet mag gebruiken. Ook andere methoden uit de klassen Integer en Double mag je niet gebruiken. Je mag wel de methoden uit klasse String gebruiken.
Je mag er zonder controle van uitgaan dat de String die als parameter wordt meegegeven alleen maar cijfertekens bevat. Je hoeft dus geen foutsituaties af te handelen, en ook geen negatieve getallen.

Ik heb dit:

Java:

public int parzeInt(String s)
{
    int t, resultaat, n;
    char c;
    n=0;
    
    resultaat=0;
    
    for(t=0;t<s.length();t++)
    {
        c=s.charAt(t);
        n=c-48;
        
    }
    
    return n;
}

Maar zo wordt natuurlijk alleen het laatst opgegeven cijfer in de String geconverteerd. Hoe zorg ik ervoor dat een heel getal kan worden geconverteerd?

[ Voor 2% gewijzigd door curry684 op 16-10-2003 01:24 . Reden: mooi he die [code] tags :) ]

[Marcj]

Simpele uitleg:

- Lees een cijfer
- Vermenigvuldig het getal die je al hebt met 10
- Tel hier het gelezen cijfer bij op
- Herhaal dit tot het einde

Dit moet je zelf toch wel naar javacode kunnen omzetten??

(ps. Voor code kun je ook de [ code ] - tags gebruiken)

[TuLPMaN]

Ehh...ben redelijk een leek wat betreft JAVA, maar begrijp de opzet op zich. Moet ik dat dan in dat tellertje van mij integreren?

[curry684]

Java:

for(t=0;t<s.length();t++) 
    { 
        resultaat *= 10;
        resultaat += s.charAt(t) - 48; 
    } 

Wel erg simpel he

Misschien een idee om een boek/tutorial over deze materie door te lezen, dit is niet echt het niveau vragen waar Programming & Webscripting voor opgezet is.

[TuLPMaN]

curry684 schreef op 16 October 2003 @ 01:26:

Java:

for(t=0;t<s.length();t++) 
    { 
        resultaat *= 10;
        resultaat += s.charAt(t) - 48; 
    } 

Wel erg simpel he

Misschien een idee om een boek/tutorial over deze materie door te lezen, dit is niet echt het niveau vragen waar Programming & Webscripting voor opgezet is.

Thanx anyway... Snap best dat dit niet echt een forum voor Dummies is, maarja...

Om het af te leren heb ik nog 1 klein vraagje... (als het mag) :

Opgave:

Schrijf een statische methode aantalInLangste. De methode heeft twee parameters: een array van strings, en een los letterteken. De methode moet als resultaat opleveren hoe vaak dat letterteken voorkomt in de langste string in de array.
Bijvoorbeeld: als de array de strings “appel”, “peer” en “banaan” bevat, en het losse letterteken is ‘n’, dan is het resultaat 2. De langste string van de drie is namelijk “banaan”, en daarin komt de letter ‘n’ tweemaal voor.
Zijn er strings die precies even lang zijn, dan mag het programma er daar zelf een van kiezen.

Ik krijg hem alleen zover dat de methode het langste woord eruit pikt..

Java:

public int langste(String [] tekst, String letter)
{
    int t, resultaat, lengte;
    
    resultaat=0;
    
    for(t=0;t<tekst.length;t++)
    {   
        lengte=tekst[t].length();
        
        if(lengte>resultaat)
            resultaat=lengte;
    }
            
    return resultaat;
}

Als iemand me hierbij zou kunnen helpen kan ik met een gerust hartje naar bed

[ Voor 58% gewijzigd door TuLPMaN op 16-10-2003 01:45 ]

[Jurgle]

Java:

public int langste(String [] tekst, String letter) 
{ 
    int t, resultaat, lengte, positie; 
     
    resultaat=0; 
    positie = 0;
     
    for(t=0;t<tekst.length;t++) 
    {     
        lengte=tekst[t].length(); 
         
        if(lengte>resultaat)
        {
            resultaat=lengte;
            positie = t;
        }
    } 
    
    resultaat = 0;
    
    for(t=0;t<tekst[positie].length();t++)
    {
        if(tekst[positie].charAt(t) == letter.charAt(0))
        {
            resultaat++;
        }
    }
    
    return resultaat; 
}

zoiets?

[ Voor 13% gewijzigd door Jurgle op 16-10-2003 02:05 ]

[TuLPMaN]

Je bent geweldig, thanx !!! Werkt idd... tering, hoezo kom ik daar zelf nou niet achter??? Wordt morgen nog pittig dan...

[reddevil]

makkelijkst om te leren programmeren is om 1 ding tegelijk te willen doen... dus nu eerst zorgen dat je weet waar het langste woord staat, en daarna pas in dat woord kijken en dus kijken hoeveel letters erin voorkomen, zo heeft jurgle het ook opgelost snel

[drm]

Imho kun je dit veel netter doen door een Comparable interface te gebruiken en vervolgens de array te sorteren op lengte. Dat is meer de Java-benadering van de zaak, zal ik maar zeggen. Hoewel er wel duizend wegen zijn die naar Rome leiden, lijkt het mij niet gek om je dit soort dingen eigen te maken.

[Eelke Spaak]

drm schreef op 16 October 2003 @ 09:27:
Imho kun je dit veel netter doen door een Comparable interface te gebruiken en vervolgens de array te sorteren op lengte. Dat is meer de Java-benadering van de zaak, zal ik maar zeggen. Hoewel er wel duizend wegen zijn die naar Rome leiden, lijkt het mij niet gek om je dit soort dingen eigen te maken.

Mwa, er zijn genoeg mensen die in Java liever met arrays werken dan verzamelingen (ikzelf bijvoorbeeld ). Verder lijkt mij een arraysort behoorlijk wat langzamer dan het hierboven gebruikte algoritme.

[Alarmnummer]

Vladimir G. schreef op 16 oktober 2003 @ 10:50:
[...]

Mwa, er zijn genoeg mensen die in Java liever met arrays werken dan verzamelingen (ikzelf bijvoorbeeld ). Verder lijkt mij een arraysort behoorlijk wat langzamer dan het hierboven gebruikte algoritme.

Ik vind arrays in java zwaar sucken. Ze maken niet eens deel uit van het collection framework.

Trouwens wel jammer dat je collections syntactisch niet zo makkelijk kan aanmaken als arrays bv: new int[]{1,2,3,4,5} en verder is het ook jammer dat je bij de nieuwe jdk1.5 syntax weer arrays bij var args binnen krijgt.

add(int[] i....}{}

ipv een List

ps:
als je de implementatie bekijkt van arraylist of vector, zie je dat onder de grond ook arrays worden gebruikt Oja.. arrays kan je ook niet mee laten groeien... nog een enorm nadeel.

[Eelke Spaak]

Alarmnummer schreef op 16 October 2003 @ 12:11:
[...]


Ik vind arrays in java zwaar sucken. Ze maken niet eens deel uit van het collection framework.

Trouwens wel jammer dat je collections syntactisch niet zo makkelijk kan aanmaken als arrays bv: new int[]{1,2,3,4,5} en verder is het ook jammer dat je bij de nieuwe jdk1.5 syntax weer arrays bij var args binnen krijgt.

Dat ze niet deel uitmaken van het collection framework komt omdat ze fundamenteel onderdeel zijn van de taal zelf, en niet de API's. Een ander gevolg hiervan is dat je een bijzondere syntaxis kan gebruiken (de welbekende []), waar dat bij API-klassen zoals Vector, ArrayList etc. niet kan.

Dat laatste vind ik eigenlijk wel mooi, want het is een goed voorbeeld van de pure object-oriëntatie van Java.

[ Voor 8% gewijzigd door Eelke Spaak op 16-10-2003 17:00 ]

[Alarmnummer]

Een ander gevolg hiervan is dat je een bijzondere syntaxis kan gebruiken (de welbekende []), waar dat bij API-klassen zoals Vector, ArrayList etc. niet kan.

Dat zou geen problemen mogen opleveren, kijk bv naar de property syntax van c#, daarmee kan je bv ook [ ] op allerlei structuren gebruiken.

[Eelke Spaak]

Alarmnummer schreef op 16 October 2003 @ 17:30:
[...]

Dat zou geen problemen mogen opleveren, kijk bv naar de property syntax van c#, daarmee kan je bv ook [ ] op allerlei structuren gebruiken.

Dat is logisch, want dat is nou eenmaal gedefiniëerd in de taal C# . De bedenkers van Java hebben er bewust voor gekozen om low-level operatoren en Object-functieaanroepen (zoals bij het collection framework) strict gescheiden te houden. Terecht, naar mijn mening, want zo komt het OO-karakter veel beter uit en heb je een 'schonere' en mooiere taal. _{Maar eigenlijk is dat natuurlijk een kwestie van smaak...}

[Alarmnummer]

Vladimir G. schreef op 16 October 2003 @ 22:33:
[...]
Dat is logisch, want dat is nou eenmaal gedefiniëerd in de taal C# . De bedenkers van Java hebben er bewust voor gekozen om low-level operatoren en Object-functieaanroepen (zoals bij het collection framework) strict gescheiden te houden.

Property syntax (dus persoon.voornaam="Jan" ipv persoon.setVoornaam("Jan") ) is stukken duidelijker. En dito geld voor de indexed-property syntax.

Terecht, naar mijn mening, want zo komt het OO-karakter veel beter uit en heb je een 'schonere' en mooiere taal. _{Maar eigenlijk is dat natuurlijk een kwestie van smaak...}

Ik zou akelige methode aanroepen geen pluspunt voor een oo taal willen noemen. Operator overloading en properties zijn imho een zwaar plus punt voor c# omdat je code een stuk korter (en in dit geval overzichtelijker) blijft.

[Eelke Spaak]

Alarmnummer schreef op 17 oktober 2003 @ 09:51:
[...]

Property syntax (dus persoon.voornaam="Jan" ipv persoon.setVoornaam("Jan") ) is stukken duidelijker. En dito geld voor de indexed-property syntax.


[...]

Ik zou akelige methode aanroepen geen pluspunt voor een oo taal willen noemen. Operator overloading en properties zijn imho een zwaar plus punt voor c# omdat je code een stuk korter (en in dit geval overzichtelijker) blijft.

OK, dan zijn we het dus niet eens over puur een kwestie van smaak . Ik vind methode-aanroepen duidelijker en schoner dan operators op objecten die door die objecten zelf gedefiniëerd worden. Maar goed, hier komen we dus niet uit, dus laat maar .

edit:
Oja, dingen als persoon.voornaam="Jan" zijn wel mogelijk in Java (door je properties niet als 'private' maar als 'public' aan te duiden), alleen niet gewenst door veel programmeurs, waaronder degenen die Java hebben bedacht.

[ Voor 16% gewijzigd door Eelke Spaak op 17-10-2003 10:05 ]

[drm]

Ik zou akelige methode aanroepen geen pluspunt voor een oo taal willen noemen. Operator overloading en properties zijn imho een zwaar plus punt voor c# omdat je code een stuk korter (en in dit geval overzichtelijker) blijft.

I second that, hoewel het toch een kwestie van smaak blijft.

[Woy]

Vladimir G. schreef op 17 October 2003 @ 10:04:
[...]

OK, dan zijn we het dus niet eens over puur een kwestie van smaak . Ik vind methode-aanroepen duidelijker en schoner dan operators op objecten die door die objecten zelf gedefiniëerd worden. Maar goed, hier komen we dus niet uit, dus laat maar .

edit:
Oja, dingen als persoon.voornaam="Jan" zijn wel mogelijk in Java (door je properties niet als 'private' maar als 'public' aan te duiden), alleen niet gewenst door veel programmeurs, waaronder degenen die Java hebben bedacht.

Dus jij vindt het overzichtelijker als je bijvoorbeeld je eigen BigInt class implementeerd dat je bij het optellen zo doet

Java:

BigInt a = new BigInt( 1 ); //Jaja ik weet het niet echt groot :)
BigInt b = new BigInt( 2 );
BigInt c = a.add( b );

dan

C#:

BigInt a = new BigInt( 1 ); //Jaja ik weet het niet echt groot :)
BigInt b = new BigInt( 2 );
BigInt c = a + b;

Je moet natuurlijk wel goed oppassen waarvoor je operator overloading gebruikt maar in dit soort gevallen vindt ik het zeker leesbaarder dan dat je gebruik maakt van een methode.

edit:
Oja, dingen als persoon.voornaam="Jan" zijn wel mogelijk in Java (door je properties niet als 'private' maar als 'public' aan te duiden), alleen niet gewenst door veel programmeurs, waaronder degenen die Java hebben bedacht.

Ja maar dan heb je dus geen controle meer over je variabele in C# kan je er gewoon een bijbehorende methode bij declareren op de volgende manier

C#:

private int _aantal;

public int Aantal
{
    get
    {
        return _aantal;
    }
    set
    {
        if( value < 0 )
            throw new Exception( "Ja dat mag dus niet he" );
        _aantal = value;
    }
}

Wat dus eigenlijk hetzelfde is als een get en set methode implementeren ( Dit doet de compiler onderwater eigenlijk ook voor je ). Maar ik vindt het wel leesbaarder in veel gevallen. Ook hier geld weer dat je natuurlijk wel moet kijken op wat je het toepast.

offtopic:
Waarom gebruikt de C# code tag trouwens niet gewoon dezelfde syntax highlighter als java. Zou toch grotendeels goed moeten werken

[ Voor 38% gewijzigd door Woy op 17-10-2003 10:14 ]

[Alarmnummer]

Vladimir G. schreef op 17 October 2003 @ 10:04:
[...]

OK, dan zijn we het dus niet eens over puur een kwestie van smaak . Ik vind methode-aanroepen duidelijker en schoner dan operators op objecten die door die objecten zelf gedefiniëerd worden. Maar goed, hier komen we dus niet uit, dus laat maar .

Het komt misschien ook hoe je er naar kijkt. Ik schrijf software voor de kost, en dan ben ik wat pragmatischer van aard. Het maakt me niet uit of het niet helemaal oo is, als ik maar minder werk hoef te verzetten (of code makkelijker kan doorzien) dan ben ik een blij man.

edit:
Oja, dingen als persoon.voornaam="Jan" zijn wel mogelijk in Java (door je properties niet als 'private' maar als 'public' aan te duiden), alleen niet gewenst door veel programmeurs, waaronder degenen die Java hebben bedacht.

Een property is iets heel anders dan publieke field hoor Met een property heb je het schrijf gemak van een publiek field, maar de kracht van getters/setters (dus je kan er functionaliteit aan toevoegen).

[ Voor 10% gewijzigd door Alarmnummer op 17-10-2003 10:12 ]

[esf]

Misschien een beetje laat, maar moet je bij die parseInt methode geen exceptie gooien als de string geen getal bevat? Dit doet de originele methode ParseInt tenminste ook..

Edit:

hammerhead schreef op 17 oktober 2003 @ 10:21:
[...]
Nee.... In eerste post stond:
[...]

hmm.. overheen gelezen waarschijnlijk.. Sorry voor de hierdoor vrij nutteloze post..

[ Voor 44% gewijzigd door esf op 20-10-2003 00:07 ]

[hammerhead]

esf schreef op 17 October 2003 @ 10:19:
Misschien een beetje laat, maar moet je bij die parseInt methode geen exceptie gooien als de string geen getal bevat? Dit doet de originele methode ParseInt tenminste ook..

Nee.... In eerste post stond:

Je mag er zonder controle van uitgaan dat de String die als parameter wordt meegegeven alleen maar cijfertekens bevat. Je hoeft dus geen foutsituaties af te handelen, en ook geen negatieve getallen.

[drm]

Alarmnummer:
Een property is iets heel anders dan publieke field hoor Met een property heb je het schrijf gemak van een publiek field, maar de kracht van getters/setters (dus je kan er functionaliteit aan toevoegen).

Je zou een property ook kunnen zien als een operator overloading voor = (object.property, value)

En ik snap nog steeds niet waarom operator overloading iets zou zijn wat niet "netjes OO" is. Alsof je van "object georienteerdheid" afstapt... Ben ik het dus niet mee eens.

Een andere discussie is dat je de programmeur meer vrijheid geeft in wat hij op "mag" schrijven. Gevolg is dus (vaak) ook dat er ruimte komt voor brakke (onleesbare) code. Dus, om maar 'ns met Johan Cruijff te spreken: "Zo hep elluk foohdeel ze eige nahdeel"

Imho is dat een kwestie van discipline in net blijven schrijven en goed documenteren van de code. Tenslotte hebben er maar weinig mensen echt moeite met een

C++:

std::cout << "woei!";

terwijl de << toch eigenlijk een bit-shift left operator is

[Verwijderd]

even over dit voorbeeldje

Alarmnummer schreef op 17 October 2003 @ 09:51:
Property syntax (dus persoon.voornaam="Jan" ipv persoon.setVoornaam("Jan") ) is stukken duidelijker. En dito geld voor de indexed-property syntax.

in het C# geval; dus persoon.voornaam="Jan"

als ik bijv alleen schrijf rechten wil geven aan persoon.voornaam hoe ziet dit dan uit?

Ja ik weet erg basis maar ik heb echt totaal nul ervaring met de .NET structuur.

in java maak je gewoon een set methode en geen get methode.... dus de vraag is hoe doe ik dit in C#

[Alarmnummer]

zie [rml]rwb in "[ JAVA] parseInt"[/rml]

[drm]

afaik maak je dan in C# voor die property ook geen set-implementatie, of je throwt een exceptie in de setter. De eerste lijkt mij de meeste logische.

Maar daar mogen de C#-guru's uitsluitsel over geven

[Woy]

drm schreef op 17 October 2003 @ 11:17:
afaik maak je dan in C# voor die property ook geen set-implementatie, of je throwt een exceptie in de setter. De eerste lijkt mij de meeste logische.

Maar daar mogen de C#-guru's uitsluitsel over geven

Yup helemaal gelijk.
dus zo

C#:

public int Aantal
{
    set
    {
        _aantal = value;
    }
}

edit:

ow het ging over alleen schrijf rechten en niet over alleen leesrechten. ( Scheelt gelukkig maar 1 letter. )

[ Voor 17% gewijzigd door Woy op 17-10-2003 14:37 ]

[Glimi]

Vladimir G. schreef op 17 October 2003 @ 10:04:
OK, dan zijn we het dus niet eens over puur een kwestie van smaak . Ik vind methode-aanroepen duidelijker en schoner dan operators op objecten die door die objecten zelf gedefiniëerd worden. Maar goed, hier komen we dus niet uit, dus laat maar .

_{Ik dan ook maar even}
De operator overloadings die jij hier aanhaald zijn idd gewoon een kwesite van smaak, een beetje suiker om het wat 'natuurlijker' eruit te laten zien. Natuurlijk ziet bij aritmiek de + er beter uit dan 'add'.
Verder is er natuurlijk geen discussie echt nuttig of het mooi is, als het over suiker gaat. Immers je hoeft het niet te gebruiken Als voorbeeldjes noem ik bijvoorbeel anonieme inner classes, ook een stukje suiker wat veel mensen mooi vinden en anderen lelijk

Echter er zijn ook hele andere vormen van operator overloading die veel serieuzer zijn en die weldegelijk de typesterkte van de taal kunnen aanpassen.
Wat zou je krijgen als je de new operator op een class kan aanpassen? Wat als je de int() operator kan aanpassen? Wat als je = (OtherType) kan aanpassen?
Het aanpassen van de new levert natuurlijk dikke problemen op in een VM en het overloaden van casting en of assignatie operatoren verzwakt je typesysteem door impliciete casting.

[whoami]

drm schreef op 17 October 2003 @ 11:17:
afaik maak je dan in C# voor die property ook geen set-implementatie, of je throwt een exceptie in de setter. De eerste lijkt mij de meeste logische.

Maar daar mogen de C#-guru's uitsluitsel over geven

Enkel een set property maken is idd voldoende, en ook beter.
Als je bv. enkel 'schrijfrechten' wilt geven, en je maakt enkel een 'set' property, en je wilt later in je code die waarde terug uitlezen, dan zal het geval niet compileren, terwijl de methode met het throwen v/e exceptie wel zal compileren.
't Eerste is dus de meest logische , en ook diegene die het minst werk met zich meebrengt.

[Woy]

Wat ik me eigenlijk net bedenk is dat je geen Property kan maken met een public get method en een protected set method.
Dus ik bedoel zoiets

C#:

private int _waarde;
public int Waarde
{
    get
    {
        return _waarde;
    }
    protected set
    {
        if( value > 0 )
            _waarde = value;
        else
            throw new Exception( "Dit mag dus niet he" );
    }
}

Ik heb het eigenlijk nog nooit nodig gehad maar zover ik zie en even snel geprobeerd heb is dit niet mogelijk zonder een tweede Property te declareren wat natuurlijk weer niet mooi is. Zie ik nou wat over het hoofd of kan het echt niet?

[whoami]

rwb schreef op 17 October 2003 @ 14:35:
Wat ik me eigenlijk net bedenk is dat je geen Property kan maken met een public get method en een protected set method.
Dus ik bedoel zoiets

Ik heb het eigenlijk nog nooit nodig gehad maar zover ik zie en even snel geprobeerd heb is dit niet mogelijk zonder een tweede Property te declareren wat natuurlijk weer niet mooi is. Zie ik nou wat over het hoofd of kan het echt niet?

Nope, ik heb daar ook al eens naar gezocht, want ik had het wel nodig.
Wel irritant eigenlijk.
Dat komt natuurlijk omdat je je access modifier toekent aan de naam van je property, en niet aan de desbetreffende setter of getter.
Je kan als work-around natuurlijk wel 2 properties maken dan bv:

code:

public getAttribute
{
    get
    {
             return _blaat;
    }
}

protected setAttribute
{
     set
     {
            _blaat = value;
     }
}

maar dit is eigenlijk ranzig. Dan kan je evengoed een getter en een setter method maken ipv gebruik te maken van die properties.

[drm]

Maar is het dan niet logischer om de access van de property al op protected te zetten en dan voor public alleen de getter te setten?

C#:

protected int waarde;
public Waarde {
   get {
       return waarde;
   }
}

zoiets?

En als je toch de methoden transparant wilt hebben zou ik het zo doen:

C#:

private int waarde;
public int Waarde {
   get {
      return getWaarde ();
   }
}
protected int getWaarde () { ... }
protected int setWaarde () { ... }

en dan "intern" toch gewoon de setWaarde () te gebruiken.

Hoewel het inderdaad wel vreemd is dat je voor de set/get geen access modifier kan/mag zetten

[Yoeri]

edit:

/me was ff vergeten dat er een tweede pagina was in dit topic. Ze moeten er hier toch es over denken om die quickreply ènkel op de laatste pagina weer te geven

[ Voor 92% gewijzigd door Yoeri op 17-10-2003 14:51 ]

[whoami]

drm schreef op 17 oktober 2003 @ 14:47:
Maar is het dan niet logischer om de access van de property attribute al op protected te zetten en dan voor public alleen de getter te setten?

C#:

protected int waarde;
public Waarde {
   get {
       return waarde;
   }
}

zoiets?

Dat kan je inderdaad doen, maar dat is niet altijd afdoende als workaround.
Stel dat je bij het setten van die waarde altijd een controle, of een berekening, of whatever moet uitvoeren.
Dat zou je dus mooi kwijt kunnen in die property-setter.
Als je die setter dus niet meer hebt, dan moet je een andere manier verzinnen, een method die de goede waarde returned bv:

code:

Class.Attribute = DoeSomething(5);

[Eelke Spaak]

Alarmnummer
Het komt misschien ook hoe je er naar kijkt. Ik schrijf software voor de kost, en dan ben ik wat pragmatischer van aard. Het maakt me niet uit of het niet helemaal oo is, als ik maar minder werk hoef te verzetten (of code makkelijker kan doorzien) dan ben ik een blij man.

Ik programmeer alleen als hobby (en af en toe voor de studie), dus wellicht dat dat ons meningsverschil verklaart.

drm
En ik snap nog steeds niet waarom operator overloading iets zou zijn wat niet "netjes OO" is. Alsof je van "object georienteerdheid" afstapt... Ben ik het dus niet mee eens.

Op een laag niveau (je kan ook de semantiek zeggen) is het natuurlijk nog steeds object-georiënteerd, maar dan komt dat in de syntax minder duidelijk naar voren.

Imho is dat een kwestie van discipline in net blijven schrijven en goed documenteren van de code. Tenslotte hebben er maar weinig mensen echt moeite met een

C++:

std::cout << "woei!";

terwijl de << toch eigenlijk een bit-shift left operator is

Als ik eerlijk ben vind ik

C++:

cout << "hoi";

ook behoorlijk lelijk, en geef ik de voorkeur aan iets als

C++:

cout.print("hoi");

Helaas bestaat er geen formatted-outputfunctie op het cout object, en ben ik dus veroordeeld de <<-operator te gebruiken .

Glimi
De operator overloadings die jij hier aanhaald zijn idd gewoon een kwesite van smaak, een beetje suiker om het wat 'natuurlijker' eruit te laten zien. Natuurlijk ziet bij aritmiek de + er beter uit dan 'add'.

Dat vind ik dus niet. Een add() geeft duidelijk weer dat je met een functie-aanroep op een object bezig bent. Een + impliceert eigenlijk dat je de objecten bij elkaar optelt, en dat doe je helemaal niet (geheugenadressen optellen zou behoorlijk vreemde resultaten geven), want de compiler maakt er evengoed een functie-aanroep van.

Verder is er natuurlijk geen discussie echt nuttig of het mooi is, als het over suiker gaat. Immers je hoeft het niet te gebruiken

Helemaal mee eens .

Als voorbeeldjes noem ik bijvoorbeel anonieme inner classes, ook een stukje suiker wat veel mensen mooi vinden en anderen lelijk

Die vind ik ook ernstig lelijk. (Ik gebruik ze wel, maar dat is meer uit luiheid )

Wat zou je krijgen als je de new operator op een class kan aanpassen?

Is dat niet gewoon het definiëren van een constructor?

[Alarmnummer]

Vladimir G. schreef op 17 October 2003 @ 15:04:
[...]

Dat vind ik dus niet. Een add() geeft duidelijk weer dat je met een functie-aanroep op een object bezig bent. Een + impliceert eigenlijk dat je de objecten bij elkaar optelt, en dat doe je helemaal niet (geheugenadressen optellen zou behoorlijk vreemde resultaten geven), want de compiler maakt er evengoed een functie-aanroep van.

Hmmm.. het hele idee over adressen is imho ook beetje passee. Je moet je steeds meer bezighouden met de semantiek van objecten en niet zo met low level zaken.

En ik vind het verschil tussen een methode aanroep, operator aanroep en functie aanroep niet zo groot. (Technisch gezien maakt het namelijk geen fluit uit).

En verder is het misschien niet verstandig om operator overloading zo uitgebreid te maken als in c++, maar het zou wel fijn zijn als je de standaard wiskundige operatoren kon overloaden. Dan raak je tenminste een beetje af van

matrix.multiply(matrix2)

Weet iemand trouwens waarom properties niet in java komen? Ik zou geen enkele reden weten om het niet te doen en er komen toch al zo veel nieuwe (syntactisch 'lastige') features in, dat dit er ook wel bij kan.

[ Voor 25% gewijzigd door Alarmnummer op 17-10-2003 15:11 ]

[Eelke Spaak]

Alarmnummer schreef op 17 oktober 2003 @ 15:08:
[...]

Hmmm.. het hele idee over adressen is imho ook beetje passee. Je moet je steeds meer bezighouden met de semantiek van objecten en niet zo met low level zaken.

En ik vind het verschil tussen een methode aanroep, operator aanroep en functie aanroep niet zo groot. (Technisch gezien maakt het namelijk geen fluit uit).

Dat klopt inderdaad voor talen waar operator overloading bestaat, maar niet in bv. Java. Een operator-aanroep is een fundamentele bewerking op primitieven of op referenties naar objecten, en een functie/methode-aanroep is dat niet.

Zoals je ongetwijfeld weet levert

Java:

public class Test
{
    private String content;
    
    public Test(String s)
    {
        content = s;
    }
    
    public String getContent()
    {
        return content;
    }
    
    public void setContent(String s)
    {
        content = s;
    }

    public static void main(String[] args)
    {
        Test a = new Test("hoi");

        Test b = a;
        b.setContent("blaat");

        System.out.println(a.getContent());
    }
}

als output "blaat", en niet "hoi". Maar goed, zoals al geconstateerd is het een zeer begrijpelijke kwestie van persoonlijke smaak .

[Alarmnummer]

Vladimir G. schreef op 17 oktober 2003 @ 15:20:
[...]

Dat klopt inderdaad voor talen waar operator overloading bestaat, maar niet in bv. Java.

Java en geen operator overloading?? Het is dat je ze niet zelf mag definieren, maar java heeft wel degelijk operator overloading

1+2
"foo"+"bar"

Een operator-aanroep is een fundamentele bewerking op primitieven of op referenties naar objecten, en een functie/methode-aanroep is dat niet.

Ik weet niet waar jij dat vandaan hebt, maar daar klopt echt niets van. Het onderscheid tussen een operator aanroep, methode aanroep en een functie aanroep is puur een syntactische kwestie.

1+2 //operator
+(1,2) //functie
1.+(2) //methode

[ Voor 11% gewijzigd door Alarmnummer op 17-10-2003 15:26 ]

[Woy]

whoami schreef op 17 October 2003 @ 14:39:
[...]

code:

public getAttribute
{
    get
    {
             return _blaat;
    }
}

protected setAttribute
{
     set
     {
            _blaat = value;
     }
}

Dit is inderdaad wat ik ook voorstelde met een extra Property. Maar dit vindt ik eigenlijk zeer lelijk. Ik vindt het dus vreemd dat je niet op het get/set niveau aan kan geven wat de acces modifier is. Dan kan je bijvoorbeeld standaard gewoon de modifier van de property name erven en dat je ze kan overriden op get/set niveau.

[Eelke Spaak]

Alarmnummer schreef op 17 oktober 2003 @ 15:24:
[...]

Java en geen operator overloading?? Het is dat je ze niet zelf mag definieren, maar java heeft wel degelijk operator overloading

1+2
"foo"+"bar"

Ja, je hebt gelijk. Sorry, wat ik bedoelde is dat je ze niet zelf mag definiëren dus.

[...]

Ik weet niet waar jij dat vandaan hebt, maar daar klopt echt niets van. Het onderscheid tussen een operator aanroep, methode aanroep en een functie aanroep is puur een syntactische kwestie.

1+2 //operator
+(1,2) //functie
1.+(2) //methode

Laat ik het dan anders stellen; een operator is voor mijn gevoel iets wat vastligt, en waarvan het gedrag altijd hetzelfde is. Een functie- of methode-aanroep is iets wat je zelf een naam geeft en ook zelf definiëert. _{Ik realiseer me nu dat ik me alleen nog maar aan het beroepen ben op gevoel en smaak, en dat mijn punt objectief gezien dus onverdedigbaar is. Hetzelfde geldt overigens voor dat van jou...}

edit:
Oja, er zit wel degelijk semantisch verschil tussen een functie en een methode zoals jij die hierboven hebt gedefiniëerd: een methode is hier een procedure die eigenschap is van een object en een functie is een procedure die dat niet is. Dat verschil is niet alleen syntactisch.

[ Voor 14% gewijzigd door Eelke Spaak op 17-10-2003 15:39 ]

[Alarmnummer]

Vladimir G. schreef op 17 oktober 2003 @ 15:35:

Laat ik het dan anders stellen; een operator is voor mijn gevoel iets wat vastligt, en waarvan het gedrag altijd hetzelfde is.

Tja... misschien dat het komt omdat je er nog niet veel mee hebt gewerkt. Dan kunnen allerlei dingen vreemd aanvoelen. Polymorfisme zal voor een procedurele man ook vreemd aanvoelen, en pointcuts/advices zullen weer vreemd aanvoelen voor een oo man. Alles dat je niet kent lijkt vreemd...

Een functie- of methode-aanroep is iets wat je zelf een naam geeft en ook zelf definiëert. _{Ik realiseer me nu dat ik me alleen nog maar aan het beroepen ben op gevoel en smaak, en dat mijn punt objectief gezien dus onverdedigbaar is. Hetzelfde geldt overigens voor dat van jou...}

Tja... ik merk dat ik me in de praktijk toch soms loop te ergeren aan onnodige syntax.

code:

for(Iterator<Persoon> itt = _persoonList.iterator();itt.hasNext();){
     ....
}

of

code:

for(Persoon p: _persoonList){
     .....
}

Ik vind de laatste toch fijner en het maakt je code nog makkelijker om te overzien (tenslotte heb je minder onnodige tekst).

maar idd.. het is een kwestie van smaak

[Soultaker]

Alarmnummer schreef op 17 oktober 2003 @ 15:24:
Ik weet niet waar jij dat vandaan hebt, maar daar klopt echt niets van. Het onderscheid tussen een operator aanroep, methode aanroep en een functie aanroep is puur een syntactische kwestie.

1+2 //operator
+(1,2) //functie
1.+(2) //methode

Ik vind het allebei nogal discutabel. Volgens jouw redenatie is een prefix operator dus een functie (++(i)) (en tegelijkertijd een operator?).

Wat operators, methoden en functies precies zijn, is nogal afhankelijk van de context waarin je ze bespreekt. Een wiskundige zou zeggen dat een functie alleen invoer in uitvoer kan transformeren en dus nooit side-effects kan hebben (daarom wordt in sommige talen ook onderscheid gemaakt tussen procedures en functies). Voor een taal als C gaat dat niet op.

Ik kan me wel vinden in de stelling dat methoden en operators ook functies zijn, maar in het traditionele C++ vocabulaire heb je helemaal geen methoden (die dingen heten dan "member functions", hoewel ze hetzelfde doen). In SmallTalk zijn operators ook methoden (of eigenlijk: messages?) en heb je helemaal geen functies.

Om een wat concreter standpunt in te nemen: in Java zijn operators overloaded voor een vast aantal klassen; je kunt ze als gebruiker van de taal niet meer overloaden (terwijl dat in talen als C++ of Python wel kan).

[ Voor 10% gewijzigd door Soultaker op 17-10-2003 15:43 ]

[Alarmnummer]

Soultaker schreef op 17 October 2003 @ 15:42:
[...]

Ik vind het allebei nogal discutabel. Volgens jouw redenatie is een prefix operator dus een functie (++(i)) (en tegelijkertijd een operator?).

Tja.. persoonlijk vind ik het verschil tussen een functie/methode en operator eigelijk niet zo groot dus het maakt me niet uit hoe die genoemt wordt

[edit]
Ik wou er alleen mee laten zien dat het onderscheid niet zo groot is, en het was niet bedoelt als definitie.

Wat operators, methoden en functies precies zijn, is nogal afhankelijk van de context waarin je ze bespreekt. Een wiskundige zou zeggen dat een functie alleen invoer in uitvoer kan transformeren en dus nooit side-effects kan hebben (daarom wordt in sommige talen ook onderscheid gemaakt tussen procedures en functies). Voor een taal als C gaat dat niet op.

Hmmz... Het verschil tussen procedure en functie in pascal varianten (delphi, modula) is dat een procedure dus niets kan returnen. Uit welke talen heb jij deze definities?

[ Voor 9% gewijzigd door Alarmnummer op 17-10-2003 15:52 ]