| Oberon | |
|---|---|
| Nyelvóra | kötelező , strukturált , moduláris |
| Megjelent | 1986 |
| Szerző | Niklaus Wirth |
| Típusrendszer | statikus , erős |
| Befolyásolva | Modula-2 , Pascal |
| befolyásolta | Active Oberon , Component Pascal , Go , Java [1] [2] , Modula-3 , Oberon-2 , Zonnon , Nim |
| Engedély | BSD |
| Weboldal | projectoberon.com |
Az Oberon egy Niklaus Wirth által az azonos nevű operációs rendszeren történő programok végrehajtására tervezett magas szintű programozási nyelv , amelynek szerzői Niklaus Wirth és Jürg Gutknecht .
Az Oberon programozási nyelven írt programok valamilyen futásidejű támogatást igényelnek - dinamikus betöltőre és központilag végrehajtott automatikus szemétgyűjtőre van szükség, amihez az Oberon programoknak speciális működési környezetre van szükségük. Megvalósításának szokásos módja az, hogy a rendszerhez a szükséges komponenseket megvalósító könyvtárak halmazát adjuk, bár általában az operációs környezet nem feltétlenül igényel külön operációs rendszert: maga is lehet operációs rendszer. Ezek a Native Oberon rendszerek az eredeti Oberonhoz és az A2 az Active Oberonhoz . Jelenleg Oberon fordítók vannak a Java Virtual Machine bájtkódhoz és egy CLI a .NET Virtual Machine számára .
Az eredeti Oberon rendszerből kifejlődött Oberon család nyelvein a programok végrehajtására szolgáló operációs rendszerek és környezetek az ETH Oberon, a BlackBox Component Builder , a WinOberon , az A2 stb.
Az Oberon-0, Oberon-X és más projektek az Oberon [3] alapján készültek . Az Oberon egyszerűsége és az eredeti megvalósítás forráskódjainak elérhetősége megkönnyíti a speciális problémaosztályokhoz való adaptálást. De ezek az Oberonok nagyon közel állnak egymáshoz, mivel az eredeti Oberon nagyon egyszerű.
Az Oberon programozási nyelvet Niklaus Wirth hozta létre 1988-ban a Modula-2 , Pascal és Algol-60 [4] programozási nyelvek alapján .
Wirth szerint kezdetben közvetlenül a Modulra akarták írni a rendszert, de arra a következtetésre jutottak, hogy finomítani és redukálni kell, ami az Oberon megjelenéséhez vezetett [5] .
Niklaus Wirth és Jürg Gutknecht 1986-1989- es projektjének ( Eng. Project Oberon ) [6] célja az volt, hogy a semmiből egy látható és megbízható operációs rendszert hozzanak létre egy egyfelhasználós munkaállomások számára.
Ennek a projektnek a megvalósítására Niklaus Wirth 1988-ban egy általános célú, magas szintű programozási nyelvet tervezett, amelyet Oberonnak is neveztek [7] .
1989-ben az ETH Zürichben (ETH) adták ki az Oberon első implementációját az NS32000 processzorcsaládhoz . Az Oberon működési környezet összetevőjeként jött létre. Ez a fordító kevesebb, mint 50 KB memóriát igényel, 6 modulból áll, összesen körülbelül 4000 soros térfogattal, és 15 másodperc alatt fordítja le magát egy NS32532 processzorral rendelkező számítógépen (órajel frekvencia - 25 MHz).
Egyszerűen lehetetlen köszönetet mondani mindazoknak, akik így vagy úgy ötleteikkel táplálták a ma Oberon nevű várost. A legtöbb ötlet a meglévő nyelvek, például a Modula-2, az Ada, a Smalltalk és a Cedar használatából és tanulásából származott, amelyek gyakran figyelmeztettek minket, hogy mit ne tegyünk.Niklaus Wirth [5]
A nyelv megtartotta a Modula szintaxis főbb jellemzőit, és objektumkiterjesztés volt . Ez lehetővé tette a variáns rekordok Modulok mechanizmusának elhagyását, amelyek visszavonulnak az eredeti erős statikus gépeléstől , ami lehetővé tette egy automatikus memóriakezelési mechanizmus bevezetését - szemétgyűjtés : a dinamikusan lefoglalt memória felszabadításának lehetősége egy speciális operátor segítségével ki lett zárva a nyelvből, helyette maga a futási környezet tartalmaz egy A modult, amely visszaadja a fel nem használt memóriát a rendszernek. Az automatikus memóriakezelés a dinamikus adatstruktúrákkal rendelkező programok megbízhatóságának javításának eszköze, mivel kiküszöböli az emberi hibákat, amelyek például olyan nyelvekre jellemzőek, mint a C / C++ .
A fordítás legnagyobb megbízhatóságának és teljesítményének elérése érdekében a nyelv jelentős egyszerűsítését végezték el a szükségtelennek ítélt (más nyelvek fejlesztése, megvalósítása és használata tapasztalatai alapján) jellemzők kiiktatásával, vagy kellő indoklás nélkül bonyolították a fordítót. teljesítmény szempontjából, vagy elég összetettek ahhoz, hogy külső könyvtárakba szállítsák, vagy nem kompatibilisek a modularitás és az automatikus memóriakezelési mechanizmusokkal: változat rekordok , felsorolt típusok , tartománytípusok , általános halmazok , előjel nélküli egész típus, helyi modulok, definíciós modulok, export listák, operátor a with utasítás korábbi verziójához, speciális szintaxis a főprogram meghatározásához. A Modul-2-ben rendelkezésre álló kezdetleges párhuzamos programozási támogatási eszközök nem kerültek be a nyelvbe, mivel egyfelhasználós operációs rendszert szolgáltak ki. A kivételkezelést az egyszerűség kedvéért elhagytuk .
A tömbök leírása leegyszerűsödött (a tömb indexei csak egész számok lehetnek és mindig nulláról indulhatnak, mint a C nyelv), a pointerek használata korlátozott - mutatók csak rekordokon és tömbökön létezhetnek, az importnál csak az importált modul van megadva. listák, importált nevek használata esetén pedig kötelező minősítés (az exportőr modul nevének kifejezett feltüntetése). A "From Modula to Oberon" [5] cikkében Wirth részletesen kifejtette az egyes elemek eltávolításának okait.
Az „elegendő minimum” okán a metódusok (egy típushoz tartozó eljárások és funkciók) nem kerültek bele a nyelvbe, mint kifejezett szintaktikai fogalom, mivel ez a mechanizmus a legáltalánosabb formájában könnyen modellezhető úgy, hogy procedurális típusú mezőket hozunk létre a nyelvben. objektumok (Oberon nyelvű rekordok).és a metódusoknak megfelelő eljárások hozzárendelése. Így az objektum-orientált programozást az Oberon minimális eszközökkel támogatja a kódfordítási folyamat egyszerűsítése és a folyamat felgyorsítása érdekében.
Az elvégzett változtatásoknak köszönhetően az Oberon szintaktikailag egyszerűbbé vált. A szintaxis leírása egy oldalra elfér, a nyelv teljes leírása körülbelül 20 oldalt vesz igénybe, ami fele annyi, mint a Modula-2 leírása . Az Oberon, ha nem is minimális, de legalább az egyik legkisebb univerzális magas szintű programozási nyelv.
Einstein kijelentését választották az eredeti Oberon leírásának epigráfjául: "Legyen olyan egyszerű, amennyire csak lehetséges, de ne egyszerűbb . "
Meghatározása a következő RBNF- javaslatokban [8] :
Modul = MODUL azonosítója ";" [ ImportList ] Utoljára deklarált [ BEGIN Last Statements ] END id "." . ImportList = IMPORTÁLÁS [ id ":=" ] id { "," [ id ":=" ] id } ";" . LastDeclared = { CONST { DeclaredConst ";" } | TYPE { Típusdeklaráció ";" } | VAR { DeclaredVar ";" }} { DeclaredProc ";" | TovábbításDeclared ";" }. DeclaredConst = IdentDef "=" ConstExpression . TypeDeclare = IdentDef "=" Típus . DeclaredVar = ListIdentifier ":" Típus . DeclaredProc = PROCEDURE [ Receiver ] IdentDef [ FormalParam ] ";" Utoljára deklarált [ BEGIN Utolsó nyilatkozatok ] END Ident . ForwardDeclare = PROCEDURE "^" [ Receiver ] IdentDef [ FormalParam ]. FormalParam = "(" [ FP Section { ";" FP Section }] ")" [ ":" SpecIdent ]. SectionFP = [ VAR ] id { "," id } ":" Típus . Receiver = "(" [ var ] id ":" id ")" . Típus = QualID | ARRAY [ ConstExpression { "," ConstExpression }] OF Type | RECORD [ "(" QualIdent ")" ] FieldList { ";" FieldList } END | POINTER TO Típus | ELJÁRÁS [ FormalParam ]. FieldList = [ ListIdent ":" Type ]. AfterOperators = Operátor { ";" A } operátor. Operátor = [ Jelölés ":=" Kifejezés | Jelölés [ "(" [ ListExpression ] ")" ] | IF Expr THEN utasítás Seq { ELSIF Expr THEN utasítás Seq } [ ELSE Statement Seq ] END | CASE OF Option { " |" Változat } [ ELSE StatementSeq ] END | WHILE Express DO nyilatkozat Seq END | REPEAT StatementSeq UNTIL Kifejezés | LOOP AfterStatements VÉGE | A Guard DO nyilatkozatával Seq END | KILÉPÉS | RETURN [ Express ] ]. Option = [ Option Labels { "," Option Labels } ":" StatementLast ]. VariantLabels = ConstExpression [ ".." ConstExpression ]. Guard = SpecId ":" SpecId . ConstExpression = Expressz . Kifejezés = SimpleExpression [ Relation SimpleExpression ]. SimpleExpression = [ "+" | "-" ] Term { OperSlog Term }. Term \ u003d szorzó { OperMul szorzó }. Szorzó = Jelölés [ "(" [ ListExpression ] ")" ] | szám | szimbólum | húr | NIL | Állítsa be | "(" Kifejezés ")" | " ~ " Szorzó . Set = "{" [ Element { "," Element }] "}" . Elem = Express [ ".." Express ]. Reláció = "=" | "#" | "<" | "<=" | ">" | ">=" | IN | VAN . OperSlog = "+" | "-" | VAGY . OperUmn = "*" | "/" | DIV | MOD | "&" . Megnevezés = Minősítő { "." ident | "[" ListExpression "]" | "^" | "(" QualIdent ")" }. ListExpr = { "," Express } kifejezés . ListIdent = IdentDef { "," IdentDef }. QualID = [ azonosító "." ] ID . IdentDef = ident [ "*" | "-" ].Az Oberon program egy modulkészlet. Általában a modul így néz ki:
MODUL Név ; IMPORT ImportList ; Meghatározások ; BEGIN Kimutatások END Név .Az importlista határozza meg, hogy mely modulokból kerüljön importálásra a külső nevek . A definíciók magukban foglalják a típusok, eljárások, függvények, változók, állandók definícióit. Ebben az esetben a csillaggal jelölt nevek definícióit ez a modul exportálja, vagyis azokat a többi, ezt importáló modul láthatja. Az Oberon-2-ben a nevek mínuszjellel is jelölhetők, ilyenkor csak olvasható módban kerülnek exportálásra.
A modul törzse betöltéskor végrehajtódik. A Pascal komponensben a modul törzsében (a szakaszban BEGIN..END) most már lehetőség van egy szakasz hozzáadására CLOSE:
BEGIN CLOSE utasítások END utasítások Név .Itt a és közötti utasítások BEGINa CLOSEmodul betöltésekor, a és közötti utasítások CLOSEpedig END a memóriából való kitöltéskor hajtódnak végre. Egy ilyen kiterjesztést hasznosnak találtak a modulokat dinamikusan betöltõ és kirakodó komponensprogramok esetében .
A programozó által létrehozott adattípusok a következő halmazokra korlátozódnak: tömbtípusok ARRAY , rekordtípusok RECORD , procedurális típusok PROCEDURE , mutatótípusok POINTER . A mutatót csak tömbnek vagy rekordnak lehet deklarálni.
A program belső részének szintaxisa meglehetősen hagyományos és egyszerű. A nyelv támogatja a hagyományos szerkezeti halmazt: feltételes operátor IF, kiválasztó operátor CASE, ciklusok (előfeltétellel - WHILE, utófeltétellel REPEAT..UNTIL, feltétel nélküli - LOOP). A 2. modulhoz hasonlóan az azonosítókban megkülönböztetik a kis- és nagybetűket, minden lefoglalt szót nagybetűvel írunk. A ciklus kivételével minden nyelvi konstrukció REPEAT..UNTILkulcsszóval végződik, ENDés lehetővé teszi több utasításon belüli egymásba ágyazását összetett utasítás használata nélkül BEGIN..END. Természetesen, mint a 2. modulban, nincsenek feltétlen ugrások.
Az objektum-orientált programozási paradigmát a rekordkiterjesztési mechanizmus támogatja (a nyelvnek nincs külön kulcsszava az osztályok leírására, mint pl. "class" vagy "object", úgy vélik, hogy a "rekordtípus" szokásos fogalma meglehetősen elegendő). Lényegében minden rekordtípus az osztály leírása, a rekord mezői pedig az osztály adattagjai.
Az eredeti Oberonban egyáltalán nincsenek metódusok ( az osztályhoz társított eljárások és függvények ). A metódusmechanizmus használható eljárási típusú mezők deklarálásával a rekordban, amelyekhez az osztály példányának létrehozásakor speciális eljárásokat rendelnek. Az ilyen eljárások meghívása a rekordmező elérésének hagyományos módjával történik, alapértelmezés szerint az eljárás nem tud arról az osztályról, amelyre meghívták (nincs hasonló mechanizmus thisC ++-ban vagy Java-ban), és ha ilyen információ szükséges hozzá, a példányra való hivatkozást kifejezetten át kell adni (például a paraméteren keresztül ). A kifejezetten leírt módszerek hiánya volt az eredeti Oberon egyik tulajdonsága, ami kritikát váltott ki a hagyományos hibrid nyelvekhez szokott programozók részéről. Másrészt az Oberon által javasolt mechanizmus lehetővé teszi, hogy mindent, ami a nyelvek hagyományos eszközeivel megvalósítható metódusokkal, és még inkább - az Oberonban egy osztály minden példányának megvan a maga metódusverziója ( egy procedurális típusú mező értéke), míg a metódusok osztály részeként történő leírásakor minden példány egyetlen metódusváltozaton működik. Az Oberon 2-ben még bevezették a módszereket. A metódusokat a rekordtípustól elkülönítve írjuk le, jelezve a hozzájuk tartozó típust.
Egy új rekordtípus deklarálható egy meglévő kiterjesztéseként. Ebben az esetben a kibontandó típust a bejegyzés leírásában a kulcsszó után zárójelben adjuk meg RECORD. A kiterjesztett típus automatikusan megkapja a kiterjesztett típusú összes mezőt, és (az Oberon 2-ben) hozzá van rendelve a kiterjesztett típushoz kapcsolódó összes eljáráshoz. Az új típushoz társított eljárások ugyanazzal az aláírással rendelkezhetnek , mint a kibővítendő típushoz tartozó eljárások - ez biztosítja, hogy a származtatott típusokban lévő metódusok felülírásra kerüljenek. A Component Pascalban az öröklődési hierarchiák konzisztenciájának teljes statikus ellenőrzése érdekében (és ezáltal az eredeti Oberont megkülönböztető teljes statikus tipizálási elv visszaállítása érdekében) a rekordok alapértelmezés szerint nem bővíthetők, és a metódusok nem bírálhatók felül. A speciálisan bevezetett kulcsszavak a rekordbővítés és a metódusok felülbírálásának szabályozására szolgálnak EXTENSIBLE, ABSTRACT, LIMITED, EMPTY. Ebben az esetben az újonnan bevezetett módszereket kulcsszóval kell jelölni NEW(vö. az újonnan bevezetett változók kötelező definíciójával).
Az Oberon a komponens-orientált szoftverfejlesztésre irányul [9] . A beágyazás kizárólag modulszinten támogatott – a modulon belül deklarált összes típus teljesen átlátszó egymás számára. Ami más modulokból elérhető, az a definícióban exportálhatónak van deklarálva.
A polimorfizmust a metódusmechanizmus biztosítja (mind az Oberon procedurális mezői, mind az Oberon-2 metódusai virtuálisan viselkednek , a legtöbb hibrid objektum-orientált nyelv terminológiája szerint), valamint egy kiterjesztett WITH konstrukció, amely lehetővé teszi különböző csoportok végrehajtását. állítások, attól függően, hogy argumentuma melyik kiterjesztett típushoz tartozik-e.
A nyelvben nincs speciális konstruktor mechanizmus. Az objektumok létrehozásának és inicializálásának ajánlott módszere a modulok és eljárások előállítása (hagyományos OOP terminológiával gyárilag).
A program ebben a technológiában viszonylag független komponensek halmaza (jelen esetben modulok), amelyek a külvilág elől rejtett belső szerkezettel és világosan meghatározott interfésszel rendelkeznek. A modulok a program futása közben dinamikusan be- és kirakhatók, a rendszer fejlett futásidejű típus-ellenőrző eszközöket biztosít, amelyek lehetővé teszik olyan univerzális adatfeldolgozó algoritmusok írását, amelyek nem függenek ezen adatok konkrét típusaitól (például könyvtár A DBMS-sel végzett munka olyan módszereket biztosíthat, amelyek egy lekérdezés eredményét az adatbázisból egy tetszőleges szerkezetű rekordba írják, ha ebben a rekordban a mezők halmaza és típusai megfelelnek az adatbázisban lévő mezők halmazának és típusainak).
A komponensparadigmában szerencsétlen építészeti döntésnek tartják, amely a másik komponensben deklarált típusokból származó implementáció öröklődésének széles körben elterjedt használatához kapcsolódik, mivel ez az „alaptípus ridegség” néven ismert jelenséghez vezet – miután nagyszámú származtatott típus származtatott az alaptípus (és ezek egy része még ismeretlen is lehet az alaptípus fejlesztője számára), az alaptípus implementációjában bekövetkezett bármilyen változtatás rendkívül kockázatossá válik, mivel kiszámíthatatlan módon érintheti a leszármazott típusokat.
Ismeretes, hogy az objektum-orientált programozás rendszerprogramozásban való használatának egyik problémája az, hogy kis osztályokból álló csoportokra van szükség, amelyek további többletköltség nélkül képesek együttműködni. Az Oberonnál nincs ilyen probléma - az egy modulban definiált összes típus látja egymást, és ez nem okoz megbízhatósági problémákat, mivel a modult továbbra is egészében fejlesztik, tesztelik és karbantartják.
Az Oberonon kifejlesztett tipikus rendszer eljárási interfésszel rendelkező modulokból áll, amelyeken keresztül a modulok adatokat, köztük objektumokat cserélnek. Ugyanakkor az összes beágyazóeszköz csak modulok közötti interakcióban működik, ami kényelmessé teszi az objektumok használatával történő rendszerprogramozást.
Objektumorientált programozásAz objektumprogramozási eszközöket az Oberon az iratokkal való munkavégzéshez szükséges eszközök természetes fejlődéseként értelmezi moduláris rendszerben, pontosabban technikai eszköztárként egy konkrét építészeti probléma megoldásához: hatékony „munkamegosztást” biztosít a különböző modulok között a munkavégzés során. dinamikus típusokkal és adatszerkezetekkel: például a listában a mutatókkal való munka elrejthető (a megfelelő mezőkkel együtt) az egyik modulban, egy másikban pedig a listaelemek definíciója és konkrét „kitöltésével” való munka. (vagy gyakrabban mások). Ebben az értelemben az Oberon objektumprogramozási technológiája a modularitás fogalmának van alárendelve: itt inkább az adatok leírásának eszköze, mintsem az alkalmazásarchitektúra egészének felépítése.
Wirth [10] szerint a Java nyelv fejlesztői több évvel a létrehozása előtt „tanulmányozták az Oberon forráskódjait, és különösen az Oberon szemétgyűjtőinek forráskódjait. Aztán elrontották az Oberont a C szintaxissal, és Java-nak nevezték. Bár a szóbeli előadástól nem lehet megkövetelni abszolút pontos megfogalmazást, mindenesetre az oberoni és a jávai ideológiák kétségtelen hasonlósága (a minimalizmus és az erős gépelés vágya, a többszörös öröklődés korlátozása, az automatikus memóriakezelés) azt sugallja. bizonyos konszenzus arról, hogy mely eszközök képezzék a modern általános célú programozási nyelv magját. Ha azonban a minimalizmus továbbra is az Oberon és közvetlen utódai élen jár, a Java fejlesztők a nyelv képességeinek széles körű kiépítésének útját választották.
Magába az Oberon nyelvcsaládba tartozik még az Oberon-07 , Oberon-2 , Component Pascal ( Component Pascal ), Active Oberon , OberonScript stb.
Az Oberon eredeti verziója ("klasszikus Oberon") a legtömörebb, a legkevesebb kulcsszót és szintaktikai konstrukciót tartalmazza. Ez szolgált alapul egy olyan nyelvcsalád létrehozásához, amelyek mindegyike valamilyen irányba kiterjeszti a klasszikust, vagy bizonyos részletében eltér attól.
1992-ben Niklaus Wirth és tanítványa, Hanspeter Mössenböck jelenleg az egyetem professzorai. Johannes Kepler Linzben – közzétette az Oberon bővített változatának, az Oberon-2- nek a leírását . A klasszikus Oberon finomított változata. Az Oberon 2-höz nagyon takarékosan bevezetett kiegészítések a következők:
A nyelv bővítése ellenére az Oberon-2 szintaxisának formális leírásának volumene a szintaxisleírás optimalizálása miatt kisebb, mint a klasszikus Oberoné. Létezik egy optimalizáló XDS fordító [13] az Oberon-2 számára; van még egy fordító [14] a Java bájtkódhoz .
ETH Oberon , amelynek megvalósításai számos számítástechnikai platformra elérhetők.
Az Oberon SA az Oberon nyelv változata, amelyet N. Wirth fejlesztett ki a pilóta nélküli helikopterekben használt Strong-ARM processzorhoz .
Az Oberon SA fejlesztésének tapasztalatai alapján 2007-ben N. Wirth változtatásokat és kiegészítéseket készített a klasszikus Oberonhoz [15] [16] a strukturált programozás szigorúbb támogatása érdekében, mint például az Oberon-2 vagy a Component Pascal esetében. A nyelv új verziója az Oberon-07 nevet kapta [17] . Létezik a "The Programming Language Oberon, Revision 1.11.2008" orosz nyelvű fordítása [18] . De az objektum-orientált programozás támogatása tekintetében az Oberon-07 nyelv nem követi az Oberon-2-t, hanem a klasszikus Oberon minimalista vonalát folytatja, beleértve a rekordtípusokhoz kapcsolódó eljárások támogatásának hiányát.
Az Oberon-07 a következő fő különbségekkel rendelkezik a klasszikus Oberontól:
Az ausztrál CFB Software (Brisbane) cég a Queenslandi Egyetemen kifejlesztette az Astrobe IDE -t [21] az Oberon-07 nyelvhez NXP (Philips) ARM7 mikrokontrollerekhez, valamint az Oberon-07 nyelv szintaktikai diagramjait [22] . mint iránymutatás az Oberon-07 programjainak stílusához [23] .
Közvetlenül 1992-es megjelenése után az Oberon-2-t a nyelvi szabvány szerepére jelölték (Oakwood Conference, Croydon, 1993), de a nagy szoftverrendszerek létrehozásában szerzett gyakorlati tapasztalatok rávilágítottak az újítások gyenge pontjaira és az újítások kívánatosságára. további finomítások (ami ismét hangsúlyozza annak a konzervativizmusnak a bölcsességét, amelyet Wirth mutatott fel a klasszikus Oberon meghatározásakor). Ezeket a finomításokat az Oberon-2 Component Pascal nevű változatában végezték el, és 1999 -ben adta ki az Oberon microsystems [24] , amelyet 1992-ben Wirth tanítványai alapítottak (Wirth maga lett az igazgatótanács tagja). Csakúgy, mint az Oberonról az Oberon-2-re való átmenet során, ezeket a finomításokat a legtakarékosabban hajtják végre [25] . A nyelv most már teljes mértékben támogatja a komponens-orientált programozási módszertant . Az utolsó körülménynek köszönhetően a Pascal komponens jelenleg láthatóan a legtökéletesebb a klasszikus Oberon közvetlen leszármazottai közül. Ez azonban nem csak az eredeti Oberonnal egyenértékű részhalmazra redukálható, hanem egy másik teljes értékű minimalista részhalmazra is, amelyben az öröklődés és a metódus felülbírálása csak tisztán interfésztípusok és metódusok esetén megengedett (az ABSTRACT attribútummal definiálva). Ez a körülmény rávilágít az Oberon-2 némileg köztes jellegére.
A Pascal komponens olyan funkciókat ad hozzá, amelyek lehetővé teszik a fejlesztő számára, hogy teljes ellenőrzést gyakoroljon az exportálási típus-kiterjesztés és a metódus felülbírálása felett (EXTENSIBLE, ABSTRACT, NEW, EMPTY attribútumok, valamint a korlátozott "csak implementációra szánt" metódusexport lehetősége). Hozzáadott modultörzs befejezési blokk (CLOSE kulcsszó) és előre meghatározott üres FINALIZE metódus. Az alap (elemi) típusok rendszere a Java típusokhoz igazodik. Egy implicit karakterlánc típust vezettek be. A Component Pascalt meghatározó Oberon Microsystems kiadta a BlackBox Component Framework -et és a BlackBox Component Builder [26] vizuális programozási környezetet is , amely kis méretű és erőforrásigénytelen, teljes egészében Component Pascalra épült.
Ezt követően a BlackBox fordítót beépítették a Denia keresztplatformos programozási környezetébe , különösen a JBed valós idejű operációs rendszerhez , és teljes egészében Component Pascal nyelven íródott.
Ezeket a nyelveket már jó okkal nevezhetjük nem az Oberon kiterjesztésének vagy verziójának, hanem független nyelveknek. Jelentősen kibővítették a szintaxist, konstrukciókat vezettek be a klasszikus "tulajdonságok" (tulajdonságok) leírására olvasási / írási vezérléssel, bitben meghatározott méretű numerikus típusokkal. Az RBNF leírása által meghatározott formátumú üzeneteket cserélő aktív objektumok támogatása, kivételkezelés [27] .