[SE] Polymorfisme bij var records?

[cG`]

Uit den Arickx zenne cursus:

voorbeeld van een C++ class:

Code: Select all

class time

{

public:

time(); // constructor!

void set_time(int const, int const, int const);

void print_time_universal();

void print_time_standard();

vergelijking met Oberon:

Code: Select all

In de strikte zin noemen we dit in Oberon-2 jargon geen “echte klasse”, om de eenvoudige reden dat we steeds afgesproken hebben dat een object in Oberon-2 aangewezen moet worden via een pointer. Niets weerhoudt er ons echter van om bovenstaande klasse ook in Oberon-2 te gebruiken! Echter zal men geen polymorfisme kunnen toepassen op dergelijke constructie (waarom??)!

Hij heeft het dus over een variabele record als receiver te gebruiken in Oberon.
Het is toch mogelijk om een record "Class" te maken en dan als volgt een procedure te maken:
PROCEDURE (VAR receiver: Class) Test(getal: INTEGER)

Het is dan toch ook mogelijk om "Class" uit te breiden tot "ClassExt" en dan deze procedure te maken:
PROCEDURE (VAR receiver: ClassExt) Test(getal: INTEGER)

Dit werkt dus perfect, een super-call en type-guards ook, maar dit is dan toch geen polymorfisme... ?


Enlighten me!

[Shinta]

De verwoording is een beetje ambetant. In c++ kun je klassen creeeren waarnaar niet verwezen wordt met pointers.
Stel we hebben de klasse Class en de klasse ClassExt en stel de doen

Code: Select all

ClassExt ikbenuitgebreid;

Class ikBenInOberonOokUitgebreidMaarInCppNiet = ikbenuitgebreid;

Stel dat deze beiden de methode

Code: Select all

void ikBenEenMethode();

hebben en dat we zeggen

Code: Select all

ikBenInOberonOokUitgebreidMaarInCppNiet.ikBenEenMethode();

Dan wordt de methode van de basisklasse Class gekozen en dus niet polymorf die van de uitgebreide methode, dit komt doordat er slicing optreedt, alles van het uitgebreide gedeelte van die uitgebreide klasse wordt in de vuilbak gesmete en een nieuw object van de basisklasse wordt geinitialiseerd met de half-in-de-vuilbak-gesmeten klasse zodat je een basisklasse bekomt.

Als je nu pointers gebruikt in plaats van gewone objecten, dan wordt wel de juiste methode opgeroepen (net zoals in Oberon) en vindt polymorfisme wel plaats. Wat arickx bedoelt met die niet-polymorfisme constructie in Oberon snappek ok ni, mss in plaats van VAR receivers gewone receivers zonder var, da wetek ni meer .

[cG`]

Bedankt voor de reactie
Die uitleg over C++ is wsl iets te diepgaand voor wat we moeten kennen van OO in C++ dit jaar, mor dus toch bedankt

Ne receiver in Oberon moet normaalgezien ofwel ne pointer naar ne record of ne variabele record zijn dacht'k. Dus ja ik weet ook niet wat hij dan bedoelt..

[Robbe]

Oberon werkt op zowat dezelfde manier als C++ op het gebied van pointers en klassen(/records).

[Shinta]

Bedankt voor de reactie
Die uitleg over C++ is wsl iets te diepgaand voor wat we moeten kennen van OO in C++ dit jaar, mor dus toch bedankt

Ne receiver in Oberon moet normaalgezien ofwel ne pointer naar ne record of ne variabele record zijn dacht'k. Dus ja ik weet ook niet wat hij dan bedoelt..

mja idd, de uitleg is wat verwarrend want hij wekt de indruk dat je ook in oberon niet-pointer klassen kunt maken terwijl dit niet zo is.