procedure of object

Onko Delphissä myös "function of object"?

Jos ei, niin onpa onnetonta.

Jos on, niin sijoitusta ei voi hoitaa syntaksilla

X := FunctionNimi;

koska eikös se kutsu funktiota FunktionNimi ja sijoita X:ään sen paluuarvon, vaikka haluttaisiin sijoittaa itse funktio?

Saisko tästä vähän täydellisemmän esimerkin.
Mielellään lähes pienen ohjelman palasen verran

miksi miksi kirjoitti:

Onko Delphissä myös "function of object"?

Jos ei, niin onpa onnetonta.

Jos on, niin sijoitusta ei voi hoitaa syntaksilla

X := FunctionNimi;

koska eikös se kutsu funktiota FunktionNimi ja sijoita X:ään sen paluuarvon, vaikka haluttaisiin sijoittaa itse funktio?

X := @FunctionNimi

function FunctionNimi:integer of object

Saisko vähän täydellisemmän... kirjoitti:

Saisko tästä vähän täydellisemmän esimerkin.
Mielellään lähes pienen ohjelman palasen verran

Delphissä on kyllä vastaavanlainen rakenne function ... of object kuin procedure ... of objectkin on.

Mutta jo kauan sitten eli 1995-1996 delphi 1-2:n aikoihin, tultiin siihen lopputulokseen, että tapahtumakäsittelijät (event handler) tulee olla proseduureja, ei funktioita.

Näinollen, vaikka function ... of object on periaatteessa mahdollinen rakenne (ja kääntäjäkin sen kyllä hyväksyy), niin sitä ei tulisi käyttää.

Perusteluja saattaoi olla useampiakin, mutta itse muistan vain yhden (googlettamalla saattaa löytyä muitakin perusteluja):

Tyhjän tapahtumakäsittelijän pitäisi vaikuttaa samalla tavalla kuin se, ettei tapahtumakäsittelijää ole lainkaan.

Funktioissa tämän säännön noudattaminen on mahdotonta, koska funktiolla ei ole oletuspaluuarvoa, vaan funktiossa paluuarvon määrittämättä jättäminen on virhe.

Ja jos annat jonkin paluuarvon, funktio ei ole enää tyhjä.

Jos oikein muistan, niin historiallisista syistä delphin VCL:stä löytyy yksi tapahtumakäsittelijä, joka on funktio. Lisää ei siis ole syytä tehdä.

Oikeampi tapa on siis tämä:

TBooleanEvent = procedure (Sender:TObject; var B:Boolean) of object;

tällaista määrittelyä käyttävä luokka siis, samalla, kun testaa, ettei käsittelyrutiinin arvo ole NIL (testataan assigned() -funktiolla). niin alustaa tuon arvon B haluttuun oletusarvoon ennen käsittelijän kutsumista jos käsittelijä NIL.

Myös kutsuvan luokan välittäminen Sender -parametrillä kuuluu hyviin tapoihin, jollei ole painavaa syytä sen poisjättämiseen.

miksikö "of object" ?

Delphissä jokaisen tyypin täytyy olla tarkkaan määritelty.

tuo "of object" siis kertoo, että tapahtuman käsittelevä proseduuri on metodi, eli siis luokan jäsenproseduuri, ei itsenäinenn proseduuri.

Tämä on käsittelijän teknisen toteutuksen kannalta tärkeä määritellä.

Pelkkä procedure tässä (ilman "of object" -määrettä) vaatisi tilaa 4 tavua (= osoitin proseduurin alkuosoitteeseen).

vastaava metodikutsumääritys ("of object" -määreen kanssa) vaatii 8 tavua (= 4 tavua kuten edellä ja toiset 4 tavua osoitin olion ilmentymään = instance, jälkimmäinen tunnetaan myös nimellä Self, Javassa vastaava on "this").

em. tavumäärät koskevat 32 -bittisiä Delphin versioita. Jos Delphistä tulee (tai on jo olemassa) 64 -bittinen versio, niin olettaisin tämän tuplaavan em. tavumäärät.

Delphin ainoa 16-bittinen versio on Delphi 1.0, joka ilmestyi 1995. Sillä tehdyt EXE:t ja .DLL:t toimivat windowseissa windows 95 .. windows XP.

Delphi 2.0:sta alkaen Delphi on tuottanut 32 -bittisiä binääriohjelmia, joten ne toimivat myös Vistassa.

Tähän voi Vistan käyttäjä törmätä siksi, että moni asennusohjelma on käännetty Delphi 1.0:lla 16 -bittiseksi, koska se saadaan siten pienemmäksi.

16 -bittiset ohjelmat siis *eivät* toimi Vistassa.
Delphi 1.0:lla tehdyt ohjelmat on siis Vistaa varten käännettävä uudelleen Delphi 2.0:lla tai uudemmalla.

miksi miksi kirjoitti:

Onko Delphissä myös "function of object"?

Jos ei, niin onpa onnetonta.

Jos on, niin sijoitusta ei voi hoitaa syntaksilla

X := FunctionNimi;

