NO331544B1 - System og fremgangsmate for a assosiere egenskaper til objekter - Google Patents

System og fremgangsmate for a assosiere egenskaper til objekter Download PDF

Info

Publication number
NO331544B1
NO331544B1 NO20032993A NO20032993A NO331544B1 NO 331544 B1 NO331544 B1 NO 331544B1 NO 20032993 A NO20032993 A NO 20032993A NO 20032993 A NO20032993 A NO 20032993A NO 331544 B1 NO331544 B1 NO 331544B1
Authority
NO
Norway
Prior art keywords
property
computer
class
value
attached
Prior art date
Application number
NO20032993A
Other languages
English (en)
Other versions
NO20032993D0 (no
NO20032993L (no
Inventor
Mark James Finocchio
Nicholas M Kramer
Jeffrey L Bogdan
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of NO20032993D0 publication Critical patent/NO20032993D0/no
Publication of NO20032993L publication Critical patent/NO20032993L/no
Publication of NO331544B1 publication Critical patent/NO331544B1/no

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488Object-oriented
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Storage Device Security (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Det er beskrevet en mekanisme for å frembringe ny funksjonalitet for et objekt som skal uttrykkes som en egenskap som ikke er innebygd i den klasse hvor objektet er utledet fra. Mer spesielt assosierer mekanismen egenskaper i en klasse med en annen klasse. Et datamaskin- lesbart medium som innbefatter et objekt som har en egenskap i et første sett med egenskaper, innbefatter videre en datastruktur. Datastrukturen innbefatter definisjoner for hver av et annet sett med egenskaper, og innbefatter minst en statisk metode. Den statiske metode er assosiert med en egenskap blant det annet sett med egenskaper og innbefatter en første parameter. Den første parameter identifiserer entydig den ene egenskap. Den statiske metode er operativ for å assosiere den ene egenskap med objekter, uten å spesifisere en eksplisitt referanse til den ene egenskap ved objektet. Egenskapen blir registrert under kjøretiden for å motta den unike identifikator.

Description

Teknisk område
Foreliggende oppfinnelse vedrører generelt programvareapplikasjon, og mer spesielt mekanismer for styring av egenskaper ved objekter innenfor en programvareapplikasjon.
Bakgrunn for oppfinnelsen
De fleste programmeringsmodeller understøtter i dag klassekonseptet. Disse klassene er vanligvis strukturert i et hierarkisk tre med grener som representerer forskjellige klasser i klassehierarkiet. Når to grener er ved forskjellige nivåer, representerer den nedre grenen en datterklasse. Datterklassen arver informasjon fra den klasse som er tilknyttet den øvre gren (f.eks. morklassen). Når to grener er ved samme nivå, blir klassene referert til som søskenklasser. For formålet med den følgende beskrivelse kan, når det refereres til en datterklasse i relasjon til en morklasse, uttrykkene nedre klasse og øvre klasse brukes til å referere til henholdsvis datterklassen og morklassen. Den øvre grenen i hierarkiet representerer en basisklasse i det hierarkiske klassetreet. Informasjon i hver klasse innbefatter typisk egenskaper, metoder og hendelser. Egenskapene beskriver karakteristikker tilknyttet klassen. En knappklasse kan f.eks. ha egenskaper slik som bredde, bak-grunnsfarge, fonttype, synlig og nedtrykt. Når en av disse klassene blir opprettet, blir det skapt et objekt for vedkommende klasse. Hver egenskap i objektet har en tilordnet eller assosiert verdi som kan etterspørres og fastsettes under en kjøre-operasjon. Den verdi som etterspørres eller fastsettes, kan ventes å stemme over-ens med en spesiell datatype hvis syntaksen er sterkt fremhevet. Det å ha sterkt fremhevet syntaks er ønskelig, fordi feil kan detekteres innenfor en programvareapplikasjon før kjøreoperasjonen.
Når klassehierarkiet er på plass, oppviser tilføyelse av ny funksjonalitet til objektet innenfor klassehierarkiet et problem. I en programmeringsmodell blir den nye funksjonaliteten tvunget inn i basisklassen. Når dette gjøres, blir basisklassen meget stor (f.eks. etthundre metoder, femti egenskaper og tjue hendelser), noe som resulterer i et nesten ustyrlig objekthierarki. Et uønsket resultat av denne programmeringsmodellen er at antallet egenskaper, metoder og hendelser innenfor basisklassen blir overveldende for utviklere å forstå fullstendig før implementering av ønskede trekk inn i objekter som de frembringer. Nok et annet uønsket utfall av denne programmeringsmodellen er at lagerkravene blir enorme på grunn av det faktum at verdier for egenskapene blir lagret lokalt. Fordi verdiene blir lagret lokalt, kan applikasjoner frembrakt med denne programmeringsmodellen ikke skaleres særlig bra.
Denne programmeringsmodellen forårsaker også andre problemer for tredje parts utviklere. Tredje parts utviklere som ønsker å tilføye ny funksjonalitet, må tilføye en datterklasse ved bunnen av hierarkiet. Fordi den nye datterklassen er ved bunnen av hierarkiet, er den nye funksjonaliteten ikke tilgjengelig for andre klasser innenfor hierarkiet. Tredje parts utviklere kan derfor måtte tilføye den nye funksjonalitet til flere datterklasser. Som man kan forstå, resulterer dette i kode-duplisering som påvirker muligheten til å opprettholde objekthierarkiet. Av de ovennevnte grunner er denne programmeringsmodellen ikke særlig ønskelig.
Inntil foreliggende oppfinnelse har en programmeringsmodul som tillot ny funksjonalitet å bli tilveiebrakt til en klasse innenfor et eksisterende klassehierarki uten de ovennevnte ulemper, ikke blitt funnet av fagkyndige på området.
EP 725337 A angår en fremgangsmåte og et system for å tilveiebringe et prototypisk objekt som kan kopieres for å skape et avledet objekt. Et avledet objekt kan inneholde attributtverdier eller det kan inneholde en referanse til dens prototypiske objekt. Hvis en påkrevet verdi ikke holdes av det prototypiske objekt, søker objektet opp et objekthierarki for å finne den påkrevde attributt. I tillegg kan hvert objekt registrere en interesse i et prototypisk objekt som inneholder påkrevde attributter. Hvis en attributt til et prototypisk objekt endres, informerer det prototypiske objekt alle registrerte objekter om endringen. Ved kjøring blir det prototypiske objekt et hovedobjekt hvis attributtverdier kan endres av brukeren, hvorved endringer i hovedobjektattributtene propageres til alle registrerte avledede objekter.
Oppsummering av oppfinnelsen
Foreliggende oppfinnelse tilveiebringer en mekanisme som gjør det mulig å fremskaffe ny funksjonalitet til en klasse uten at den nye funksjonaliteten blir en permanent del av klassen. I tillegg muliggjør foreliggende oppfinnelse at den nye funksjonalitet uttrykkes som en egenskap som ikke er bygd inn i klassen. Generelt tilveiebringer foreliggende oppfinnelse en mekanisme for å assosiere egenskaper i en klasse med en annen klasse. Denne assosieringen kan lett modifiseres slik at andre sett med egenskaper kan assosieres med klassen.
I et første aspekt tilveiebringer oppfinnelsen et datamaskin-lesbart medium med datamaskin-utførbare instruksjoner for å assosiere et objekt med en første egenskap med en andre egenskap i et andre objekt, kjennetegnet ved at instruksjonene når de utføres utfører en metode omfattende: å identifisere det andre objektet, hvor den andre egenskap er assosiert med en første parameter i det andre objektet; å assosiere den andre egenskap med det første objektet uten å spesifisere en eksplisitt referanse til den første egenskap i det første objektet, å beregne et vektmål basert på plasseringen av den første parameteren; å hurtigbufre den andre egenskap basert på vektmålet; og å initialisere det første objektet med den første parameteren.
I et andre aspekt tilveiebringer oppfinnelsen datamaskin-lesbart medium med datamaskin-utførbare komponenter for å implementere en objektorientert klasseinitialisering, kjennetegnet ved en basisklasse som innbefatter et antall egenskaper; og en vedføyd klasse som innbefatter et antall vedføyde egenskaper, hvor komponentene, når de utføres, utfører følgende: minst én av de vedføyde egenskaper assosieres med et tilfelle av et basisobjekt, basisobjektet initialiseres ved innhenting av en vedføyd egenskapsverdi uten å spesifisere en referanse til noen av basisegenskapene i basisklassen, idet den vedføyde egenskapen hurtigbufres basert på et vektmål som er beregnet basert på en plassering av den ved-føyde egenskaps verdi.
I et tredje aspekt tilveiebringer oppfinnelsen et databehandlingssystem med et datamaskinlesbart medium som lagrer instruksjoner for å implementere en objektorientert klasseinitialisering, kjennetegnet ved et første objekt utledet fra en første klasse, hvor det første objekt innbefatter et første sett med egenskaper; og en annen klasse innrettet for å vedføye en egenskap fra et annet sett med egenskaper til det første objekt som reaksjon på en operativ forespørsel assosiert med det første objekt uten å referere det første sett av egenskaper, hvor komponentene, når de utføres, utfører følgende: det første objekt initialiseres med den ved-føyde egenskap fra det annet sett med egenskaper, og videre hvor den vedføyde egenskap hurtigbufres basert på et vektmål som beregnes basert på plasseringen til den vedføyde egenskapsverdi.
I et fjerde aspekt tilveiebringer oppfinnelsen en datamaskin-implementert fremgangsmåte for å assosiere et objekt med en første egenskap med en andre egenskap i et andre objekt, å identifisere en verdi som tilsvarer det andre objektet; å registrere den andre egenskap med det første objekt, hvor den andre egenskap er lagret på et sted utenfor det første objektet; å beregne et vektmål basert på en plassering av verdien; å hurtigbufre den andre egenskap basert på vektmålet; og å initialisere det første objektet med verdien.
I et femte aspekt tilveiebringer oppfinnelsen et datamaskin-implementert system for å assosiere en vedføyd egenskap til et basisobjekt kjennetegnet ved en prosessor; midler for å vedføye et vedføyd objekt til basisobjektet; midler for å identifisere den vedføyde egenskap i det vedføyde objekt; midler for å assosiere den vedføyde egenskap med basisobjektet uten å referere til en basisegenskap i basisobjektet; midler for å beregne et vektmål basert på plasseringen til en verdi som tilsvarer den vedføyde egenskap; midler for å hurtigbufre den vedføyde egenskap basert på vektmålet; og midler for å initialisere basisobjektet med verdien.
Det beskrives et datamaskin-lesbart medium som innbefatter et objekt med en egenskap i et første sett med egenskaper, videre en datastruktur. Datastrukturen innbefatter definisjoner for hver av et annet sett med egenskaper og innbefatter minst én statisk metode. Den statiske metode er assosiert med en egenskap blant det annet sett med egenskaper og innbefatter en første parameter. Den første parameter identifiserer entydig den ene egenskap. Den statiske metode er operativ til å assosiere den egne egenskap med objektet uten å spesifisere en eksplisitt referanse til den ene egenskap i objektet.
I henhold til et aspekt understøtter den statiske metode en sterkt typebestemt syntaks.
I henhold til et annet aspekt innbefatter den statiske metode å innhente en verdi for objektet uten å ha verdien lagret lokalt på objektet. Verdien kan innhentes fra flere trinn, slik som et morobjekt eller et egenskapsark.
En fordel ved foreliggende oppfinnelse er at inndelingen av egenskaper i ett eller flere delsett gjør det lettere å opprettholde hvert delsett med egenskaper.
En annen fordel ved foreliggende oppfinnelse er at objekthierarkiet lettere kan utvides og gjør det mulig for utviklere å tilføye funksjonalitet til objekthierarkiet som påvirker basisklassen og alle lavere klasser.
En annen fordel ved foreliggende oppfinnelse er at lagerstyring for egenskapene i objektet blir mer effektiv og hensiktsmessig.
Nok en annen fordel ved foreliggende oppfinnelse er at programmeringsmodellen opererer innenfor et programmatisk eller et markerings-miljø. I tillegg opererer programmeringsmodulen i sterkt typebestemte programmeringsspråk, slik som C++ og C#. I tillegg understøtter programmeringsmodulen egenskapsark, endringsvarsler og verdiarv.
En annen fordel ved foreliggende oppfinnelse er at uavhengige biblioteker kan eksistere sammen fordi navnekonflikter er mindre sannsynlige, siden navnet på den vedføyde klasse effektivt blir en del av egenskapsnavnet. Hvis derfor to forskjellige utviklere hver skaper en tilfestet egenskap som har et navn (farge), vil de to tilfestede egenskapene ikke komme i konflikt med hverandre.
Kort beskrivelse av tegningene
Fig. 1 illustrerer et eksempel på en beregningsinnretning som kan brukes i henhold til et utførelseseksempel av foreliggende oppfinnelse,
fig. 2 er et eksempel på en visning som kan frembringes med beregnings-innretningen på fig. 1,
fig. 3 er en grafisk representasjon av en programmeringsmodell som tillater egenskaper fra en klasse å bli tilføyd en annen klasse i samsvar med foreliggende oppfinnelse,
fig. 4 illustrerer flere syntaks-eksempler for implementering av den programmeringsmodell som er vist på fig. 3,
fig. 5 er et logisk flytskjema som illustrerer en prosess for å fastsette en verdi i samsvar med foreliggende oppfinnelse,
fig. 6 er et logisk flytskjema som illustrerer en prosess for å innhente en verdi i samsvar med foreliggende oppfinnelse.
Detaljert beskrivelse av den foretrukne utførelsesform
Kort sagt tilveiebringer foreliggende oppfinnelse en programmeringsmodell som gjør det mulig å tilveiebringe ny funksjonalitet til en klasse uten at den nye funksjonalitet blir en permanent del av klassen. I tillegg gjør foreliggende oppfinnelse det mulig å uttrykke den nye funksjonalitet som en egenskap som ikke er innebygd i klassen. Generelt tilveiebringer foreliggende oppfinnelse er mekanisme for å assosiere egenskaper i en klasse med en annen klasse. Som det vil fremgå etter å ha lest den etterfølgende, detaljerte beskrivelse, tilveiebringer programmeringsmodellen i henhold til foreliggende oppfinnelse, dynamiske egenskaper til objekter uten å bygge egenskapene inn i objektet.
Det vises til fig. 1, hvor et eksempel på et system for implementering av oppfinnelsen innbefatter en databehandlingsinnretning, slik som databehandlingsinnretningen 100.1 en meget grunnleggende konfigurasjon innbefatter databehandlingsinnretningen 100 typisk minst én prosesseringsenhet 102 og et system-lager 104. Avhengig av den nøyaktige konfigurasjon og type databehandlingsinnretning, kan systemlageret 104 være flyktig (slik som RAM), ikke-flyktig (slik som ROM, flash-lager, osv.) eller en eller annen kombinasjon av de to. Systemlageret 104 innbefatter typisk et operativsystem 105, en eller flere programmoduler 106, og kan innbefatte programdata 107. Eksempler på programmoduler 106 innbefatter Visual Studio IntelliSense fra Microsoft Corporation, Redmond, WA, og andre programmeringsmiljøer som benytter objektbiblioteker. I tillegg innbefatter pro-grammodulene 106 programvareapplikasjoner frembrakt ved bruk av et program-meringsmiljø. Når disse programvareapplikasjonene utføres på prosesseringsen-heten 102, behandleren egenskapsmotor programvareapplikasjonen i samsvar med programmeringsmodulen i henhold til foreliggende oppfinnelse. Egenskapsmotoren kan være en del av operativsystemet 105 eller kan være en annen pro-grammodul 106. Denne grunnleggende utforming av databehandlingsinnretningen 100 er illustrert på fig. 1, hvor disse komponentene befinner seg innenfor den stiplede linje 108.
Databehandlingsinnretningen 100 kan ha ytterligere trekk eller funksjonalitet. Databehandlingsinnretningen 100 kan f.eks. også innbefatte ytterligere data-lagringsinnretninger (fjernbare og/eller ikke-fjernbare), slik som f.eks. magnetiske plater, optiske plater eller bånd. Slike ytterligere lagre er illustrert på fig. 1 ved hjelp av det fjernbare lager 109 og det ikke-fjernbare lager 110. Datalagringsmedia kan innbefatte flyktige og ikke-flyktige, fjernbare og ikke-fjernbare media implementert ved hjelp av en hvilken som helst fremgangsmåte eller teknologi for lagring av informasjon, slik som datamaskin-lesbare instruksjoner, datastrukturer, programmoduler eller andre data. Systemlageret 104, det fjernbare lager 109 og det ikke-fjernbare lager 110 er alle eksempler på datalagringsmedia. Datalagringsmedia innbefatter, men er ikke begrenset til RAM, ROM, EEPROM, flash-minne eller annen lagringsteknologi, CD-ROM, digitale versatile plater (DVD) eller annet optisk lager, magnetiske kassetter, magnetbånd, magnetiske platelagre eller andre magnetiske lagringsinnretninger, eller et hvilket som helst annet medium som kan brukes til å lagre den ønskede informasjon og som kan aksesseres av databehandlingsinnretningen 100. Ethvert slikt datalagringsmedium kan være en del av innretningen 100. Databehandlingsinnretningen 100 kan også ha en eller flere innmatingsinnretninger 112, slik som tastatur, mus, penn, taleinnmatingsanordnin-ger, berøringsinnmatingsanordninger, osv. En eller flere utmatingsanordninger 114, slik som en skjerm, høytalere, skrivere, osv., kan også være innbefattet. Disse anordningene er velkjente på området og behøver ikke å bli diskutert nærmere her.
Databehandlingsinnretningen 100 kan også inneholde kommunikasjonsfor-bindelser 116 som gjør innretningen i stand til å kommunisere med andre databe-handlingsinnretninger 118, slik som over et nett. Kommunikasjonsforbindelsene 116 er et eksempel på kommunikasjonsmedia. Kommunikasjonsmedia kan typisk være utformet ved hjelp av datamaskin-lesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal, slik som en bærebølge eller en annen transportmekanisme, og innbefatter et hvilket som helst informa-sjonsleveringsmedium. Uttrykket "modulert datasignal" betyr et signal som har en eller flere av sine karakteristikker fastsatt eller endret på en slik måte at informasjon kodes inn i signalet. Som et eksempel, og ikke som en begrensning, innbefatter kommunikasjonsmedia ledningsførte media, slik som ledningsnett eller direkte ledningskoplede forbindelser og trådløse media, slik som akustiske, radiofrek-vente, infrarøde og andre trådløse media. Uttrykket datamaskin-lesbart medium slik det brukes her, innbefatter både lagringsmedia og kommunikasjonsmedia.
Fig. 2 er et eksempel på en visning som kan frembringes ved hjelp av en applikasjon innenfor programmeringsmiljøet på fig. 1. Selv om programmeringsmodellen i henhold til foreliggende oppfinnelse kan brukes i forskjellige omgivelser, illustrerer fig. 2 som et ikke-begrensende eksempel, bruken av programmeringsmodellen innenfor et brukergrensesnitt-miljø. I dette eksemplet frembringer derfor en av applikasjonene på fig. 1 den visning 200 som er illustrert på fig. 2.
Visningen 200 innbefatter en dialogboks 202. Dialogboksen 202 kan innbefatte et hvilket som helst antall andre styringer (dvs. objekter). I dette eksemplet innbefatter dialogboksen 202 en listeboks 204, en redigeringsboks 206 og et beholderob-jekt 208 som har to knappobjekter (f.eks. en OK-knapp 210 og en AVBRYT-knapp 212). Som diskutert mer detaljert senere i forbindelse med fig. 3, blir, ved bruk av konvensjonelle programmeringsteknikker, hvert av disse objektene (f.eks. 202-212) et datterobjekt utledet fra et basisobjekt (f.eks. en elementklasse). I tillegg kan hvert datterobjekt i samsvar med en utførelsesform av foreliggende oppfinnelse, også utledes fra en nodeklasse. Som beskrevet senere, tilveiebringer denne nodeklassen "tilleggsegenskapen" for de tillagte egenskaper.
Selv om utseendet av skjermen 200 kan synes lik fremvisninger frembrakt ved bruk av tidligere kjente programmeringsmodeller, er mekanismen for å frembringe visningen 200 ganske forskjellig. I tidligere kjente programmeringsmodeller vil programvarekoden som implementerer fremvisningen 200, ha både oppførse-len til objektet og utseendet til objektet, inkorporert innenfor hvert objekt selv, eller i ett av mor-objektene. Som beskrevet i detalj nedenfor, tilveiebringer imidlertid separate klasser, i samsvar med foreliggende oppfinnelse, handlingene og utseendet for objektene 202-212 uten å ty til en eksplisitt referanse mellom de to klassene.
Dette gjør det mulig for utviklere å modifisere enten handlingsdelen eller utseendedelen uten å modifisere hele objektet. I dette eksemplet på et brukergrensesnitt, er således hvert objekt inndelt i to deler. En del angår handlingen (dvs. oppførselen) tilknyttet objektet, og den annen del vedrører utseendet (dvs. gjengivelsen) av objektet. Fordi gjengivelsen er adskilt fra oppførselen til objektet, kan objektets utseende lett modifiseres for å endre den måte objektet ser ut på.
Selv om det ovenfor angitte eksempel på et brukergrensesnitt inndeler egenskapene for objektet i en oppførsel-gruppe og en utseende-gruppe, har opp-finnerne bestemt at egenskaper til mange objekter i forskjellige omgivelser, hensiktsmessig kan inndeles i to eller flere relevante grupper. I samsvar med foreliggende oppfinnelse kan så disse relevante gruppene være "implisitt" assosiert med hverandre for fullstendig å implementere objektet. Denne "implisitte" assosiering frembringer flere fordeler i forhold til tidligere kjente programmeringsteknikker. En av fordelene er at tredje parts utviklere hensiktsmessig kan modifisere den rele vante gruppe som vedrører deres applikasjon, samtidig som de andre gruppene forblir uberørte. Dette forenkler i sterk grad den informasjonsmengde som utvikleren må kjenne til for å endre objektets funksjonalitet. I tillegg blir objekthierarkiet lettere å styre. En annen fordel er at lageret blir redusert fordi hvert objekt ikke nødvendigvis opprettholder en lokal verdi med en løpende tilstand. I stedet, som beskrevet i detalj i forbindelse med fig. 6, kan tilstanden innhentes fra forskjellige kilder etter behov.
Fig. 3 er en grafisk representasjon av en programmeringsmodell 300 som tilveiebringer en mekanisme for "implisitt" assosiering av relevante egenskaps-grupper fra en klasse med en annen klasse i samsvar med foreliggende oppfinnelse. I likhet med andre programmeringsmodeller understøtter foreliggende oppfinnelse en basisklasse 302. Basisklassen 302 innbefatter et første sett med egenskaper 304 assosiert med basisklassen 302.1 tillegg innbefatter basisklassen 302 et sett med metoder 306 og et sett med hendelser 308.1 samsvar med foreliggende oppfinnelse blir imidlertid basisklassen utledet fra en nodeklasse 301. Nodeklassen 301 tilveiebringer en SetValue()-metode (fastsett verdi) 307 og en GetValue()-metode (finn verdi) 309.
Et annet sett med egenskaper 324 er innbefattet i en vedlagt klasse 322. Den vedlagte klasse 322 innbefatter også minst to statiske metoder hver av egenskapene i det annet sett 324 (f.eks. SetFont() (fastsett font) 324 og GetFont() (finn font) 330). Disse statiske metodene kan tenkes på som globale metoder som er tilgjengelige for objekter som har registrert den egenskap som er assosiert med den statiske metode. Utvikleren som leverer den vedlagte klasse 322, er ansvarlig for å skrive koden for hver av disse statiske metoder 326 og 330. Koden vil innbefatte et anrop til en av de metoder som er tilveiebrakt av nodeklassen 301. En applikasjon som anroper SetFont() 326 for en spesiell identifiserer PropertylD (egenskaps-ID) og en gitt fontverdi vil til slutt f.eks. utføre anropet til SetValue() 307 i nodeklassen 301. Parametrene som SetFont() 326 videresender til anropet for SetValue() 307 vil innbefatte den spesifikke identifiserer PropertylD og den gitte fontverdi som ble fremskaffet i SetFont()-anropet 326. Som eksempel kan SetFontQ-funksjonen se ut på følgende måte:
En fagkyndig på området vil forstå at den vedlagte klasse således tilveiebringer sterk understrekning av en eventuelt vedlagt egenskap. Selv om foreliggende oppfinnelse understøtter den applikasjon som anroper SetValue() 307 direkte, omgår dette fordelen ved å tilveiebringe sterk understrekning under kompile-ringstiden. Som nevnt tidligere, gjør sterk typebestemmelse det mulig å detektere feil før kjøreoperasjonen. I en annen utførelsesform tilveiebringer den vedlagte klasse 322 en ytterligere statisk metode (f.eks. GetFontlD() (finn font-ID) 328) for hver av de vedlagte egenskaper 324. Denne ytterligere statiske metode er operativ til å teste om den etterspurte, vedlagte egenskap er blitt registrert. Denne ytterligere statiske metode 328 blir således brukt for å sikre at applikasjonen på riktig måte har registrert den vedlagte egenskap før forsøk på å utføre settet og fremskaffe statiske metoder for den vedlagte egenskap. Hvis f.eks. GetFontlD() 328 detekterer at den farge som er vedlagt egenskapen, ikke er blitt registrert, kan GetFontlD() gi en feil, kan automatisk registrere den farge som er vedlagt egenskapen for det etterspurte objekt, eller lignende.
Det følgende er et eksempel på en utførelsesform for å tilveiebringe den forsinkede registrering:
I likhet med andre programmeringsmodeller, understøtter foreliggende oppfinnelse datterklasser (ikke vist) av basisklassen 302. For enkelhets skyld illustrerer fig. 3 ikke grafisk noen datterklasser av basisklassen 302 eller noen andre ved-føyde klasser, og illustrerer derfor ikke de datterklasser som er assosiert med en annen vedføyd klasse. En fagkyndig på området vil imidlertid etter å ha lest den følgende beskrivelse, være i stand til enkelt å utforme en applikasjon som har datterklasser som refererer til andre vedføyde klasser. Generelt kan en hvilken som helst klasse være en "leverandør" av tilføyde egenskaper så lenge klassen leverer de nødvendige statiske metoder for de tilføyde egenskaper.
Den tilføyde klasse 322 gir tredje parts utviklere mulighet til dynamisk å til-føye egenskaper og funksjonalitet til sine applikasjoner uten å modifisere basisklassen 302.1 likhet med å modifiserer egenskaper innenfor basisklassen 302, påvirker de tilføyde egenskaper (f.eks. et annet sett med egenskaper 324) objekter innenfor et helt hierarkisk objekttre 390. De tilføyde klasser 322 blir ikke initiert under utførelsen av applikasjonen. For hvert objekt som initialiseres fra basisklassen 302, kan derfor den samme vedføyde klasse (vedføyd klasse 322) tilveiebringe det annet sett med egenskaper 324 til hvert av disse objektene.
Under kjøring av applikasjonen, blir et basisobjekt 312 initialisert. I tillegg blir ett eller flere datterobjekter (f.eks. datterobjektene 340-350) initialisert. Initialiseringen av objektene i objekttreet 390 kan være gjennom programstyring (f.eks. C#), gjennom markeringsspråk (f.eks. XML), eller ved hjelp av andre midler. Når objekttreet 390 er frembrakt under programmatisk styring, identifiserer en kompile-rer typisk om de instruksjoner som implementerer den vedføyde klasse 322 har feil, slik som ulovlig navn eller datatype. Som diskutert ovenfor, tilveiebringer den vedføyde klasse 322 sterk typebestemmelse. Feil kan derfor oppfanges før kjør-ing. I tillegg kan programutviklingsverktøy detektere feil under utviklingen av applikasjonen. Når objekttreet 390 er frembrakt ved hjelp av markeringsspråk, tolker en parser markeringselementene. Vanligvis er et navn på en etikett i markeringssprå-ket, navnet på den tilsvarende klasse.
Hvert av disse datterobjektene 340-350 kan innbefatte en eller flere datteregenskaper (f.eks. datteregenskap 341) innenfor datterobjektet (f.eks. datterobjektet 340). Verdier for datteregenskaper kan være lagret i det assosierte datterobjekt. I samsvar med foreliggende oppfinnelse har imidlertid datterobjektene ikke nødvendigvis lokale lagre for lagring av en verdi. I tillegg kan hvert av disse datterobjektene 340-350 innbefatte en eller flere vedføyde egenskaper (f.eks. den ved-føyde egenskap 352 representert innenfor den stiplede boksen) assosiert med datterobjektet. Som beskrevet i detalj i forbindelse med fig. 6, kan den vedføyde egenskap 352 fremskaffe sin verdi fra et lokalt lager tilknyttet datterobjektet 350, kan fremskaffe sin verdi gjennom arv (f.eks. basisobjektet 312) ved hjelp av et egenskapsark (ikke vist), ved hjelp av programmatiske metoder (f.eks. den statiske metode 330 i forbindelse med metoden 309), og ved hjelp av andre midler i samsvar med foreliggende oppfinnelse. Selv om disse verdiene for de vedføyde egenskaper er assosiert med datterobjektet, er lagringen av disse verdiene ikke vanligvis en del av datterobjektet.
Igjen illustrerer fig. 3 programmeringsmodellen i et brukergrensesnitt-miljø. Man vil således bemerke at egenskapene innenfor basisobjektet 312 og datterobjektene 340-350 er relatert til oppførselen av objektene. Basisobjektet 312 representerer et dialogobjekt, datterobjektet 340 representerer et knappobjekt, datterobjektet 350 representerer en redigeringsboks og datterobjektet 342 representerer et velgerobjekt som har to datterobjekter 346 og 348, som henholdsvis representerer en listeboks og et tre. Hvert av disse datterobjektene 340-350 innbefatter en eller flere datteregenskaper (f.eks. datteregenskapen 341), slik som en nedtrykt egenskap for knappobjektet og en utvidet egenskap for treobjektet.
Egenskapene innenfor den vedlagte eller vedføyde klasse 322 relaterer derimot til utseendet av objektet. Det annet sett med egenskaper kan f.eks. innbefatte en egenskap og en normalverdi for fonttype, farge og lignende. Denne programmeringsmodellen er utformet for å fastsette en egenskap ved kjøringen av datterobjektene. I denne utstrekning er den vedføyde egenskap (f.eks. den ved-føyde egenskap 352) i hvert av datterobjektene konfigurert for å motta verdien fra den vedføyde klasse.
Fig. 4 illustrerer flere syntakseksempler for forskjellige operativmiljøer hvor programmeringsmodellen som er vist på fig. 3, kan implementeres. Bruken av uttrykket "leverandør" (provider) i hvert av syntakseksemplene, betegner at de statiske metoder som er beskrevet i syntaksene, er assosiert med en vedføyd klasse som har navn "leverandør". Fordi hver av disse syntaksene tillater den vedføyde klasse å bli navngitt, vil derfor egenskaper som er navngitt identisk innenfor to forskjellige vedføyde klasser, ikke komme i konflikt med hverandre. Dette gjør det mulig for utviklere å utvikle vedføyde egenskapsklasser uten å måtte være opp-merksom på potensielle navnekonflikter.
Det vises nå til syntakseksemplene hvor, hvis programmeringsmiljøet er et programmatisk språk slik som Visual Basic eller C#, kan pseudokode se ut som vist i den programmatiske syntaks 401. Den programmatiske syntaks 401 innbefatter en klasseidentifiserer 402 som identifiserer den klasse som inneholder en tilføyd egenskap. Den programmatiske syntaks 401 innbefatter videre en metodeidentifiserer 404, en parameterliste som har en første identifiserer 406 for å spesifisere et navn på en egenskap, og en annen identifiserer 408 for å spesifisere en verdi assosiert med den egenskap som er spesifisert i den første identifiserer 406. Parameterlisten er omsluttet av parenteser, og et punktum adskiller klasseidentifi-sereren 402 og metodeidentifisereren 404. Det vises til den vedføyde klasse 322 som er vist på fig. 3, for den vedføyde egenskap "FONT" er den programmatiske syntaks 401 som følger:
Attrached Class.SetFont(PropertylD, value).
Det er interessant at denne syntaksen synes å være lik syntaksene i tidligere programmeringsmodeller. Syntaksen er imidlertid ikke identisk, og den programmatiske syntaks 401 er forskjellig fra tidligere kjente syntakser. I den programmatiske syntaks 401 identifiserer f.eks. metodeidentifisereren 404 en statisk metode på en leverandørklasse (dvs. en vedføyde klasse 322 på fig. 3). I henhold til tidligere kjente programmeringsmodeller vil metodeidentifiserere identifisere et metodeeksempel på et leverandør-tilfelle (Provider-instance). Fordi foreliggende oppfinnelse benytter leverandør-klassen (Provider class) (dvs. den vedføyde klasse 322 på fig. 3), kan programmeringsmodellen understøtte utvidede egenskaper i markerings- og egenskaps-ark, fordi levetiden til leverandør-tilfellet ikke må spo-res. Et annet trekk ved den programmatiske syntaks 401 er at syntaksen er sterkt typebestemt. Som nevnt tidligere, muliggjør en sterkt typebestemt syntaks god verktøyunderstøttelse for de potensielle feil, slik som feilstavede navn, ukorrekte datatyper og lignende, kan detekteres ved kompilering istedenfor ved kjøring.
I tillegg tillater programmeringsmodellen, for programmeringsmiljøer slik som Visual Basic, C# eller lignende, også en løst typebestemt syntaks (dvs. programmatisk syntaks 411). Programmatisk syntaks 411 innbefatter en objektidenti-fiserer412 som identifiserer et målobjekt, en metodeidentifiserer 414 som identifiserer en statisk metode innenfor en vedføyd egenskapsklasse, en parameterliste som innbefatter en vedføyd egenskapsidentifiserer og en verdi 419. Den vedføyde egenskapsidentifiserer innbefatter en klasseidentifiserer 416 og en egenskapsidentifiserer 418 som identifiserer den vedføyde egenskap innenfor den assosierte, vedføyde klasse.
I henhold til en annen utførelsesform kan progammeringsmodellen være implementert ved å bruke markeringsspråk-syntaks, slik som markeringssyntaks 421. Markeringssyntaks 421 innbefatter et merke 422, og en vedføyd egenskap har en leverandørbetegner 424 og en egenskapsidentifiserer 426, samt en verdi 428.1 en utførelsesform er merket 422 navnet på målobjektet (f.eks. knappobjektet 340 på fig. 3). Typisk begynner og slutter markeringssyntaksen 421 med et åpnings- og lukke-symbol, "<" og ">". Igjen utfører en parser behandling for å finne ut hvor de vedføyde egenskaper finnes, fordi de vedføyde egenskaper ikke er direkte på klassen.
I nok en annen utførelsesform kan programmeringsmodellen implementeres ved å bruke utvid bart markeringsspråk (XML, extensible Markup Language) med stilark, slik som stilark-syntaks 431 vist på fig. 4. For denne utførelsesformen innbefatter stilark-syntaksen 421 en "merke"-attributt 432. Merke-attributten 432 svarer til den klasse som anmoder om prosessering. Et illustrerende eksempel på vedføyde egenskaper i XML, er som følger: <Button xmlns:ap="expandoNameSpace"Pressed="false" ap:Expandos.String="string"/>
Når en applikasjon som implementerer vedføyde egenskaper i samsvar med foreliggende oppfinnelse utføres, initialiserer applikasjonen objektene i objekttreet. I forbindelse med egenskapsmotoren håndterer så applikasjonen kjø-reoperasjonen som innbefatter innhenting og fastsetting av verdier for objektene. Fig. 5 og 6 illustrerer behandling utført av applikasjonen, i forbindelse med egenskapsmotoren.
Før enten SetValue()-prosessen eller GetValue()-prosessen som er vist på fig. 5 og 6, kan utføres, må imidlertid den vedføyde egenskap som er spesifisert
innenfor en av disse to prosessene, registreres. Som nevnt ovenfor kan en utførel-sesform utføre en kontroll for å bestemme om egenskapen er blitt registrert. Denne kontrollen (f.eks. GetFontlD() 328) kan utføres innenfor en hvilken som helst av de statiske metoder som svarer til den vedføyde egenskap (dvs. SetFont() 326 og GetFont() 330). Fordi denne kontrollen må utføres hver gang noen av de statiske metoder blir anropt, medfører denne utførelsesformen en ytelsesstraff. Fagkyndige på området vil forstå at andre utførelsesformer som optimaliserer registreringen av egenskapen, kan implementeres uten å avvike fra foreliggende oppfinnelse, slik som å kreve at applikasjonen skal utføre registreringen.
Registreringen av den vedføyde egenskap returnerer en unik PropertylD (egenskaps-ID) for den vedføyde egenskap. Et illustrerende anrop for registrering av en egenskap, kan være i følgende form: BarDP = RegisterProperty("Bar",0,typeof(string),typeof(Button),0x3);.
I denne utførelsesformen vil den variable BarDP så inneholde den unike identifiserer for den vedføyde egenskap. Denne unike identifiserer blir så brukt i SetValue()- og GetValue()-funksjonsanropene. I henhold til en utførelsesform blir RegisterProperty (registrer egenskap) anropt direkte eller indirekte, fra eierens statiske produsent. Eieren refererer til den klasse som vedlegger den vedføyde egenskap. Når den vedføyde egenskap er registrert, kan ethvert tilfelle som sam-menligner måltypen for den vedlagte egenskap, "implisitt" vedføye egenskapen ved å anrope finn og fastsett statiske metoder i forbindelse med den vedføyde egenskap.
Som vist ovenfor i eksemplet på anrop for registrering av en egenskap, betegner "Bar" ("stolpe") et navn for den vedføyde egenskap. Egenskapsmotoren bruker vanligvis ikke dette navnet. En parser bruker imidlertid dette navnet til å bestemme om en egenskap med det samme navn allerede er blitt registrert hos eieren. Måltypen er knapp (Button). For vedføyde egenskaper vil eieren og målet ikke være det samme. Normalverdien er "0". Som beskrevet i detalj i forbindelse med fig. 6, bestemmer egenskapsmotoren hvor det skal innhentes en verdi for den vedføyde egenskap. Anropet på registrering av egenskap innbefatter derfor oppførselsbiter som identifiserer trinn i hvilke en verdi for egenskapen blir søkt, slik som arv, egenskapsark. I det ovennevnte anropseksempel indikerer oppfør-selsbitene "0x3" at en lokal verdi, et egenskapsark og arv blir søkt for å bestemme verdien av den vedføyde egenskap. I henhold til en utførelsesform kan således tolkningen avdisse egenskapsbitene kodes innenfor den statiske GetValue()-metode. Alternativt kan bestemmelsen av disse trinnene tilveiebringes ved hjelp av et uttrykk som modellerer relasjoner mellom egenskaper på formell måte.
I henhold til en utførelsesform kan koden for en vedføyd klasse ha den form som er angitt i tabell 1.
I koden ovenfor er den vedføyde egenskap ved navn "Bar" (stolpe) definert med vedføyd klasse "BarProvider" (stolpeleverandør). Det vedføyde egenskapsnavn "Bar" er definert med en datatype som streng og kan bare tilføyes knapp-objekter (Button-objects). De statiske metoder er sterkt typebestemte og tillater tilgang til egenskapen og innstilling av egenskapen.
Når den vedføyde egenskap er blitt registrert, kan SetValue()- og GetValue()-funksjonene utføres. Fig. 5 er et logisk flytskjema som illustrerer en prosess for innstilling av en verdi i samsvar med foreliggende oppfinnelse. Prosessen begynner ved blokk 501 hvor sett-funksjonen er blitt innledet for å endre en verdi assosiert med en eller annen egenskap. Generelt vil SetValue-prosessen 500 lagre verdien lokalt for en egenskap av interesse (heretter kalt den interessante egenskap). Behandlingen fortsetter ved beslutningsblokk 502.
Ved beslutningsblokk 502 blir det tatt en bestemmelse med hensyn til om det finnes et lokalt lager for den interessante egenskap. Fordi foreliggende oppfinnelse ikke automatisk har et lager for hver egenskap for hvert tilfelle av et objekt, blir, hvis den interessante egenskap ikke tidligere har hatt en verdi som er lagret, et lager tildelt (blokk 504). Når lageret er blitt tildelt, fortsetter behandlingen til blokk 506, slik den ville ha gjort hvis den hadde detektert et lokalt lager ved beslut-ningsblokken 502.
Ved blokk 506 blir verdien kopiert inn i det lager som er tilknyttet den interessante egenskap. Når den interessante egenskap har endret tilstander, blir meld-inger sendt om tilstandsendringen (blokk 508). I henhold til en utførelsesform kan denne meldingen innebære å sette en "uren" bit for å indikere, i forbindelse med avhengige egenskaper, at deres tilstand kanskje ikke lenger er gyldig. Alternativt kan varslingen eller meldingen innebære å rapportere til hver avhengig, at en kilde er endret, som beskrevet i ovennevnte patentsøknad. Behandlingen fortsetter ved beslutningsblokk 510.
Ved beslutningsblokk 510 blir det tatt en bestemmelse med hensyn til om en verdi var lagret i hurtigbufferet for den interessante egenskap. Hvis det ikke er noen verdi i hurtigbufferet for den interessante egenskap, slutter prosessen. Hvis det imidlertid er en verdi i hurtigbufferet, blir hurtigbufferet slettet (blokk 512), fordi denne verdien ikke lenger er gyldig. Prosessen slutter så.
Fig. 6 er et logisk flytskjema som illustrerer en prosess for å innhente en verdi i samsvar med foreliggende oppfinnelse. Behandlingen begynner ved blokk 601 hvor undersøkelsen er blitt innledet. Behandlingen fortsetter ved blokk 602.
Ved blokk 602 indikerer applikasjonen at en av egenskapene som er av interesse (heretter kalt en interessant egenskap) må oppdateres. Vanligvis kan dette inntreffe når et objekt etterspør egenskaper for sin aktuelle tilstand. Prosessen 600 bestemmer en verdi for egenskapen ved å kontrollere forskjellige trinn. Disse trinnene blir definert når egenskapen registreres. Beslutningsblokkene 606-610 representerer eksempler på trinn, men andre trinn kan tilføyes uten å avvike fra foreliggende oppfinnelse. Behandlingen fortsetter ved beslutningsblokk 604.
Ved beslutningsblokk 604 kontrollerer prosessen hurtigbufferet for å bestemme om den interessante egenskap tidligere er blitt hurtigbufret. Interessante egenskaper blir typisk hurtigbufret for å optimalisere innhenting. Hvis egenskapen tidligere er blitt hurtigbufret, fortsetter prosessen ved blokk 612, hvor verdien blir innhentet fra hurtigbufferet. Alternativt fortsetter prosessen ved beslutningsblokk 606. Ved beslutningsblokk 606 blir det tatt en bestemmelse om verdien til den interessante egenskap er lokal. Verdien vil være lokal hvis en SetValue() er blitt ut-ført for å fastsette en verdi lokalt for egenskapen, som beskrevet i forbindelse med fig. 5. Hvis verdien er lokal, fortsetter prosessen ved blokk 612, hvor verdien blir innhentet fra det lokale lager. Hvis verdien ikke er lokal, fortsetter prosessen ved beslutningsblokk 608.
Ved beslutningsblokk 608 blir det tatt en bestemmelse med hensyn til om verdien av den interessante egenskap er tilgjengelig på et egenskapsark. Når en basisklasse har et tilordnet egenskapsark, spesifiserer egenskapsarket hvor hver av døtrene til basisklassen vil bli gjengitt ved initialisering. Hvis den interessante egenskap er tilgjengelig på et egenskapsark, fortsetter behandlingen ved beslutningsblokk 610.
Ved beslutningsblokk 610 blir det tatt en bestemmelse med hensyn til om verdien av den interessante egenskap kan fremskaffes ved hjelp av arv (dvs. en
arvet verdi). Arvede verdier er utledet fra et morobjekt til datterobjektet. Hvis et av morobjektene har den interessante egenskap, fortsetter behandlingen til blokk 612 hvor verdien blir innhentet fra morobjektet. Hvis imidlertid verdien ikke er arvet, blir en normalverdi fra den vedføyde klasse som er tilordnet den vedføyde egenskap, innhentet (blokk 614). Behandlingen fortsetter ved blokk 616.
Ved blokk 616 beregner applikasjonen et vektmål basert på det trinn der verdien ble mottatt. Vektmålet blir lagret og brukt til å foreta innlærte beslutninger om hvilke interessante egenskaper som skal hurtigbufres for å optimalisere frem-tidige innhentinger. Behandlingen slutter deretter.
I tillegg til SetValue- og GetValue-prosessene som er beskrevet ovenfor, tilveiebringer programmeringsmodellen i henhold til foreliggende oppfinnelse, for-bedrede funksjoner, slik som gruppeforespørsler eller gruppevarsler. Som beskrevet tilveiebringer derfor foreliggende oppfinnelse en programmeringsmodell som fremskaffer et avhengighetsbasert egenskapssystem som understøtter komplekse relasjoner mellom egenskaper ved anvendelsen av vedføyde klasser. Applikasjoner som er oppbygd ved å bruke denne programmeringsmodellen, kan meget vel skaleres, fordi teknikken med egenskapsstyring ikke krever altfor stor lokal, ved-varende lagringsplass. I stedet gjenbruker programmeringsmodellen egenskapsverdier, slik som ved bruk av egenskapsark og arv ved basisklasse-nivå. Som beskrevet ovenfor, tilveiebringer foreliggende oppfinnelse en mekanisme for egen-skapsforvaltning hvorved objekter i objekthierarkiet lagrer egenskapsverdier gjennom vedlegg.
Spesifikasjonen, eksemplene og dataene som er angitt ovenfor, gir en fullstendig beskrivelse av fremstillingen og bruken av oppfinnelsens sammensetning. Siden mange utførelsesformer av oppfinnelsen kan gjøres uten å avvike fra oppfinnelsens ramme, befinner oppfinnelsen seg innenfor rammen av de vedføyde patentkrav.

Claims (29)

1. Datamaskin-lesbart medium med datamaskin-utførbare instruksjoner for å assosiere et objekt med en første egenskap med en andre egenskap i et andre objekt, karakterisert vedat instruksjonene når de utføres utfører en metode omfattende: å identifisere det andre objektet, hvor den andre egenskap er assosiert med en første parameter i det andre objektet; å assosiere den andre egenskap med det første objektet uten å spesifisere en eksplisitt referanse til den første egenskap i det første objektet. å beregne et vektmål basert på plasseringen av den første parameteren; å hurtigbufre den andre egenskap basert på vektmålet; og å initialisere det første objektet med den første parameteren.
2. Datamaskin-lesbart medium ifølge krav 1, hvor assosieringen understøtter en sterkt typebestemt syntaks.
3. Datamaskin-lesbart medium ifølge krav 1, hvor initialiseringen videre innbefatter innhenting av en verdi for den andre egenskapen fra et sted utenfor det første objektet.
4. Datamaskin-lesbart medium ifølge krav 3, hvor innhenting av verdien videre omfatter å bestemme hvilken av et antall trinn som inneholder den verdi som er assosiert med den andre egenskap.
5. Datamaskin-lesbart medium ifølge krav 4, hvor et trinn innbefatter et morobjekt for det første objektet.
6. Datamaskin-lesbart medium ifølge krav 4, hvor et trinn innbefatter et egenskapsark.
7. Datamaskin-lesbart medium ifølge krav 1, hvor assosieringen videre innbefatter å assosiere en annen parameter med det første objektet, ved å tilordne en verdi til den annen parameter, og hvor verdien lagres på et sted utenfor det første objektet.
8. Datamaskin-lesbart medium ifølge krav 1, hvor den første egenskap svarer til det første objektets oppførsel, og hvor den annen egenskap svarer til det første objektets utseende.
9. Datamaskin-lesbart medium med datamaskin-utførbare komponenter for å implementere en objektorientert klasseinitialisering, karakterisert ved: en basisklasse som innbefatter et antall egenskaper; og en vedføyd klasse som innbefatter et antall vedføyde egenskaper, hvor komponentene, når de utføres, utfører følgende: minst én av de vedføyde egenskaper assosieres med et tilfelle av et basisobjekt, basisobjektet initialiseres ved innhenting av en vedføyd egenskapsverdi uten å spesifisere en referanse til noen av basisegenskapene i basisklassen, idet den vedføyde egenskapen hurtigbufres basert på et vektmål som er beregnet basert på en plassering av den vedføyde egenskaps verdi.
10. Datamaskin-lesbart medium ifølge krav 9, hvor basisobjektet arver minst én metode fra en nodeklasse, hvor den ene metode blir påkalt av en statisk metode når den minst ene vedføyde egenskap assosieres med tilfellet av det tilhørende basisobjektet.
11. Datamaskin-lesbart medium ifølge krav 10, hvor den statiske metode og den minst ene metode hver innbefatter en første parameter for å videresende en unik identifikator for den ene vedføyde egenskap.
12. Datamaskin-lesbart medium ifølge krav 11, hvor den unike identifikator er tilgjengelig etter registrering av den minst ene vedføyde egenskap ved kjøring.
13. Datamaskin-lesbart medium ifølge krav 10, hvor den minst ene metode understøtter en løst typebestemt syntaks.
14. Datamaskin-lesbart medium ifølge krav 10, hvor den statiske metode understøtter en sterkt typebestemt syntaks.
15. Datamaskin-lesbart medium ifølge krav 9, hvor basisobjektet initialiseres ved å innhente en verdi for den vedføyde egenskapen fra et morobjekt forbundet med basisobjektet.
16. Datamaskin-lesbart medium ifølge krav 9, hvor basisobjektet initialiseres ved å innhente den vedføyde egenskaps verdi fra et egenskapsark.
17. Databehandlingssystem med et datamaskinlesbart medium som lagrer instruksjoner for å implementere en objektorientert klasseinitialisering,karakterisert ved: et første objekt utledet fra en første klasse, hvor det første objekt innbefatter et første sett med egenskaper; og en annen klasse innrettet for å vedføye en egenskap fra et annet sett med egenskaper til det første objekt som reaksjon på en operativ forespørsel assosiert med det første objekt uten å referere det første sett av egenskaper, hvor komponentene, når de utføres, utfører følgende: det første objekt initialiseres med den vedføyde egenskap fra det annet sett med egenskaper, og videre hvor den vedføyde egenskap hurtigbufres basert på et vektmål som beregnes basert på plasseringen til den vedføyde egenskapsverdi.
18. System ifølge krav 17, videre omfattende en første parameter innrettet for entydig å identifisere den vedføyde egenskap.
19. System ifølge krav 18, hvor den vedføyde egenskap er registrert før den første parameter entydig identifiserer den vedføyde egenskap.
20. Datamaskin-implementert fremgangsmåte for å assosiere et objekt med en første egenskap med en andre egenskap i et andre objekt, karakterisert ved: å identifisere en verdi som tilsvarer det andre objektet; å registrere den andre egenskap med det første objekt, hvor den andre egenskap er lagret på et sted utenfor det første objektet; å beregne et vektmål basert på en plassering av verdien; å hurtigbufre den andre egenskap basert på vektmålet; og å initialisere det første objektet med verdien.
21. Fremgangsmåte ifølge krav 20, hvor registreringen videre innbefatter å til-dele en unik identifikator til den andre egenskap.
22. Fremgangsmåte ifølge krav 21, videre omfattende å påkalle en statisk metode som har en første parameter, hvor den første parameter refererer til den unike identifikator.
23. Fremgangsmåte ifølge krav 22, hvor den statiske metode er sterkt typebestemt.
24. Fremgangsmåte ifølge krav 20, hvor det første objekt er assosiert med et datterobjekt, og videre hvor datterobjektet er assosiert med den annen egenskap.
25. Datamaskin-implementert system for å assosiere en vedføyd egenskap til et basisobjekt karakterisert ved: en prosessor; midler for å vedføye et vedføyd objekt til basisobjektet; midler for å identifisere den vedføyde egenskap i det vedføyde objekt; midler for å assosiere den vedføyde egenskap med basisobjektet uten å referere til en basisegenskap i basisobjektet; midler for å beregne et vektmål basert på plasseringen til en verdi som tilsvarer den vedføyde egenskap; midler for å hurtigbufre den vedføyde egenskap basert på vektmålet; og midler for å initialisere basisobjektet med verdien.
26. System ifølge krav 25, hvor midlene for å assosiere understøtter en sterkt typebestemt syntaks for et programmeringsspråk.
27. System ifølge krav 25, hvor midlene for å assosiere understøtter løst typebestemt syntaks for et programmeringsspråk.
28. System ifølge krav 25, hvor midlene for å assosiere omfatter et utsagn i et markeringsdokument.
29. System ifølge krav 25, hvor midlene for å assosiere omfatter et utsagn på et egenskapsark.
NO20032993A 2002-06-28 2003-06-27 System og fremgangsmate for a assosiere egenskaper til objekter NO331544B1 (no)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/187,012 US7055132B2 (en) 2002-06-28 2002-06-28 System and method for associating properties with objects

Publications (3)

Publication Number Publication Date
NO20032993D0 NO20032993D0 (no) 2003-06-27
NO20032993L NO20032993L (no) 2003-12-29
NO331544B1 true NO331544B1 (no) 2012-01-23

Family

ID=27733967

Family Applications (1)

Application Number Title Priority Date Filing Date
NO20032993A NO331544B1 (no) 2002-06-28 2003-06-27 System og fremgangsmate for a assosiere egenskaper til objekter

Country Status (20)

Country Link
US (1) US7055132B2 (no)
EP (1) EP1378828A3 (no)
JP (1) JP4365142B2 (no)
KR (1) KR100571466B1 (no)
CN (1) CN1470984B (no)
AU (1) AU2003204351B2 (no)
BR (1) BR0302032A (no)
CA (1) CA2427288C (no)
CO (1) CO5470295A1 (no)
HK (1) HK1060925A1 (no)
IL (1) IL155571A (no)
MX (1) MX342196B (no)
MY (1) MY133528A (no)
NO (1) NO331544B1 (no)
NZ (1) NZ525483A (no)
PL (1) PL360131A1 (no)
RU (1) RU2321882C2 (no)
SG (1) SG107142A1 (no)
TW (1) TWI287203B (no)
ZA (1) ZA200303345B (no)

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030236764A1 (en) * 2002-06-19 2003-12-25 Lev Shur Data architecture to support shared data resources among applications
US6986123B2 (en) * 2002-06-28 2006-01-10 Microsoft Corporation Extensible on-demand property system
JP2004234158A (ja) * 2003-01-29 2004-08-19 Sony Corp 情報処理装置、およびコンテンツ管理方法、コンテンツ情報管理方法、並びにコンピュータ・プログラム
US20040167894A1 (en) * 2003-02-21 2004-08-26 Sap Ag Method for using a business model data interface
US7505987B2 (en) * 2003-05-13 2009-03-17 Microsoft Corporation Method and system for providing interface defaults
US7685581B2 (en) * 2003-06-27 2010-03-23 Microsoft Corporation Type system for representing and checking consistency of heterogeneous program components during the process of compilation
US7120898B2 (en) * 2003-06-26 2006-10-10 Microsoft Corporation Intermediate representation for multiple exception handling models
US7086041B2 (en) * 2003-06-27 2006-08-01 Microsoft Corporation Extensible type system for representing and checking consistency of program components during the process of compilation
US7305666B2 (en) * 2003-07-23 2007-12-04 Microsoft Corporation Description language for an extensible compiler and tools infrastructure
US7559050B2 (en) * 2003-06-30 2009-07-07 Microsoft Corporation Generating software development tools via target architecture specification
US7707566B2 (en) * 2003-06-26 2010-04-27 Microsoft Corporation Software development infrastructure
US7788652B2 (en) * 2003-06-27 2010-08-31 Microsoft Corporation Representing type information in a compiler and programming tools framework
US7676798B2 (en) * 2003-10-24 2010-03-09 Microsoft Corporation Mechanism for obtaining and applying constraints to constructs within an interactive environment
US7543286B2 (en) * 2003-11-18 2009-06-02 Microsoft Corporation Method and system for mapping tags to classes using namespaces
EP1915726A4 (en) 2004-06-18 2009-10-28 Sap Ag COHERENT SET OF INTERFACES DERIVED FROM A COMMERCIAL OBJECT MODEL
US7802228B2 (en) * 2004-08-19 2010-09-21 Microsoft Corporation Systems and methods for varying software build properties using primary and supplemental build files
US8631347B2 (en) * 2004-11-15 2014-01-14 Microsoft Corporation Electronic document style matrix
US7844956B2 (en) * 2004-11-24 2010-11-30 Rojer Alan S Object-oriented processing of markup
US20060130038A1 (en) * 2004-12-15 2006-06-15 Claussen Christopher S Apparatus, system, and method for facilitating dynamic modification of existing software objects defined in a strongly-typed programming language
CA2490645A1 (en) * 2004-12-16 2006-06-16 Ibm Canada Limited - Ibm Canada Limitee Data-centric distributed computing
JP4393404B2 (ja) * 2005-03-04 2010-01-06 株式会社東芝 データベース管理装置およびデータベース管理方法
US8332355B2 (en) * 2005-03-28 2012-12-11 Symantec Corporation Method and apparatus for generating readable, unique identifiers
US20070061349A1 (en) * 2005-09-15 2007-03-15 Microsoft Corporation Hierarchically describing shapes
US8001526B2 (en) * 2005-09-15 2011-08-16 Microsoft Corporation Hierarchical property storage
US20070061351A1 (en) * 2005-09-13 2007-03-15 Microsoft Corporation Shape object text
WO2008005102A2 (en) 2006-05-13 2008-01-10 Sap Ag Consistent set of interfaces derived from a business object model
US20080077849A1 (en) * 2006-09-27 2008-03-27 Adams Gregory D Mechanism for associating annotations with model items
US8321853B2 (en) * 2007-05-11 2012-11-27 Microsoft Corporation Type and property definition support for software
CA2607537A1 (en) * 2007-10-22 2009-04-22 Ibm Canada Limited - Ibm Canada Limitee Software engineering system and method for self-adaptive dynamic software components
US8417593B2 (en) 2008-02-28 2013-04-09 Sap Ag System and computer-readable medium for managing consistent interfaces for business objects across heterogeneous systems
US20090326988A1 (en) 2008-06-26 2009-12-31 Robert Barth Managing consistent interfaces for business objects across heterogeneous systems
US8245144B2 (en) * 2008-06-27 2012-08-14 Microsoft Corporation Object model for a user interface
US8195692B2 (en) 2008-12-11 2012-06-05 International Business Machines Corporation System and method for managing semantic and syntactic metadata
US20100153297A1 (en) 2008-12-12 2010-06-17 Sap Ag Managing Consistent Interfaces for Credit Portfolio Business Objects Across Heterogeneous Systems
US8576218B2 (en) * 2008-12-18 2013-11-05 Microsoft Corporation Bi-directional update of a grid and associated visualizations
US8473905B1 (en) * 2009-09-30 2013-06-25 Emc Corporation Managing user interface characteristics in displaying data storage systems information
US8396751B2 (en) 2009-09-30 2013-03-12 Sap Ag Managing consistent interfaces for merchandising business objects across heterogeneous systems
US9135585B2 (en) * 2010-06-15 2015-09-15 Sap Se Managing consistent interfaces for property library, property list template, quantity conversion virtual object, and supplier property specification business objects across heterogeneous systems
US8732083B2 (en) 2010-06-15 2014-05-20 Sap Ag Managing consistent interfaces for number range, number range profile, payment card payment authorisation, and product template template business objects across heterogeneous systems
JP5279767B2 (ja) * 2010-06-29 2013-09-04 ヤフー株式会社 統括プログラム
US9342274B2 (en) 2011-05-19 2016-05-17 Microsoft Technology Licensing, Llc Dynamic code generation and memory management for component object model data constructs
US8725654B2 (en) 2011-07-28 2014-05-13 Sap Ag Managing consistent interfaces for employee data replication business objects across heterogeneous systems
US8601490B2 (en) 2011-07-28 2013-12-03 Sap Ag Managing consistent interfaces for business rule business object across heterogeneous systems
US8775280B2 (en) 2011-07-28 2014-07-08 Sap Ag Managing consistent interfaces for financial business objects across heterogeneous systems
US8984050B2 (en) 2012-02-16 2015-03-17 Sap Se Consistent interface for sales territory message type set 2
US8762453B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for feed collaboration group and feed event subscription
US9237425B2 (en) 2012-02-16 2016-01-12 Sap Se Consistent interface for feed event, feed event document and feed event type
US8762454B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for flag and tag
US8756274B2 (en) 2012-02-16 2014-06-17 Sap Ag Consistent interface for sales territory message type set 1
US9232368B2 (en) 2012-02-16 2016-01-05 Sap Se Consistent interface for user feed administrator, user feed event link and user feed settings
US8756135B2 (en) 2012-06-28 2014-06-17 Sap Ag Consistent interface for product valuation data and product valuation level
US8949855B2 (en) 2012-06-28 2015-02-03 Sap Se Consistent interface for address snapshot and approval process definition
US9367826B2 (en) 2012-06-28 2016-06-14 Sap Se Consistent interface for entitlement product
US9246869B2 (en) 2012-06-28 2016-01-26 Sap Se Consistent interface for opportunity
US8615451B1 (en) 2012-06-28 2013-12-24 Sap Ag Consistent interface for goods and activity confirmation
US9400998B2 (en) 2012-06-28 2016-07-26 Sap Se Consistent interface for message-based communication arrangement, organisational centre replication request, and payment schedule
WO2014000200A1 (en) 2012-06-28 2014-01-03 Sap Ag Consistent interface for document output request
US9557974B2 (en) * 2012-07-10 2017-01-31 Oracle International Corporation System and method for supporting compatibility checking for lambda expression
US9043236B2 (en) 2012-08-22 2015-05-26 Sap Se Consistent interface for financial instrument impairment attribute values analytical result
US9076112B2 (en) 2012-08-22 2015-07-07 Sap Se Consistent interface for financial instrument impairment expected cash flow analytical result
US9547833B2 (en) 2012-08-22 2017-01-17 Sap Se Consistent interface for financial instrument impairment calculation
US9191343B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for appointment activity business object
US9191357B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for email activity business object
US9430452B2 (en) 2013-06-06 2016-08-30 Microsoft Technology Licensing, Llc Memory model for a layout engine and scripting engine

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5187786A (en) 1991-04-05 1993-02-16 Sun Microsystems, Inc. Method for apparatus for implementing a class hierarchy of objects in a hierarchical file system
US6378003B1 (en) * 1993-04-05 2002-04-23 International Business Machines Corporation Method and system for deriving metaclasses in an object oriented system
US5732271A (en) * 1995-01-23 1998-03-24 International Business Machines Corporation Data processing system and method for processing an object oriented development environment employing property inheritance using prototypical objects
US5635693A (en) * 1995-02-02 1997-06-03 International Business Machines Corporation System and method for tracking vehicles in vehicle lots
US5778227A (en) 1995-08-01 1998-07-07 Intergraph Corporation System for adding attributes to an object at run time in an object oriented computer environment
US6230159B1 (en) 1997-04-30 2001-05-08 Microsoft Corporation Method for creating object inheritance
US6191790B1 (en) * 1998-04-01 2001-02-20 Microsoft Corporation Inheritable property shading system for three-dimensional rendering of user interface controls
US6083276A (en) * 1998-06-11 2000-07-04 Corel, Inc. Creating and configuring component-based applications using a text-based descriptive attribute grammar
US6336211B1 (en) 1999-05-20 2002-01-01 Xilinx, Inc. Method and apparatus for implementing type-safe heterogeneous property lists
US20010029604A1 (en) 2001-04-27 2001-10-11 Jacob Dreyband Descriptive data construct mapping method and apparatus
US20040088448A1 (en) * 2001-10-16 2004-05-06 Userspace Corporation Embedded system and method for controlling, monitoring of instruments or devices and processing their data via control and data protocols that can be combined or interchanged

Also Published As

Publication number Publication date
AU2003204351B2 (en) 2009-11-12
JP4365142B2 (ja) 2009-11-18
HK1060925A1 (en) 2004-08-27
CA2427288C (en) 2011-08-16
MXPA03005356A (es) 2004-10-29
CN1470984B (zh) 2012-12-12
BR0302032A (pt) 2004-08-24
TWI287203B (en) 2007-09-21
KR100571466B1 (ko) 2006-04-17
RU2003119525A (ru) 2005-01-10
ZA200303345B (en) 2004-04-22
EP1378828A3 (en) 2006-12-13
CO5470295A1 (es) 2004-12-30
NZ525483A (en) 2004-10-29
EP1378828A2 (en) 2004-01-07
US7055132B2 (en) 2006-05-30
US20040002991A1 (en) 2004-01-01
SG107142A1 (en) 2004-11-29
KR20040002784A (ko) 2004-01-07
CA2427288A1 (en) 2003-12-28
MY133528A (en) 2007-11-30
JP2004038958A (ja) 2004-02-05
AU2003204351A1 (en) 2004-01-22
CN1470984A (zh) 2004-01-28
RU2321882C2 (ru) 2008-04-10
NO20032993D0 (no) 2003-06-27
MX342196B (es) 2016-09-20
IL155571A0 (en) 2003-11-23
NO20032993L (no) 2003-12-29
TW200408979A (en) 2004-06-01
IL155571A (en) 2008-11-03
PL360131A1 (en) 2003-12-29

Similar Documents

Publication Publication Date Title
NO331544B1 (no) System og fremgangsmate for a assosiere egenskaper til objekter
US6681386B1 (en) Method, system, and program for parameter expansion, generation, and execution of scripts in a networked environment
US7661091B2 (en) Extensible on-demand property system
US6366876B1 (en) Method and apparatus for assessing compatibility between platforms and applications
US5860011A (en) Method and system for automatically checking computer source code quality based on rules
US7930685B2 (en) Method and system for providing a version-independent interface
US6976144B1 (en) Methods and apparatus for digital data processing with mutable inheritance
US20070168965A1 (en) Configuration inheritance in system configuration
US7055147B2 (en) Supporting interactions between different versions of software for accessing remote objects
JPH10154095A (ja) 多数ディレクトリサービスに一様にアクセスするための方法及びシステム
US20150020057A1 (en) Controlling application features
US8341523B2 (en) Method and system for providing multiple levels of help information for a computer program
US8250528B2 (en) Static inheritance systems and methods
JP4620112B2 (ja) モニター情報の収集方法
JP2012529711A (ja) ソフトウェア拡張子解析方法及びシステム
US8433729B2 (en) Method and system for automatically generating a communication interface
NO329240B1 (no) System og fremgangsmate for forklarende definering og bruk av undergrupper innenfor dokumentkoding
US7484204B2 (en) System and method for extensible type repositories
JP2013196453A (ja) 情報処理装置
Lee et al. Runtime System
KR20010105021A (ko) 통합 메시지 시스템을 위한 스크립트 구동 프레임워크 및운용 방법
WO2002044896A1 (en) Improved manageable object oriented software environment

Legal Events

Date Code Title Description
FC2A Withdrawal, rejection or dismissal of laid open patent application
ERR Erratum

Free format text: I PATENTTIDENDE NR. 06/06 BLE PATENTSOKNAD 20032993 FEILAKTIG KUNNGJORT HENLAGT. PATENTSOKNADEN ER FORTSATT UNDER BEHANDLING.

Free format text: I PATENTTIDENDE NR. 06/06 BLE PATENTSOKNAD 20032993 FEILAKTIG KUNNGJORT HENLAGT. PATENTSOKNADEN ER FORTSATT UNDER BEHANDLING

MM1K Lapsed by not paying the annual fees