[Prog] Een paar vraagjes

[Phil]

Ah, ist da gewoon en da dan uitleggen ofwa
Als da zo zit is elke vraag over ADT van den Arickx eigelijk hetzelfde. ge moet gewoon ff oo abstractie uitlegge en dan het herdefinieren van methodes mbv type extensie en polymorfisme :/

[Teun]

Nog ff snel een vraagje waar ik niet direct kan opkomen:

Bespreek de syntactische elementen die noodzakelijk (en voorhanden!) zijn voor object-georienteerd programmeren in Oberon. Bespreek in het bijzonder de eigenschappen van de receiver paramter (o.a. de typering ervan).

Die eigenschappen van de receiver parameter wist/weet ik wel direct, maar wa bedoelen ze juist met de syntactische elementen?

Ik vermoed dat je een beetje de syntax moet bespreken. bbeetje vage vraag. Ik zou de dingen uitleggen die je ervoor nodig hebt: pointers, records, receiver parameters, en inderdaad ook de extensies.
EDIT: zie pagina 160 en 161. Daar staan 2 punten: de extensies en de procedure velden binnen de datastructuren.

Een vraag waar ik niet uitkom:
Geef een duidelijke aanwijzing voor het al dan niet correct zijn van de volgende uitspraak:
"Het is aangewezen de creatie van nieuwe objecten via NEW te doen binnen de module/procedure waar de declaratie van het object voorkomt"

[Jerre]

Dat vroeg ik me ook al af, ik dacht misschien aan dat als je het in een procedure declareert het enkel geldt binnen die procedure, en dus minder geheugen ofzo zou innemen, en dus minder belastend voor het systeem, maar denk niet dat het dat is

Ik heb wel nog wat andere vraagjes:

Leg uit hoe objectoriëntatie de abstractiemogelijkheden in Oberon optimaliseert, en dit bv. in contrast met de klassieke procedurele of data abstractie.
=> bedoelen ze hierbij dat bij OO men meer datagericht gaat werken en dat er dus meer verborgen moet worden?

Horen er, naast de EBNF-syntax regels, ook nog semantische regels (dus niet vervat in de EBNF-syntax) waarop de compiler fouten kan genereren? Zo ja, geef een zo volledig mogelijk overzicht van deze elementen, enkel voor de declaratie van een procedure.
=> hiermee worden wellicht de uitvoeringsbesluiten bedoelt, maar welke zijn die voor de declaratie van een procedure?


Oberon heeft een gevarieerde woordenschat. Geef de syntax voor een "woord" op, en bespreek
alle mogelijke semantisch verschillende betekenissen ervan. Geef duidelijk weer waar
de semantiek van elk soort wordt vastgelegd, en welke instantie "verantwoordelijk" is voor
de betekenis; hoe lang geldt voor elke soort de levensduur?
=> bedoelen ze hier woorden zoals gepredefinieerd etc of variabelen of ...

thnx alvast

[Teun]

Dat vroeg ik me ook al af, ik dacht misschien aan dat als je het in een procedure declareert het enkel geldt binnen die procedure, en dus minder geheugen ofzo zou innemen, en dus minder belastend voor het systeem, maar denk niet dat het dat is

Ik heb wel nog wat andere vraagjes:

Leg uit hoe objectoriëntatie de abstractiemogelijkheden in Oberon optimaliseert, en dit bv. in contrast met de klassieke procedurele of data abstractie.
=> bedoelen ze hierbij dat bij OO men meer datagericht gaat werken en dat er dus meer verborgen moet worden?

Ik denk het wel. De bewerkingen op de data hangen nu echt 'vast' aan de data. Daarvoor moest je, om een bewerking op de data uit te voeren, een procedure oproepen en daaraan de data als parameter meegeven. Dit gaat nu in 1 keer door ptr^.procedure.

Horen er, naast de EBNF-syntax regels, ook nog semantische regels (dus niet vervat in de EBNF-syntax) waarop de compiler fouten kan genereren? Zo ja, geef een zo volledig mogelijk overzicht van deze elementen, enkel voor de declaratie van een procedure.
=> hiermee worden wellicht de uitvoeringsbesluiten bedoelt, maar welke zijn die voor de declaratie van een procedure?

Idd de uitvoringsbesluiten. Zoals daar zijn: de identifier moet in het begin en op het iend dezelfde zijn, de compatibiliteitseigenschappen moeten voldaan zijn, de zichtbaarheidsregels moeten vervuld zijn etc. Ook krijgen de gereserveerde woorden een seamntische betekenis.

Oberon heeft een gevarieerde woordenschat. Geef de syntax voor een "woord" op, en bespreek
alle mogelijke semantisch verschillende betekenissen ervan. Geef duidelijk weer waar
de semantiek van elk soort wordt vastgelegd, en welke instantie "verantwoordelijk" is voor
de betekenis; hoe lang geldt voor elke soort de levensduur?
=> bedoelen ze hier woorden zoals gepredefinieerd etc of variabelen of ...

gereserveerd/gepredefinieerd en gebruikersgedefinieerd
Variabelen zijn uiteindelijk gebruikersgedefinieerde woorden.

thnx alvast

np

[Jerre]

