[Prog]Procedure parameterss vraag

[Fristi]

Loha
Kheb ezo een klein vraagske.

Wanneer hebt ge bij parameters van een procedure geen type-idfentifier?

Volgens slides is er een uitzondering.
Doelt ie hier mee op open arrays of benk de bal mis aant slaan?

groetjes
Fris

[Robbe]

Loha
Kheb ezo een klein vraagske.

Wanneer hebt ge bij parameters van een procedure geen type-idfentifier?

Volgens slides is er een uitzondering.
Doelt ie hier mee op open arrays of benk de bal mis aant slaan?

groetjes
Fris

ik zou denken bij de actuele parameters? maar elke parameter heeft normaal een type-identifier, enige type dat niet 'gedefinieerd' is zou een open array zijn dan. Maar in mijn ogen is dat ook gedefinieerd.

[Fristi]

Ja ik vind da perrsoonlijk ook dat ad een type identifier heeft, maar tis tenige dak me kan inbeelden

[Pieter Belmans]

Een typeidentifier is een gedefinieerd TYPE. De specificatie die bij een formele parameter hoort, hoeft niet per se volwaardige identifier te zijn, een naamloze typespecificatie is genoeg. Bijvoorbeeld string: ARRAY n OF CHAR; daar zit geen identifier in, maar wel een specificatie. Het hoeft ook geen open array te zijn dus.

[Winak465]

Ehm is string dan niet de type-identifier?

[PieterK]

Ehm is string dan niet de type-identifier?

Nope. String is hier varIdentifier. Hij doelt op anonieme typespecificatie.
Normaal hebt ge gedeclareerd:

Code: Select all

MODULE bla;



TYPE

 string = ARRAY 10 OF CHAR;



...



PROCEDURE test(s: string);

BEGIN

  ...

END test;



END bla.

Nu krijgt ge:

Code: Select all

MODULE bla;



PROCEDURE test(string: ARRAY 10 OF CHAR);

BEGIN

 ...

END test;



END bla.

Meer info: cursus op pagina 95 onderaan.

Het antwoord op de Fristi z'n vraag is dus gewoon: bij anonieme typespecificatie en bij open arrays, right?

[Pieter Belmans]

Ehm is string dan niet de type-identifier?

Nope. String is hier varIdentifier. Hij doelt op anonieme typespecificatie.
Normaal hebt ge gedeclareerd:

Code: Select all

MODULE bla;



TYPE

 string = ARRAY 10 OF CHAR;



...



PROCEDURE test(s: string);

BEGIN

  ...

END test;



END bla.

Nu krijgt ge:

Code: Select all

MODULE bla;



PROCEDURE test(string: ARRAY 10 OF CHAR);

BEGIN

 ...

END test;



END bla.

Meer info: cursus op pagina 95 onderaan.

Het antwoord op de Fristi z'n vraag is dus gewoon: bij anonieme typespecificatie en bij open arrays, right?

Ja. Maar, ik denk niet dat het mogelijk is een open array als type te definiëren en die dan met zijn typeidentifier te gebruiken in de formele paramaterlijst. Volgens mij checkt Oberon bij een typedeclaratie van een open array of er wel een pointer naar is, zodat er geheugenallocatie kan uitgevoerd worden. Dus "naamloze typespecificatie" should be enough, aangezien open arrays per definitie dus naamloos moeten zijn om in een formele parameterlijst opgenomen te kunnen worden.

[Fristi]

welja, das dan ook weer min of meer opgeklaard

[PieterK]

Ja. Maar, ik denk niet dat het mogelijk is een open array als type te definiëren en die dan met zijn typeidentifier te gebruiken in de formele paramaterlijst. Volgens mij checkt Oberon bij een typedeclaratie van een open array of er wel een pointer naar is, zodat er geheugenallocatie kan uitgevoerd worden. Dus "naamloze typespecificatie" should be enough, aangezien open arrays per definitie dus naamloos moeten zijn om in een formele parameterlijst opgenomen te kunnen worden.

k. Das inderdaad waar. Ik heb ook nog een vraagje:

Wat mag/moet het type van de receiver
zijn? Waarom?

Het gaat me vooral om de waarom. Het mag ofwel een waardeparameter van een type pointer naar een record zijn ofwel een variabeleparameter van het type record. Dus: waarom?
(Volgens mij is deze vraag al eens gesteld maar ik kon ze niet direct terugvinden.)

[Pieter Belmans]

Omdat ge ni in staat zijn om object georiënteerd te werken op een SHORTINT? Een RECORD is het enige type waar ge in Oberon-1 PROCEDURE-velden aan kon toekennen, want zo werkte het more or less in the good ol' days als ik m'n boek juist gelezen heb.

En als waardeparameter een pointer, betekent dat ge bij wijziging van velden in de reciever, daadwerkelijk iets verandert in het geheugen. Een variabeleparameter is immers een pointer naar het echte geheugenadres met de informatie. Hier werk je dus ineens met een pointer, die dus waardeparameter moet zijn, anders kan je het object zelf gaan toekennen aan andere dingen enzo, which is a bit bad practice. Al kan ik me wel usecases bedenken (maar dat gaat voor bijna alles ).

