WINAK

Bij het compileren geeft Oberon de voor mij tot nu toe onbekende foutmelding "280 duplicate fingerprint"
Dit is tevens de enige plaats waar errors gedefinieerd worden. Iemand een idee waarom alleen deze 3 lijnen worden gemeld of wat de fout will voorstellen? Google geeft bitter weinig informatie (lees: geen).

EDIT:
De reden waarom ik het op deze manier wou heeft veel de maken met overerving van basisprocedures die andere basisprocedures oproepen die ook overgeervd zijn. Even een tekening:



De groene pijlen geven de oproepen aan en de rode de returnvalues. Stel nu dat extended ProcB een error geeft. Deze wordt dan aan base ProcB gegeven, die op zijn beurt een fout geeft omdat de error niet van een type is dat hij kent. (de code hierboven moest dit oplossen, maar gaf een duplicat fingerprint). Door extended ProcA gewoon opnieuw te maken (dus zonder overerving) is het probleem dus vermeden.

De (nu minder dringende) vraag blijft echter nog altijd:
Wat zijn duplicate fingerprints en hoe geraak je er vanaf?

Err 280: duplicate fingerprint in module (implementation restriction)

Meer vind ik ni

Robbe wrote:


De groene pijlen geven de oproepen aan en de rode de returnvalues. Stel nu dat extended ProcB een error geeft. Deze wordt dan aan base ProcB gegeven, die op zijn beurt een fout geeft omdat de error niet van een type is dat hij kent. (de code hierboven moest dit oplossen, maar gaf een duplicat fingerprint). Door extended ProcA gewoon opnieuw te maken (dus zonder overerving) is het probleem dus vermeden.

De (nu minder dringende) vraag blijft echter nog altijd:
Wat zijn duplicate fingerprints en hoe geraak je er vanaf?

Ik snap niet goed wat ge wilt forceren met al uw pijlen en oproepen... Waarom zou je vanuit een base klasse een procedure uit een extended klasse willen oproepen? Een basisklasse zou normaalgezien niet mogen vertrouwen op een of andere specialiteit uit een extended klasse, omdat ge dan de compatibiliteit met andere extenties van dezelfde base klasse teniet dreigt te doen.

Maar kunt ge anders de volledige definitie van uw klassen, base en extended, eens posten?

Foundation wrote:Waarom zou je vanuit een base klasse een procedure uit een extended klasse willen oproepen?

Dat is het hem juist, ik wil dat niet, Oberon doet dat uit zichzelf. Zoals prof. Arickx mij verteld heeft, krijgt Oberon de base klasse, maar ziet die dat er een stukje bij is en neemt dan maar de procedure van de extende klasse. Ik moet nu wel vertellen dat dat gedoe van die pijlen deels gebaseerd is op wat ik denk dat er gebeurt (vooral het gedeelte van de returns).

Foundation wrote:Een basisklasse zou normaalgezien niet mogen vertrouwen op een of andere specialiteit uit een extended klasse, omdat ge dan de compatibiliteit met andere extenties van dezelfde base klasse teniet dreigt te doen.

Hebt gij ooit wel goe opgelet Joa?
Als ge ne lijst van basisklasses (bv. figuren) hebt, en daarin zitten circels en driehoeken, elk met hun specifieke paint()-methode. Op die lijst van figuren roept ge nen foreach (Figure x in lijst) op, me daarin:
x.paint();

Dan is het duidelijk WEL de bedoeling dat die gespecialiseerde functie opgeroepen wordt! Meer zelfs: het kan zijn dat er helemaal geen basisfunctie is!

Als ge toch wilt dat die basis-functie opgeroepen wordt, dan moet ge ofwel ze niet implementeren in de sub-klasse, ofwel in de subklasse super() (in java) of iets gelijkaardigs oproepen.
Maar als het de bedoeling is om dit voor een specifiek object te doen, dan denk ik eerder aan een design-fout

(en Joa: het versterken/zwakker maken van pre- en postcondities zorgen er wel voor dat u restricties op u objecten blijven kloppen, zoals ge ZOU moeten weten )

Aaah, ge wilt polymorfisme forceren... hoe dat juist ineen zat in Oberon weet'k niet meer...

Wat ik wou zeggen was: stel dat ge vanuit een methode in uw base klasse een functie wilt aanroepen die enkel in uw extended klasse zit, dan zijn er dingen mis... maar ik leidde niet onmiddellijk af dat het hier om een polymorfe functieaanroep ging.

Wat ge immers in de praktijk doet bij polymorfisme, is de methode van de Base klasse aanroepen (groene pijl naar base klasse zou ik schrijven...), waarna de virtual method table die in uw object zit dat inderdaad zal redirecten naar de implementatie die gedefinieerd is in de klassedefinitie van dat specifieke object.

Ge hebt trouwens overschot van gelijk wat dat pre en postcondities aanpassen betreft ( het Liskov Substitutieprincipe genoemd naar Barbara Liskov, ziet eens hoe goed ik heb opgelet! )

Maar in sé schreef ik niets fouts : een methode uit een basisklasse dient niet te vertrouwen op een 'specialiteit' (lees: extra functionaliteit, aangepaste pre en postcondities,... ) uit een of andere afgeleide klasse. In plaats daarvan moet het het met de pre en postcondities uit zijn eigen generieke basismethode doen.

Om terug een beetje op het topic te geraken:

"duplicate fingerprint" lijkt mij een error te zijn die met typechecking te maken heeft. Hoe zijn een "Toestel.XErrorR" en "Toestel.YErrorR" gedefinieerd? Wat is juist het verschil?

Als deze twee veldjes er in het geheugen hetzelfde uit komen te zien dan zou je inderdaad kunnen zeggen dat ze dezelfde "fingerprint" hebben. Het is mogelijk dat Oberon niet toelaat om meer dan 1 alias te creëren voor eenzelfde constructie (dunno really, te lang geleden). Als er later pointers naar records van die ene constructie worden gedefinieerd, kan het misschien zijn dat Oberon kwijt is waar elke pointer nu naar wijst.

Concreet: stel, een Toestel.XErrorR is van het type integer. Dan is XError* gedefinieerd als "pointer naar record met integer in". Als Toestel.YErrorR ook van type integer is , dan is YError* ook gedefinieerd als "pointer naar record met integer in". De twee zijn bottomline eigenlijk van hetzelfde type en zijn onderling inwisselbaar. Het lijkt mij dat Oberon over zoiets struikelt.

De oplossing kan dan zijn: in plaats van een XError en YError apart te definieren, maak een CoordError.

't Is maar een gokje, misschien kan ik meer zeggen als ik de klassedefinities volledig kan bekijken...

Dat vond ik dus raar: al die errors zijn gedefinieerd met Dus als het daaraan lag, zouden al die errors duplicate fingerprints moeten zijn.