Oberon heeft een gevarieerde woordenschat. Geef de syntax voor een "woord" op, en bespreek
alle mogelijke semantisch verschillende betekenissen ervan. Geef duidelijk weer waar
de semantiek van elk soort wordt vastgelegd, en welke instantie "verantwoordelijk" is voor
de betekenis; hoe lang geldt voor elke soort de levensduur?
=> bedoelen ze hier woorden zoals gepredefinieerd etc of variabelen of ...

gereserveerd/gepredefinieerd en gebruikersgedefinieerd
Variabelen zijn uiteindelijk gebruikersgedefinieerde woorden.

thnx alvast

np

Dankuwel , nu bij die woorden ik bedoelde met variabelen etc eigenlijk (aangezien in de opgave de levensduur gevraagd wordt) dus variabelen die enkel leven zolang de procedure waarin ze gedeclareerd zijn geldt. Vandaar dat ik twijfel tussen die gereserveerde woorden etc en variabelen/constanten/...

[Teun]

Die levensduur slaat op de levensduur 'in de compiler'. De gebruikersgedefinieerde woorden worden bij het compileren in het geheugen geladen, maar worden na het compileren weer verwijderd uit de compiler. Ze gaan dus 'dood'.

[Jerre]

Wel daarom dat het dom zou zijn als dat de bedoeling van de vraag is
Want voor gereserveerd is de levensduur dan altijd en voor gepredefinieerd is dan zolang zelfde compiler gebruikt wordt.
Daarom dat ik denk dat variabelen etc bedoeld worden omdat dit expliciet in de les aan bod kwam

[Adelbert]

Golle vergeet ook nog wel een belangrijk punt gewonnen aan de OO-abstractie: extenties. Nu moet ge tenminste ni elke keer opnieuw beginne vanaf nul als ge toevallig een extra veldje nodig hebt, da's ook nog wel handig...

en volges mij bedoelt'm me woorde wel degelijk de gepredefinieerde, de gereserveerde en de gebruikergedefinieerde (mor dan ni noodzakelijk in die volgorde eh), en zo kome we weer tot de vaststelling dat'm die vraag weer een andere versie is van een andere veel voorkomende vraag deze laatste jaren.

[Jay Jay]

Een vraag waar ik niet uitkom:
Geef een duidelijke aanwijzing voor het al dan niet correct zijn van de volgende uitspraak:
"Het is aangewezen de creatie van nieuwe objecten via NEW te doen binnen de module/procedure waar de declaratie van het object voorkomt"

Ik zit met dezelfde vraag in de knoei, de enige stukjes info die (misschien) hiermee te maken hebben die ik gevonden heb :

- Verantwoordelijkheid van geheugenvooriening ligt in handen van programmeur en vereist dus discipline:
het zou dus aangewezen (maar zeker niet verplicht) zijn om de creatie van nieuwe objecten via NEW te doen binnen de module/procedure waar de declaratie van het object voorkomt, zodat je die NEW niet vergeet, omdat er anders 'rare dingen' kunnen gebeuren. (zie Slide 208, en cursus p.147 bovenaan).
(lijkt mij wel een vraag voor Arickx, aangezien het antwoord het woord 'discipline' bevat

- Anderzijds is het zo dat gealloceerde geheugenplaatsen gereserveerd blijven totdat Garbage Collector ze terug opruimt, en dit dus een beetje verspilling is, dus best zo min mogelijk NEW gebruiken.

Dus: Ik heb eigenlijk geen idee wat ik hierop moet antwoorden

[Adelbert]

- Verantwoordelijkheid van geheugenvooriening ligt in handen van programmeur en vereist dus discipline:
het zou dus aangewezen (maar zeker niet verplicht) zijn om de creatie van nieuwe objecten via NEW te doen binnen de module/procedure waar de declaratie van het object voorkomt, zodat je die NEW niet vergeet, omdat er anders 'rare dingen' kunnen gebeuren. (zie Slide 208, en cursus p.147 bovenaan).
(lijkt mij wel een vraag voor Arickx, aangezien het antwoord het woord 'discipline' bevat

- Anderzijds is het zo dat gealloceerde geheugenplaatsen gereserveerd blijven totdat Garbage Collector ze terug opruimt, en dit dus een beetje verspilling is, dus best zo min mogelijk NEW gebruiken.

Euhm, volges mij vraagt'm ni of da ge da moet doen of ni, want ge moet da sowieso doen (anders krijgt ge zo van die genante trap-vieuwers enz...) maar hij vraagt eerder of da ge da in de module moet doen waar het type enz gedeclareerd is of de module waarin we het object gaan gebruiken.
Nu, aangezien we het over een object hebben, lijkt het mij logisch dat we object georiënteerd zijn aan het programmeren en dus moeten we eerst een object aanmaken (via NEW dus) eer we er velden/methodes van kunnen oproepen (ook al staan die in een andere module gedeclareerd).
En dat geheugen volloopt, is niet echt zo'n probleem, de GC wordt automatisch opgeroepen als er een nieuwe dynamische locatie via NEW plaatsvindt en er blijkt geen plaats te zijn (lees maar na in Oberon.Report.Text)...
Dees is mijn mening natuurlijk maar.

[Jay Jay]

Ja, nu snap ik eindelijk wat hij met deze vraag bedoelt. Ja, dan is het idd vrij logisch dat je dat binnen de module doet waarin het object gebruikt wordt ipv binnen de object-module zelf.

Thx