Als je reciever een RECORD is, moet het een variabeleparameter zijn, anders ga je voorbij aan het feit dat OOP een manier van programmeren is die vertrekt vanuit de data, die handelingen uitvoert. Nu kan je wel handelingen uitvoeren, maar ze hebben geen resultaat, je slaagt immers het resultaat niet op, er is een kopie van je object gemaakt .

[Sebastiaan]

Ja. Maar, ik denk niet dat het mogelijk is een open array als type te definiëren en die dan met zijn typeidentifier te gebruiken in de formele paramaterlijst. Volgens mij checkt Oberon bij een typedeclaratie van een open array of er wel een pointer naar is, zodat er geheugenallocatie kan uitgevoerd worden. Dus "naamloze typespecificatie" should be enough, aangezien open arrays per definitie dus naamloos moeten zijn om in een formele parameterlijst opgenomen te kunnen worden.

k. Das inderdaad waar. Ik heb ook nog een vraagje:

Wat mag/moet het type van de receiver
zijn? Waarom?

Het gaat me vooral om de waarom. Het mag ofwel een waardeparameter van een type pointer naar een record zijn ofwel een variabeleparameter van het type record. Dus: waarom?
(Volgens mij is deze vraag al eens gesteld maar ik kon ze niet direct terugvinden.)

Damn te laat.

[PieterK]

Omdat ge ni in staat zijn om object georiënteerd te werken op een SHORTINT? Een RECORD is het enige type waar ge in Oberon-1 PROCEDURE-velden aan kon toekennen, want zo werkte het more or less in the good ol' days als ik m'n boek juist gelezen heb.

En als waardeparameter een pointer, betekent dat ge bij wijziging van velden in de reciever, daadwerkelijk iets verandert in het geheugen. Een variabeleparameter is immers een pointer naar het echte geheugenadres met de informatie. Hier werk je dus ineens met een pointer, die dus waardeparameter moet zijn, anders kan je het object zelf gaan toekennen aan andere dingen enzo, which is a bit bad practice. Al kan ik me wel usecases bedenken (maar dat gaat voor bijna alles ).

Als je reciever een RECORD is, moet het een variabeleparameter zijn, anders ga je voorbij aan het feit dat OOP een manier van programmeren is die vertrekt vanuit de data, die handelingen uitvoert. Nu kan je wel handelingen uitvoeren, maar ze hebben geen resultaat, je slaagt immers het resultaat niet op, er is een kopie van je object gemaakt .

Dus effe om te sumarizen:
Waardeparamter van een pointertype omdat we dus willen vermijden dat we gaan knoeien met de pointer maar wel de data (waarnaar de pointer wijst) kunnen veranderen. En een variabele parameter van het recordtype omdat we anders niks kunnen veranderen aan de data.

Right?
Bedankt voor de uitleg! It is much appreciated!

Damn te laat.

Ge moogt altijd nog eens proberen om het uit te leggen hé. Kan alleen maar duidelijker worden zo (behalve als gij iets tegenstrijdigs zegt natuurlijk)

[Pieter Belmans]

Omdat ge ni in staat zijn om object georiënteerd te werken op een SHORTINT? Een RECORD is het enige type waar ge in Oberon-1 PROCEDURE-velden aan kon toekennen, want zo werkte het more or less in the good ol' days als ik m'n boek juist gelezen heb.

En als waardeparameter een pointer, betekent dat ge bij wijziging van velden in de reciever, daadwerkelijk iets verandert in het geheugen. Een variabeleparameter is immers een pointer naar het echte geheugenadres met de informatie. Hier werk je dus ineens met een pointer, die dus waardeparameter moet zijn, anders kan je het object zelf gaan toekennen aan andere dingen enzo, which is a bit bad practice. Al kan ik me wel usecases bedenken (maar dat gaat voor bijna alles ).

Als je reciever een RECORD is, moet het een variabeleparameter zijn, anders ga je voorbij aan het feit dat OOP een manier van programmeren is die vertrekt vanuit de data, die handelingen uitvoert. Nu kan je wel handelingen uitvoeren, maar ze hebben geen resultaat, je slaagt immers het resultaat niet op, er is een kopie van je object gemaakt .

Dus effe om te sumarizen:
Waardeparamter van een pointertype omdat we dus willen vermijden dat we gaan knoeien met de pointer maar wel de data (waarnaar de pointer wijst) kunnen veranderen. En een variabele parameter van het recordtype omdat we anders niks kunnen veranderen aan de data.

Right?
Bedankt voor de uitleg! It is much appreciated!

Dit is de tweede bevestiging. Als ge nog ne keer vraagt of uw idee juist is, verdien ik 1 blikje/glas/tas/andere-geschikte-drankcontainer limonade/thee vind ik . U mag schrappen wat niet past, en graag een aanvaardbare combinatie, dus geen blikken thee.

[PieterK]

/me thinks someone is getting annoyed

Ik zal het niet meer doen.

[cG`]

Het gaat me vooral om de waarom. Het mag ofwel een waardeparameter van een type pointer naar een record zijn ofwel een variabeleparameter van het type record. Dus: waarom?
(Volgens mij is deze vraag al eens gesteld maar ik kon ze niet direct terugvinden.)

Een variabele parameter van het type record is eigenlijk hetzelfde als een pointer naar een record, alleen wordt die pointer dan achter de schermnen gecreerd.