| Systemobjektmodell (SOMObjects) | |
|---|---|
| Utvecklaren | CILabs ( IBM , Apple Computer , etc.) |
| Operativ system | MacOS , OS /2 , AIX , Windows , DOS |
| senaste versionen | 3.0 (december 1996 ) |
System Object Model ( SOM ) är ett system av objektorienterade dynamiska bibliotek utvecklat av CILabs ( IBM , Apple , OMG, Adobe , Oracle, etc.). DSOM, en CORBA -baserad distribuerad version av SOM som gör att objekt kan distribueras över olika datorsystem. Det finns implementeringar för Windows NT, MacOS Classic, OS/2, AIX, DOS, Copland, OS/390, NonStop OS operativsystem. För Windows NT, MacOS och OS/2 finns en implementering av SOM/DSOM-baserad OpenDoc-komponentutveckling. Systemet utvecklades i mitten av 1990-talet, det övergavs 1998 [1] .
IBM SOM liknar konceptuellt Microsoft Component Object Model . Båda systemen löser problemet med att skapa ett standardbiblioteksformat som kan anropas från mer än ett språk. SOM anses vara mer funktionellt än COM. COM tillhandahåller två sätt att anropa metoder på ett objekt, och ett objekt kan implementera en eller båda av dem. Den första är dynamisk anrop och sen bindning (IDispatch), och är liksom SOM språkoberoende. Det andra sättet, genom ett privat gränssnitt, använder en funktionstabell som kan konstrueras i C, eller använd en lägre nivåkompatibel virtuell metodtabell för ett C++-objekt. Med kompatibla C++-kompilatorer kan du deklarera privata gränssnitt som rena virtuella C++-klasser. Privata gränssnitt är en kompromiss mellan funktionalitet och prestanda. När ett gränssnitt väl har publicerats till en släppt produkt kan det inte ändras eftersom användarapplikationerna för gränssnittet har kompilerats för en specifik tabellenhet på låg nivå. Detta är ett exempel på ett skört basklassproblem som kan resultera i DLL hell , där alla program som använder den gamla versionen slutar fungera korrekt efter installation av en ny version av ett delat bibliotek. För att undvika detta problem bör COM-utvecklare alltid ha i åtanke att gränssnitt som redan har publicerats inte bör modifieras. Om du vill lägga till nya metoder eller göra andra ändringar måste du definiera nya gränssnitt. SOM förhindrar dessa problem genom att endast tillhandahålla sen bindning och tillåta runtime-linkern att bygga om tabeller i farten. Således beräknas ändringar av underliggande bibliotek om när de läses in i program, till priset av en liten prestandaträff.
Gränssnittet kan dock inte ändras inte bara av tekniska skäl utan också ur OOPs synvinkel. Ett gränssnitt, till skillnad från en klass, har ingen standardimplementering och kan implementeras av vem som helst, inklusive en tredjepartsutvecklare. Följaktligen, om ändringar görs i gränssnittet, kan tredje parts klasser inte automatiskt stödja det nya gränssnittet. Således kan du antingen bara använda klasser istället för gränssnitt, vilket ger en alltid uppdaterad standardimplementering, eller så kan du förhindra tredjepartsutvecklare från att implementera ett potentiellt utökningsbart gränssnitt, i vilket fall ordet "gränssnitt" förlorar sin betydelse i OOP-villkor.
SOM är också mer funktionellt vad gäller fullt stöd för olika OO-språk. Medan COM-utveckling är begränsad till att använda en avskalad version av C++, stöder SOM nästan alla vanliga funktioner och till och med några esoteriska. Till exempel stöder SOM flera arv, metaklasser och dynamiska anrop. Vissa av dessa funktioner är inte tillgängliga på de flesta språk, så många SOM/COM-liknande system är lättare att implementera på bekostnad av stöd för en mindre uppsättning språk. Den fulla flexibiliteten för flerspråkig support var viktig för IBM på grund av behovet av att stödja både Smalltalk (enkelt arv, dynamisk länkning) och C++ (multipelt arv och statisk länkning). Behovet av att stödja multipelarv är bland annat en konsekvens av att det istället för gränssnitt bara finns klasser. Det bör noteras att C++:s stöd för multipelt arv skiljer sig från CLOS, Dylan, SOM och Python, och C++:s multipla arvsproblem är inte specifika för SOM.
Den mest märkbara skillnaden mellan SOM och COM är stödet för arv, vilket COM inte alls har. Det kan tyckas konstigt att Microsoft har tagit fram ett objektbibliotekssystem som inte stöder den mest grundläggande principen för OOP. Det största hindret för detta är svårigheten att avgöra var basklassen är i systemet medan biblioteken laddas i en potentiellt godtycklig ordning. COM kräver att utvecklaren specificerar basklassen exakt vid kompilering, vilket gör det omöjligt att infoga andra ärvda klasser i mitten (åtminstone i utländska COM-bibliotek).
Däremot använder SOM en enkel algoritm som går igenom arvsträdet och letar efter en potentiell basklass och bestämmer sig för den första lämpliga. I de flesta fall är detta den grundläggande principen för arv. Nackdelen med detta tillvägagångssätt är möjligheten att nya versioner av basklassen inte fungerar trots oförändrade API. Denna möjlighet finns i alla program, inte bara de som använder delade bibliotek, men problemet blir väldigt svårt att spåra om det finns i någon annans kod. I SOM är den enda lösningen att helt testa nya versioner av bibliotek, vilket inte alltid är lätt.
Jämförelse med andra tillvägagångssätt gjordes i rapporten "Release-to-Release Binary Compatibility and the Correctness of Separate Compilation" [2] , särskilt Smalltalk, CLOS, Generic C++, SOM, SGI Delta/C++, OBI, Objective- C , Java. Av moderna system är det närmast SOM när det gäller att tillhandahålla objektiv-C-kompatibilitet på låg nivå, särskilt efter implementering av icke-bräckliga ivar.
Sändare för C och C++ ingår i själva SOMobjects Developer Toolkit och låter dig både anropa objektmetoder och ärva från klasser. Vissa C++-kompilatorer, först MetaWare High C++, sedan IBM VisualAge C++, implementerade Direct-to-SOM-kapacitet. VisualAge C++ för Windows introducerade den här funktionen i version 3.5 [3] , som också var den senaste versionen som stödde denna funktion.
ObjectREXX, som levereras med OS/2, är integrerat med SOM, vilket gör att du kan anropa metoder på objekt och ärva från klasser. När ObjectREXX-källorna släpptes till öppen källkodsgemenskap överfördes inte alla filer som krävdes för att denna integration skulle fungera, och den här funktionen inkluderades inte i versionen med öppen källkod. Under en tid fanns spår av integration med SOM i förvaret, men det var omöjligt att kompilera, och därefter togs allt relaterat till SOM bort helt.
VisualAge SmallTalk SOMSupport-paketet låter dig anropa SOM-metoder på objekt och skapa SOM-omslag för SmallTalk- klasser .
IBM ObjectCOBOL använde ursprungligen SOM som ett objektsystem i Direct-to-SOM-läge. Därefter portades ObjectCOBOL till Java och började använda Java-objektsystemet istället för SOM.
Vissa versioner av VisualAge for Basic hade SOM-integration [4] . Dessutom kan Lotus Script, som ingår i distributionen av OpenDoc, också fungera med SOM-objekt genom OpenDoc Direct Scripting (ODDS) [5] .
I SOMObjects Java Client [6] var det möjligt att anropa SOM-objekt endast på distans, via DSOM. Demoexemplet hade klasser som gjordes tillgängliga på DSOM-servern, och sedan lagrades Java-appleten på en internetresurs, skapade fjärrobjekt och anropade deras metoder. Lokala metodanrop tillhandahålls inte.
Sändare för Virtual Pascal utvecklades av en privatperson, senare portade till Free Pascal [7] (endast OS/2). De låter dig anropa metoder och skapa dina egna klasser.
SOMIRIMP.exe [8] (endast Windows), en importör från den binära databasen SOM.IR till Delphi-bindningar, utvecklades oberoende av en annan person. Låter dig anropa metoder, men inte skapa klasser. Till skillnad från den tidigare sändaren implementerad i C, är SOMIRIMP skriven i Delphi och använder självgenererade bindningar.
Utvecklarna av PowerAda-kompilatorn gjorde sändare [9] och exempel på användning av SOM. PowerAda var bara tillgänglig på AIX, och sändaren kräver SOM 3.0 Beta, även för AIX, för att köras. SOM 3.0 för AIX har gått förlorad.
Canterbury Modula-2 för OS/2 hade objektorienterade tillägg liknande Oberon-2 och stödde Direct-to-SOM-kompileringsläge i den professionella versionen. [tio]
Oberon Microsystems har meddelat stöd för Direct-to-SOM på Mac OS Classic, men statusen för detta projekt är okänd. [elva]
Vanligtvis fortskrider utvecklingen för SOM enligt följande:
I konsumentläge:
Utvecklaren kör SOM-kompilatorn med en emitter för det önskade programmeringsspråket, och anger vilka IDL-filer i det önskade biblioteket som ska bindas till. Till exempel:
sc -sada somcm.idl
Sändaren skapar en eller flera filer i det format som kompilatorn för det valda programmeringsspråket förstår. Med hjälp av dessa filer blir det möjligt att skapa objekt av de beskrivna klasserna och anropa deras metoder.
I producentläge:
Utvecklaren skriver sina egna .idl-filer, som #inkluderar andra .idl-filer, och ärver från klasserna som beskrivs i andra .idl-filer. Sedan kör utvecklaren en speciell sändare som skapar filer med hjälpkod och filer med tomma implementeringar av klassmetoder.
Till exempel:
sc -sih animals.idl
sc -sc animals.idl
Det första anropet kommer att skapa animals.ih, som kommer att innehålla, till exempel, en implementering av Animals_AnimalNewClass som kommer att köra somBuildClass2, vilket ger den en komplex struktur som syntetiserats från ingången .idl. Förutom detta anrop innehåller den här filen själva strukturen och några andra hjälpelement som utvecklaren inte bör ändra alls. Det andra anropet kommer att skapa animals.c med tomma metodimplementationer. IBM:s C- och C++-sändare kan arbeta stegvis och lägga till tomma nya metoder utan att röra koden för befintliga metoder.
Dessutom finns det sändare för att skapa .dll. IMOD-sändaren syntetiserar den huvudsakliga .dll-funktionen, DEF-sändaren syntetiserar .def- och .nid-filerna.
Sändaren är ett bibliotek som heter emit*.dll, där * är ett alternativ till -s-argumentet för SOM-kompilatorn. Biblioteket måste exportera en emit (SOM 2.1) eller emitSL (SOM 3.0) procedur som, när den anropas från SOM-kompilatorn, utför arbete specifikt för den valda sändaren. Arbete kan vara vilket som helst. För att skapa nya sändare finns det ett newemit-skript.
Sändare inkluderar en IR-sändare som skapar eller uppdaterar den binära databasen SOM.IR. Denna databas kan sedan öppnas med Interface Repository Framework. Detta används oftast för fjärranrop och dynamiska programmeringsspråk. Så här fungerar VisualAge SOMSupport för Smalltalk och ObjectREXX.
Dessutom inkluderar OpenDoc-standarden OpenDoc Direct Scripting (ODDS), och skriptspråkstolkar som implementerar ODScriptComponent- gränssnittet kan därmed komma åt SOM-klasser via ODDS. Ett exempel på ett sådant programmeringsspråk är Lotus Script, som levereras med OpenDoc [5] .
SOM.IR-databasen kan också användas för att skapa bindningar för kompilerade programmeringsspråk [12] .
Novell har utvecklat en brygga som gör SOM-objekt tillgängliga från språk som stöder OLE Automation. Dessutom tillåter Novell ComponentGlue applikationer som använder en av OLE- eller OpenDoc-teknikerna att använda komponenter som är gjorda med en annan teknik, samt att linda OpenDoc-delen som en OLE (OCX)-komponent. Detta använder verktyget ctypelib . När du använder det här verktyget genereras ingen programkod under kompileringen. Samma DLL från OpenDoc är registrerad i registret, som kan ladda SOM-biblioteket i minnet och skapa virtuella metodtabeller, språngbrädor och andra element som behövs för proxy-COM-objekt under körning. Vanligtvis implementerar ComponentGlue bara IDispatch-gränssnittet, men för att påskynda saker och ting är det möjligt att deklarera och implementera ditt eget COM-gränssnitt genom att markera SOM-gränssnittet med ODdual-modifieraren och följa alla regler för OLE-gränssnitt.
Ett annat verktyg för att integrera SOM och COM är verktyget emitcom , som skapar COM-omslag för SOM-klasser i C++. emitcom ingick i SOM 3.0 Beta (februari 1996), men ingick inte i SOM 3.0 Release (december 1996), som många andra funktioner.
Det bör dock noteras att eftersom COM inte gör något för att lösa problemet med spröd basklass bör du vara försiktig med sådana broar. COM-inpackningarna som produceras av emitcom motsvarar klassens gränssnittsnugget vid tidpunkten för skapandet, och när gränssnittet ändras måste nya versioner av wrappers skapas med nya COM-gränssnitts-GUID:er som fortfarande stöder COM-gränssnitten för de gamla wrapperversionerna . COM-gränssnitten som genereras av verktyget ctypelib för SOM-klasser markerade med ODdual-modifieraren bör inte användas från kompilerade programmeringsspråk, eftersom lågnivårepresentationen av ett sådant gränssnitt inte är stabil. ctypelib skriver vanligtvis över COM-typbiblioteket, och det finns ingen möjlighet att underhålla flera olika versioner av ett gränssnitt parallellt.
När du använder sändare i kompilerade programmeringsspråk som C++, ger C++-sändaren sken av att SOM-klassen är en C++-klass. somInit mappas till standardkonstruktorn och somAssign mappas till operator=. Men när man implementerar sina klasser spelar det en stor roll att skriva .idl, och implementeringen av metoder ser inte ut som implementeringen av klassmetoder. Du måste hela tiden anropa SOM-kompilatorn för att uppdatera filerna. SOM visar sig vara något främmande för programmeringsspråk vars kompilatorer inte har inbyggt stöd för SOM.
Direct-to-SOM C++-kompilatorn eliminerar behovet av att skriva .idl-filer. .idl-filer genereras baserat på C++ DTS-huvudfiler, inte tvärtom. Således ger DTS C++-kompilatorn en komplett, homogen utvecklingsmiljö som låter dig skriva allt på ett språk. Att arbeta med som.dll i DTS C++ liknar att arbeta med objc.dll i Objective-C.
Sändare behövs fortfarande, men bara för att importera tredjepartsbibliotek. Microsoft C++ har förmågan att skriva #import <something.tlb>. Samma sak kunde göras med IDL i DTS C++, men detta implementerades inte. Istället måste du använda en sändare som skapar .hh-filerna som krävs av DTS C++-kompilatorn. DTS C++-kompilatorn stöder både vanliga C++-klasser och SOM-klasser som ärver från SOMObject (explicit eller implicit, med #pragma SOMAsDefault (på)). Precis som med en annan hybrid, Objective-C++, är möjligheten att blanda klasser från olika hierarkier begränsad.
Direct-to-SOM C++ dök upp i MetaWare High C++ och duplicerades senare i VisualAge C++, dessutom är dessa implementeringar inte direkt kompatibla, endast genom import/export till .idl. I boken "Putting Metaclasses to Work" beskrevs en annan, tredje känd dialekt av DTS C ++, vars kompilator ännu inte existerar.
Det finns en öppen implementering av SOM - somFree [13] . Projektet hävdar binär kompatibilitet med den ursprungliga implementeringen från IBM. Netlabs.org har en NOM-implementering som är baserad på SOM-principer, men som varken är käll- eller binärkompatibel.
| OS/2 -komponenter och API:er | |
|---|---|
| Main | |
Management Services | |
| Spel |
|
| OS kärna | |
| Filsystem | |
| Grafiskt delsystem |
|
| Objektmodell | SOM
|
| Kompatibilitet |
|