koska eikös se kutsu funktiota FunktionNimi ja sijoita X:ään sen paluuarvon, vaikka haluttaisiin sijoittaa itse funktio?

Kerroppa miksi se on tärkeää?

delphiguru kirjoitti:

Delphissä on kyllä vastaavanlainen rakenne function ... of object kuin procedure ... of objectkin on.

Mutta jo kauan sitten eli 1995-1996 delphi 1-2:n aikoihin, tultiin siihen lopputulokseen, että tapahtumakäsittelijät (event handler) tulee olla proseduureja, ei funktioita.

Näinollen, vaikka function ... of object on periaatteessa mahdollinen rakenne (ja kääntäjäkin sen kyllä hyväksyy), niin sitä ei tulisi käyttää.

Perusteluja saattaoi olla useampiakin, mutta itse muistan vain yhden (googlettamalla saattaa löytyä muitakin perusteluja):

Tyhjän tapahtumakäsittelijän pitäisi vaikuttaa samalla tavalla kuin se, ettei tapahtumakäsittelijää ole lainkaan.

Funktioissa tämän säännön noudattaminen on mahdotonta, koska funktiolla ei ole oletuspaluuarvoa, vaan funktiossa paluuarvon määrittämättä jättäminen on virhe.

Ja jos annat jonkin paluuarvon, funktio ei ole enää tyhjä.

Jos oikein muistan, niin historiallisista syistä delphin VCL:stä löytyy yksi tapahtumakäsittelijä, joka on funktio. Lisää ei siis ole syytä tehdä.

Oikeampi tapa on siis tämä:

TBooleanEvent = procedure (Sender:TObject; var B:Boolean) of object;

tällaista määrittelyä käyttävä luokka siis, samalla, kun testaa, ettei käsittelyrutiinin arvo ole NIL (testataan assigned() -funktiolla). niin alustaa tuon arvon B haluttuun oletusarvoon ennen käsittelijän kutsumista jos käsittelijä NIL.

Myös kutsuvan luokan välittäminen Sender -parametrillä kuuluu hyviin tapoihin, jollei ole painavaa syytä sen poisjättämiseen.

miksikö "of object" ?

Delphissä jokaisen tyypin täytyy olla tarkkaan määritelty.

tuo "of object" siis kertoo, että tapahtuman käsittelevä proseduuri on metodi, eli siis luokan jäsenproseduuri, ei itsenäinenn proseduuri.

Tämä on käsittelijän teknisen toteutuksen kannalta tärkeä määritellä.

Pelkkä procedure tässä (ilman "of object" -määrettä) vaatisi tilaa 4 tavua (= osoitin proseduurin alkuosoitteeseen).

vastaava metodikutsumääritys ("of object" -määreen kanssa) vaatii 8 tavua (= 4 tavua kuten edellä ja toiset 4 tavua osoitin olion ilmentymään = instance, jälkimmäinen tunnetaan myös nimellä Self, Javassa vastaava on "this").

em. tavumäärät koskevat 32 -bittisiä Delphin versioita. Jos Delphistä tulee (tai on jo olemassa) 64 -bittinen versio, niin olettaisin tämän tuplaavan em. tavumäärät.

Delphin ainoa 16-bittinen versio on Delphi 1.0, joka ilmestyi 1995. Sillä tehdyt EXE:t ja .DLL:t toimivat windowseissa windows 95 .. windows XP.

Delphi 2.0:sta alkaen Delphi on tuottanut 32 -bittisiä binääriohjelmia, joten ne toimivat myös Vistassa.

Tähän voi Vistan käyttäjä törmätä siksi, että moni asennusohjelma on käännetty Delphi 1.0:lla 16 -bittiseksi, koska se saadaan siten pienemmäksi.

16 -bittiset ohjelmat siis *eivät* toimi Vistassa.
Delphi 1.0:lla tehdyt ohjelmat on siis Vistaa varten käännettävä uudelleen Delphi 2.0:lla tai uudemmalla.

Viekö 32-bittisessä versiossa normaali
olion/luokan procedure
( esim tälläinen määrittely:
procedure TForm1.HuhHuh(a:integer);
) sitten myös 8 tavua (2*4 tauva)?

MKkysyjä kirjoitti:

Viekö 32-bittisessä versiossa normaali
olion/luokan procedure
( esim tälläinen määrittely:
procedure TForm1.HuhHuh(a:integer);
) sitten myös 8 tavua (2*4 tauva)?

Siis tuo 4 tai 8 tavua kuluu viittaukseen:

4 tavua, kun viitataan proseduuriin proseduraalimuuttujalla, ja

8 tavua, kun viitataan luokan metodiin metodimuuttujalla (siis of object -määrettä käyttäen).

Ilman erillisviitettä metodiin, en ymmärrä kysymystäsi, mutta huomaa:

Delphissä on valikkokohta:

View / Debug Windows / CPU

Tuolta voit askeltaa ohjelmaasi konekielikäsky kerrallaan ja seurata millaista koodia Delphi tuottaa kääntäessään ohjelmasi konekielelle.