| Oberon | |
|---|---|
| Kieliluokka | välttämätön , jäsennelty , modulaarinen |
| Esiintyi | 1986 |
| Tekijä | Niklaus Wirth |
| Tyyppijärjestelmä | staattinen , vahva |
| Vaikutettu | Modula-2 , Pascal |
| vaikutti | Active Oberon , Component Pascal , Go , Java [1] [2] , Modula-3 , Oberon-2 , Zonnon , Nim |
| Lisenssi | BSD |
| Verkkosivusto | projectoberon.com |
Oberon on Niklaus Wirthin suunnittelema korkean tason ohjelmointikieli ohjelmien suorittamiseen samannimisessä käyttöjärjestelmässä ja jonka ovat kirjoittaneet Niklaus Wirth ja Jürg Gutknecht .
Oberon-ohjelmointikielellä kirjoitetut ohjelmat vaativat jonkinlaista ajonaikaista tukea - ne tarvitsevat dynaamisen latausohjelman ja keskitetysti suoritettavan automaattisen roskakeräimen, jota varten Oberon-ohjelmat tarvitsevat erityisen käyttöympäristön. Tavallinen tapa toteuttaa se on lisätä järjestelmään joukko kirjastoja, jotka toteuttavat tarvittavat komponentit, vaikka yleisesti ottaen käyttöympäristö ei välttämättä tarvitse erillistä käyttöjärjestelmää: se voi itsekin olla käyttöjärjestelmä. Nämä ovat Native Oberon - järjestelmät alkuperäiselle Oberonille ja A2 Active Oberonille . Tällä hetkellä Java Virtual Machine -tavukoodille on olemassa Oberon - kääntäjät ja .NET - virtuaalikoneen CLI .
Käyttöjärjestelmät ja -ympäristöt ohjelmien suorittamiseen alkuperäisestä Oberon-järjestelmästä kehittyneillä Oberon-perheen kielillä ovat ETH Oberon, BlackBox Component Builder , WinOberon , A2 jne.
Oberon-0, Oberon-X ja muut projektit kehitettiin Oberonin [3] pohjalta . Oberonin yksinkertaisuus ja alkuperäisen toteutuksen lähdekoodien saatavuus helpottavat sen mukauttamista erityisiin ongelmaluokkiin. Mutta kaikki nämä Oberonit ovat hyvin lähellä toisiaan, koska alkuperäinen Oberon on hyvin yksinkertainen.
Oberon-ohjelmointikielen loi Niklaus Wirth vuonna 1988 ohjelmointikielten Modula-2 , Pascal ja Algol-60 perusteella [4] .
Wirthin mukaan alun perin he halusivat kirjoittaa järjestelmän suoraan moduuliin, mutta he tulivat siihen tulokseen, että sitä oli jalostettava ja vähennettävä, mikä johti Oberonin ilmestymiseen [5] .
Niklaus Wirthin ja Jürg Gutknechtin vuosina 1986-1989 [6] toteuttaman projektin ( Eng. Project Oberon ) tavoitteena oli luoda tyhjästä näkyvä ja luotettava käyttöjärjestelmä yhden käyttäjän työasemalle.
Tämän projektin toteuttamiseksi Niklaus Wirth suunnitteli vuonna 1988 yleiskäyttöisen korkean tason ohjelmointikielen, jota kutsutaan myös nimellä Oberon [7] .
Vuonna 1989 Oberonin ensimmäinen toteutus NS32000-prosessoriperheelle julkaistiin ETH Zurichissa (ETH) . Se luotiin osaksi Oberonin toimintaympäristöä. Tämä kääntäjä vaatii alle 50 KB muistia, koostuu 6 moduulista, joiden kokonaisvolyymi on noin 4000 riviä, ja kääntää itsensä 15 sekunnissa tietokoneella, jossa on NS32532-prosessori (kellotaajuus - 25 MHz).
On yksinkertaisesti mahdotonta kiittää kaikkia niitä, jotka tavalla tai toisella ruokkivat ideoillaan sitä, mitä nyt kutsutaan Oberoniksi. Suurin osa ideoista tuli käyttämällä ja oppimalla olemassa olevia kieliä, kuten Modula-2, Ada, Smalltalk ja Cedar, jotka usein varoittivat meitä siitä, mitä ei pidä tehdä.Niklaus Wirth [5]
Kieli säilytti Modula -syntaksin pääpiirteet ja oli objektilaajennus . Tämä teki mahdolliseksi luopua muunnelmien tietueiden mekanismista Moduulit, jotka ovat vetäytyminen alkuperäisestä vahvasta staattisesta kirjoittamisesta , mikä mahdollisti automaattisen muistinhallintamekanismin käyttöönoton - roskien kerääminen : mahdollisuus vapauttaa dynaamisesti varattu muisti erityisellä operaattorilla jätettiin pois kielestä, ja sen sijaan itse ajonaika sisältää moduulin A, joka palauttaa käyttämättömän muistin järjestelmään. Automaattinen muistinhallinta on keino parantaa dynaamisten tietorakenteiden ohjelmien luotettavuutta, koska se eliminoi inhimilliset virheet, jotka ovat tyypillisiä esimerkiksi kielille, kuten C / C++ .
Käännöksen suurimman luotettavuuden ja suorituskyvyn saavuttamiseksi tehtiin kielen merkittävä yksinkertaistaminen poistamalla tarpeettomiksi pidetyt (muiden kielten kehittämisestä, toteutuksesta ja käytöstä saatujen kokemusten perusteella) ominaisuudet, jotka joko vaikeuttivat kääntäjää ilman riittävää perustetta. suorituskyvyn suhteen tai ne olivat riittävän monimutkaisia toimitettavaksi ulkoisiin kirjastoihin tai eivät ole yhteensopivia modulaarisuuden ja automaattisten muistinhallintamekanismien kanssa: muunnelmatietueet , luetellut tyypit , aluetyypit , yleisjoukot , etumerkitön kokonaislukutyyppi, paikalliset moduulit, määritelmämoduulit, vienti listat, operaattori, entinen versio with-lauseesta, erityinen syntaksi pääohjelman määrittämiseen. Moduuli 2:ssa saatavilla olevat alkeelliset keinot rinnakkaisohjelmoinnin tukemiseksi eivät tulleet kieleen, koska se palveli yhden käyttäjän käyttöjärjestelmää. Poikkeuskäsittelystä on luovuttu yksinkertaisuuden vuoksi .
Taulujen kuvausta on yksinkertaistettu ( taulukkoindeksit voivat olla vain kokonaislukuja ja aina alkaa nollasta, kuten C-kieli), osoittimien käyttöä on rajoitettu - osoittimia voi olla vain tietueissa ja taulukoissa, tuonnissa on määritetty vain tuotu moduuli luettelot ja tuontinimiä käytettäessä pakollinen kelpoisuus (viejämoduulin nimen selkeä maininta). Artikkelissa "From Modula to Oberon" [5] Wirth selitti yksityiskohtaisesti jokaisen elementin poistamisen syyt.
"Riittävästä vähimmäismäärästä" johtuen menetelmiä (tyyppiin liittyviä proseduureja ja toimintoja) ei sisällytetty kieleen eksplisiittisenä syntaktisena käsitteenä, koska tämä mekanismi yleisimmässä muodossaan on helppo mallintaa luomalla proseduurityyppisiä kenttiä. objektit (tietueet Oberon-kielellä) ja osoittamalla niille menetelmiä vastaavat menettelyt. Siten Oberon tukee olio-ohjelmointia minimaalisilla keinoilla koodin käännösprosessin yksinkertaistamiseksi ja prosessin nopeuttamiseksi.
Tehtyjen muutosten ansiosta Oberonista on tullut syntaktisesti yksinkertaisempi. Sen syntaksin kuvaus mahtuu yhdelle sivulle, kielen täydellinen kuvaus kestää noin 20 sivua, mikä on puolet Modula-2 :n kuvauksesta . Oberon on ellei minimaalinen, niin ainakin yksi pienimmistä universaaleista korkean tason ohjelmointikielistä.
Einsteinin lausunto valittiin alkuperäisen Oberonin kuvauksen epigrafiksi: "Tee siitä mahdollisimman yksinkertainen, mutta ei yksinkertaisempi . "
Määritelty seuraavissa RBNF- ehdotuksissa [8] :
Moduuli = moduulin tunnus ";" [ ImportList ] Viimeksi ilmoitettu [ BEGIN Viimeiset lausunnot ] END id "." . ImportList = TUO [ id ":=" ] id { "," [ id ":=" ] id } ";" . LastDeclared = { const { DisculdedConst ";" } | Tyyppi { typedeclaration ";" } | Var { dolderVar ";" }} { Julistettuproc ";" | ForwardDeclared ";" }. JulistetunConst = identDef "=" ConsertExpression . Typedeclare = identdef "=" tyyppi . DECTIARDVAR = ListIdentifier ":" Tyyppi . DeclaredProc = PROCEDURE [ Vastaanotin ] IdentDef [ FormalParam ] ";" Viimeksi ilmoitettu [ BEGIN Viimeiset lausunnot ] END Ident . ForwardDeclare = PROCEDURE "^" [ Vastaanotin ] IdentDef [ FormalParam ]. FormalParam = "(" [ FP Section { ";" FP Section }] ")" [ ":" SpecIdent ]. Scentfp = [ var ] id { "," id } ":" tyyppi . Vastaanotin = "(" [ var ] id ":" id ")" . Tyyppi = Qualid | ARRAY [ ConstExpression { "," ConstExpression }] OF Type | Tallenna [ "(" Qualtive ")" ] FieldList { ";" FieldList } END | OSOITIN Tyyppi | _ Menettely [ FormalParam ]. FieldList = [ ListILIMIt ":" Tyyppi ]. Jälkioperaattorit = operaattori { ";" }-operaattori . Operaattori = [ merkintä ": =" lauseke | Merkintä [ "(" [ ListExpression ] ")" ] | JOS Lausu THEN Lauseke Seq { ELSIF Laus THEN Lause Seq } [ ELSE Lause Seq ] END | Tapausvaihtoehdon ilmaisu { " | " Variant } [ else lausekeq ] loppu | Kun taas Express do -lausunto Seq End | Toista lausekeq , kunnes lauseke | Silmukan jälkikäsittelyt päättyvät | Guard DO -lausekkeella Seq End | POISTU | RETURN [ Express ] ]. Optio = [ Option Labels { "," Option Labels } ":" StatementLast ]. VariantLabels = ConstExpression [ ".." ConstExpression ]. Guard = Specid ":" Specid . Consertekspression = Express . Lauseke = SimpleExpression [ Relation SimpleExpression ]. Simpleexpression = [ "+" | "-" ] termi { operslog termi }. Term \ U003D Kerroin { OPERMUL -kerroin } . Kerroin = merkintä [ "(" [ ListExpression ] ")" ] | numero | symboli | merkkijono | NIL | Aseta | "(" Lauseke ")" | "~" Kerroin . Set = "{" [ elementti { "," elementti }] "}" . Elementti = Express [ ".." Express ]. Suhde = "=" | "#" | "<" | "<=" | ">" | "> =" | Sisään | On . Operslog = "+" | "-" | Tai . Obuln = "*" | "/" | DIV | MOD | "&" . Nimitys = Tarkenne { "." identt | "[" ListExpression "]" | "^" | "(" QualIdent ")" }. ListExpr = Lauseke { "," Express }. ListIdent = IdentDef { "," IdentDef }. QualID = [ tunniste "." ] ID . IdentDef = identt [ "*" | "-" ].Oberon-ohjelma on joukko moduuleja. Yleisesti ottaen moduuli näyttää tältä:
MODUULI Nimi ; IMPORT ImportList ; määritelmät ; Aloita lausunnot LOPPU NIMI .Tuontiluettelo määrittää, mistä moduuleista ulkoiset nimet tuodaan . Määritelmät sisältävät tyyppien, menettelyjen, funktioiden, muuttujien ja vakioiden määritelmiä. Tässä tapauksessa tämä moduuli vie tähdellä merkittyjen nimien määritelmät, eli ne näkyvät muille tämän moduulin tuoville moduuleille. Oberon-2:ssa on myös mahdollista merkitä nimet miinusmerkillä, jolloin ne viedään vain luku -tilassa.
Moduulin runko suoritetaan, kun se ladataan. Component Pascalissa moduulin runkoon (osaan BEGIN..END) on nyt mahdollista lisätä osio CLOSE:
BEGIN CLOSE - lauseet END- lauseet Nimi .Tässä ja välissä olevat käskyt suoritetaan, kun moduuli ladataan, ja käskyt välissä ja BEGINsuoritetaan , kun se puretaan muistista. Tällainen laajennus on havaittu hyödylliseksi komponenttiohjelmille, jotka lataavat ja purkavat moduuleja dynaamisesti . CLOSECLOSEEND
Ohjelmoijan luomat tietotyypit on rajoitettu seuraaviin joukkoihin: taulukkotyypit ARRAY , tietuetyypit RECORD , proseduurityypit PROCEDURE , osoitintyypit POINTER . Osoitin voidaan ilmoittaa vain taulukolle tai tietueelle.
Ohjelman sisäisen osan syntaksi on melko perinteinen ja yksinkertainen. Kieli tukee perinteistä konstruktiojoukkoa: ehdollinen operaattori IF, valintaoperaattori CASE, syklit (ehdolla - WHILE, jälkiehdolla REPEAT..UNTIL, ehdoton - LOOP). Moduuli-2:n tapaan tunnisteissa erotetaan isot ja pienet kirjaimet, kaikki varatut sanat kirjoitetaan isoilla kirjaimilla. Kaikki kielirakenteet, paitsi silmukka REPEAT..UNTIL, päättyvät avainsanaan ENDja sallivat pesimisen useissa lauseissa käyttämättä yhdistelmälausetta BEGIN..END. Luonnollisesti, kuten moduulissa 2, ei ole ehdottomia hyppyjä.
Objektikeskeistä ohjelmointiparadigmaa tukee tietueen laajennusmekanismi (kielellä ei ole erillistä avainsanaa luokkien kuvaamiseen, kuten "luokka" tai "objekti", katsotaan, että tavallinen "tietuetyypin" käsite on melko riittävä). Pohjimmiltaan jokainen tietuetyyppi on kuvaus luokasta, ja tietueen kentät ovat luokan datajäseniä.
Alkuperäisessä Oberonissa ei ole lainkaan menetelmiä ( luokkaan liittyviä proseduureja ja funktioita ). Metodimekanismia voidaan käyttää ilmoittamalla tietueessa proseduurityyppisiä kenttiä, joille määritetään erityiset proseduurit, kun luokan esiintymä luodaan. Tällaisten proseduurien kutsuminen tapahtuu perinteisellä tietuekenttään pääsyllä, oletusarvoisesti proseduuri ei tiedä luokan esiintymää, jolle se on kutsuttu (ei ole samanlaista mekanismia thisC ++:ssa tai Javassa), ja jos tieto on välttämätöntä, viittaus ilmentymään on välitettävä eksplisiittisesti (esimerkiksi parametrin kautta ). Selkeästi kuvattujen menetelmien puute oli yksi alkuperäisen Oberonin ominaisuuksista, mikä herätti kritiikkiä perinteisiin hybridikieliin tottuneiden ohjelmoijien keskuudessa. Toisaalta Oberonin ehdottaman mekanismin avulla voit toteuttaa kaiken, mikä voidaan toteuttaa perinteisillä kielillä menetelmillä, ja vielä enemmän - Oberonissa jokaisella luokan esiintymällä voi olla oma versio menetelmästä ( proseduurityyppisen kentän arvo), kun taas kuvattaessa menetelmiä osana luokkaa, kaikki esiintymät toimivat yhdellä menetelmävariantilla. Oberon 2:ssa menetelmiä otettiin edelleen käyttöön. Menetelmät on kuvattu tietuetyypistä erillään ja osoittavat tyypin, johon ne liittyvät.
Uusi tietuetyyppi voidaan ilmoittaa olemassa olevan tietueen jatkeeksi. Tässä tapauksessa laajennettava tyyppi määritetään merkinnän kuvauksessa suluissa avainsanan jälkeen RECORD. Laajennettu tyyppi vastaanottaa automaattisesti kaikki laajennetun tyypin kentät ja (Oberon 2:ssa) liitetään kaikkiin laajennettuun tyyppiin liittyviin toimenpiteisiin. Uuteen tyyppiin liittyvillä proseduureilla voi olla sama allekirjoitus kuin laajennettavaan tyyppiin liittyvillä proseduureilla - tämä varmistaa, että johdettujen tyyppien menetelmät ohitetaan. Komponentti Pascalissa , jotta periytymishierarkioiden johdonmukaisuuden täydellinen staattinen hallinta (ja siten alkuperäisen Oberonin erottaneen staattisen kirjoitusperiaatteen palauttaminen ) saataisiin aikaan, tietueita ei voi laajentaa oletusarvoisesti eikä menetelmiä voida ohittaa. Erityisesti käyttöön otettuja avainsanoja käytetään tietueen laajentamisen ja menetelmien ohituksen ohjaamiseen EXTENSIBLE, ABSTRACT, LIMITED, EMPTY. Tässä tapauksessa uudet menetelmät on merkittävä avainsanalla NEW(vrt. uusien muuttujien pakollinen määritelmä).
Oberon on suunnattu komponenttikeskeiseen ohjelmistokehitykseen [9] . Kapselointia tuetaan yksinomaan moduulitasolla - kaikki moduulin sisällä ilmoitetut tyypit ovat ehdottomasti läpinäkyviä toisiinsa. Muista moduuleista on saatavana sitä, mitä määritelmässä on ilmoitettu vietäväksi.
Polymorfismi saadaan menetelmamekanismi (molemmat Oberonin menettelytapat ja menetelmät Oberon-2: ssa käyttäytyvät virtuaalina useimpien hybridiobjektikoteloitujen kielten terminologiassa), samoin kuin laajennettu rakenteella, jonka avulla voit suorittaa eri ryhmien ryhmät lausekkeita riippuen siitä, mihin laajennetuista tyypeistä sen argumentti kuuluu.
Kielessä ei ole erityistä rakentajamekanismia. Suositeltava menetelmä objektien luomiseen ja alustamiseen on moduulien ja proseduurien generointi (perinteisen OOP-terminologian tehdas).
Tämän tekniikan ohjelma on joukko suhteellisen itsenäisiä komponentteja (tässä tapauksessa moduuleja), joilla on ulkopuolelta piilotettu sisäinen rakenne ja selkeästi määritelty käyttöliittymä. Moduulit voidaan ladata ja purkaa dynaamisesti ohjelman ollessa käynnissä, järjestelmä tarjoaa edistyneitä ajonaikaisia tyyppitarkistustyökaluja, joiden avulla voit kirjoittaa yleisiä tietojenkäsittelyalgoritmeja, jotka eivät riipu näiden tietojen tietystä tyypeistä (esimerkiksi kirjasto DBMS:n kanssa työskentely voi tarjota menetelmiä, jotka kirjoittavat kyselyn tuloksen tietokannasta mielivaltaisen rakenteen tietueeseen, jos tämän tietueen kenttien joukko ja tyypit vastaavat tietokannan kenttien joukkoa ja tyyppejä).
Komponenttiparadigmassa sitä pidetään valitettavana arkkitehtonisen päätöksen, joka liittyy toisessa komponentissa ilmoitetuista tyypeistä esitetyistä tyypeistä, koska tämä johtaa ilmiöön, joka tunnetaan nimellä ”perustyyppinen haureus” - sen jälkeen kun suuri joukko johdettuja tyyppejä on johdettu Perustyyppi (ja jotkut niistä voivat jopa olla tuntemattomia perustyypin kehittäjälle), mahdolliset muutokset perustyypin toteutuksessa ovat erittäin riskialttiita, koska ne voivat vaikuttaa jälkeläisiin arvaamattomalla tavalla.
On tiedossa, että yksi oliokeskeisen ohjelmoinnin käytön ongelmista järjestelmäohjelmoinnissa on tarve olla pienten luokkien ryhmiä, jotka voivat olla vuorovaikutuksessa ilman ylimääräistä yleiskustannuksia. Oberonilla ei ole tätä ongelmaa - kaikki yhdessä moduulissa määritellyt tyypit näkevät toisiaan, ja tämä ei aiheuta luotettavuusongelmia, koska moduulia kehitetään edelleen, testataan ja ylläpidetään kokonaisuutena.
Tyypillinen Oberonissa kehitetty järjestelmä on joukko moduuleja, joilla on menettelytapoja, joiden kautta moduulit vaihtavat tietoja, mukaan lukien objektit. Samanaikaisesti kaikki kapselointityökalut toimivat vain moduulien välisessä vuorovaikutuksessa, mikä tekee järjestelmän ohjelmoinnista käyttämällä kohteita.
Olio-ohjelmointiOlioohjelmointityökalut tulkitaan Oberonissa moduulijärjestelmän tietueiden kanssa työskentelyn työkalujen luonnolliseksi kehitykseksi, tarkemmin sanottuna tekniseksi työkalupakkiksi tietyn arkkitehtonisen ongelman ratkaisemiseksi: tehokkaan "työnjaon" varmistamiseksi eri moduulien välillä työskennellessään. dynaamisilla tyypeillä ja tietorakenteilla: esimerkiksi luettelossa olevien osoittimien kanssa työskentely voidaan piilottaa (yhdessä vastaavien kenttien kanssa) yhteen moduuliin ja luettelon elementtien määrittely ja työskentely tietyn "täytön" kanssa voidaan määrittää toiseen moduuliin. (tai useammin muita). Tässä mielessä Oberonin olioohjelmointitekniikka on alisteinen modulaarisuuden käsitteeseen: tässä se on pikemminkin väline tietojen kuvaamiseen kuin sovellusarkkitehtuurin rakentaminen kokonaisuutena.
Wirthin mukaan [10] Java -kielen kehittäjät useita vuosia ennen sen luomista "tutkivat Oberonin lähdekoodeja ja erityisesti Oberonin roskienkeräilijöiden lähdekoodeja. Sitten he sekoittivat Oberonin C -syntaksin kanssa ja kutsuivat sitä Javaksi. " Vaikka suullisesta esityksestä ei voi vaatia ehdotonta sanatarkkuutta, Oberonin ja Javan ideologioiden kiistaton samankaltaisuus (halu minimalismiin ja vahvaan konekirjoitukseen, moniperinnön rajoitus, automaattinen muistinhallinta) viittaa joka tapauksessa siihen, että Tietty yksimielisyys siitä, mitkä työkalut muodostavat nykyaikaisen yleiskäyttöisen ohjelmointikielen ydin. Jos minimalismi kuitenkin pysyy Oberonin ja sen suorien seuraajien eturintamassa, Java-kehittäjät ovat valinneet kielen ominaisuuksien laajan kehittämisen.
Itse Oberonin kielen perhe sisältää myös Oberon-07 , Oberon-2 , komponentti Pascal ( komponentti Pascal ), Active Oberon , OberonScript jne.
Oberonin alkuperäinen versio ("klassinen Oberon") on tiiviin, siinä on vähiten avainsanoja ja syntaktisia rakenteita. Sitä käytettiin perustana luotiin kieliperhe, joista jokainen laajentaa klassista johonkin suuntaan tai eroaa siitä joissakin yksityiskohdissa.
Vuonna 1992 Niklaus Wirth ja hänen opiskelijansa Hanspeter Mössenböck ovat nykyään yliopiston professoreita. Johannes Kepler Linzissä - julkaisi kuvauksen Oberonin laajennetusta versiosta nimeltä Oberon-2 . Hän on hienostunut versio klassisesta Oberonista. Oberon 2:een tehdyt lisäykset, jotka on tehty erittäin säästeliäästi, ovat seuraavat:
Kielen laajenemisesta huolimatta Oberon-2:n syntaksin muodollisen kuvauksen volyymi on pienempi kuin klassisen Oberonin syntaksikuvauksen optimoinnin vuoksi. Oberon-2: lle on olemassa optimoiva kääntäjä XDS [13] ; on myös kääntäjä [14] Java - tavukoodiin .
ETH Oberon , jonka toteutukset ovat saatavilla useille laskenta-alustoille.
Oberon SA on versio Oberon-kielestä, jonka N. Wirth on kehittänyt miehittämättömässä helikopterissa käytettävälle Strong-ARM-prosessorille .
Oberon SA:n kehittämisestä saatujen kokemusten perusteella N. Wirth valmisteli vuonna 2007 muutoksia ja lisäyksiä klassiseen Oberoniin [15] [16] , jotta strukturoidun ohjelmoinnin tuki olisi tiukempaa kuin esimerkiksi Oberon-2:ssa tai Component Pascalissa. Kielen uusi versio nimettiin Oberon-07 [17] . "Oberonin ohjelmointikieli, versio 1.11.2008" on käännetty venäjäksi [18] . Mutta olio-ohjelmoinnin tuen osalta Oberon-07-kieli ei seuraa Oberon-2:ta, vaan jatkaa klassisen Oberonin minimalistista linjaa, mukaan lukien tietuetyyppiin liittyvien toimenpiteiden tuen puute.
Oberon-07 :llä on seuraavat tärkeimmät erot klassiseen Oberoniin:
Australialainen yritys CFB Software (Brisbane) Queenslandin yliopistossa on kehittänyt Astrobe IDE :n [21] Oberon-07-kielelle NXP (Philips) ARM7-mikro-ohjaimille sekä Oberon-07-kielen syntaksikaaviot [22] . ohjenuorana Oberon-07:n ohjelmien tyylille [23] .
Heti vuonna 1992 ilmestymisensä jälkeen Oberon-2:ta pidettiin ehdokkaana kielistandardin rooliin (Oakwood Conference, Croydon, 1993), mutta käytännön kokemus suurten ohjelmistojärjestelmien luomisesta paljasti innovaatioiden heikkouksia ja haluttavuutta. lisätarkennuksia (joka jälleen kerran korostaa Wirthin osoittaman konservatiivisuuden viisautta klassisen Oberonin määrittelyssä). Nämä parannukset tehtiin Oberon-2:n muunnelmassa, nimeltään Component Pascal , ja julkaisi vuonna 1999 Oberon microsystems [24] , jonka Wirthin opiskelijat perustivat vuonna 1992 (Wirthista tuli hallituksen jäsen). Kuten siirtymisessä Oberonista Oberon-2:een, näitä parannuksia tehdään säästeliäästi [25] . Erityisesti kieli tukee nyt täysin komponenttilähtöistä ohjelmointimenetelmää . Viimeisen seikan ansiosta Component Pascal on tällä hetkellä ilmeisesti täydellisin klassisen Oberonin suorista jälkeläisistä. Se voidaan kuitenkin pelkistää alkuperäistä Oberonia vastaavaksi osajoukoksi myös toiseksi täysimittaiseksi minimalistiseksi osajoukoksi, jossa periytyminen ja menetelmän ohittaminen ovat sallittuja vain puhtaasti rajapintatyypeille ja -menetelmille (määritetty ABSTRACT-attribuutilla). Tämä seikka paljastaa Oberon-2:n jonkin verran keskitason luonteen.
Komponentti Pascal lisää ominaisuuksia, joiden avulla kehittäjä voi hallita täysin vientityypin laajennusta ja menetelmän ohittamista (EXTENSIBLE, ABSTRACT, NEW, EMPTY attribuutit sekä mahdollisuus rajoitettuun "vain toteutus" -menetelmän vientiin). Lisätty moduulirungon täydennyslohko (CLOSE-avainsana) ja ennalta määritetty tyhjä FINALIZE-menetelmä. Perus (alkeis)tyyppien järjestelmä on linjassa Java-tyyppien kanssa. Implisiittinen merkkijonotyyppi on otettu käyttöön. Oberon Microsystems, joka määritteli Component Pascalin , julkaisi myös BlackBox Component Frameworkin ja visuaalisen ohjelmointiympäristön BlackBox Component Builder [26] , kooltaan pieni ja resursseja vaatimaton ja joka on rakennettu kokonaan Component Pascalille.
Myöhemmin BlackBox-kääntäjä rakennettiin Denia cross-platform -ohjelmointiympäristöön , erityisesti JBed -reaaliaikaiseen käyttöjärjestelmään , kirjoitettu kokonaan Component Pascalilla.
Näitä kieliä, joilla on jo hyvä syy, voidaan kutsua ei oberonin laajennuksiksi tai versioiksi, vaan itsenäisiksi kieliksi. He laajensivat merkittävästi syntaksia, esittelivät rakenteita klassisten "ominaisuuksien" (ominaisuuden) kuvaamiseksi luku-/kirjoitusohjauksella, numeeriset tyypit, joilla oli määrätty koko bitteinä. Esitteli Aktiivisten objektien tuen, joka vaihtaa viestejä RBNF -kuvauksen määrittelemässä muodossa, poikkeuskäsittely [27] .