Closure - Delphissä tunnetaan "procedureOfobject"

Closure - Delphissä tämä ohjelmointiin liittyvä konsepti tunnetaan nimellä "procedure of object".

Aika kauan on tullut tehtyä Delphi -koodausta, ennenkuin selvisi, että
Delphi -käyttäjäpiirin ulkopuolella samaa asiaa kutsutaan nimellä "Closure".

LAINAUS:
A far safer and simpler approach is to simply have the thread run what Delphi calls a procedure of object and C++Builder calls a closure
LAINAUS päättyy.

esimerkiksi Delphin TTimer -komponentti hyödyntää tätä ideaa:

TTimer -komponentissa on määritelty OnTimer -tapahtuma:

property OnTimer: TNotifyEvent;

ja tuo mainittu TNotifyEvent:

type
TNotifyEvent = procedure (Sender: TObject) of object;

Samaa TNotifyEvent -tapahtumatyyppiä on käytetty myös esim. TButton -komponentissa, jossa se suoritetaan aina, kun FORMilla olevaa nappia painetaan.

type
TfrmTestiohjelma_Mainform = class(TForm)
bnRunThread: TButton;
tmrCheckThrResults: TTimer;

procedure tmrCheckThrResultsTimer(Sender: TObject);

end;

// ... muuta koodia ...

procedure TfrmTestiohjelma_Mainform.tmrCheckThrResultsTimer
(Sender: TObject);
begin
if NOT TimesBufferReady
then Exit;

tmrCheckThrResults.Enabled := False;
bnRunThread.Enabled := True;

// ok:
ReportThrTimingResults;
end;

Ja tämä siis alunperin jo 1995 Delphi 1.0:ssa (joka jäi ainoaksi 16 -bittiseksi Delphiksi, uudemmat ovat 32 -bittisiä, ja kaikista uusimmista on olemassa myös 64 -bittinen versio).
Ilmianna
Jaa

20 Vastausta



Jos tuo on pascalin perusominaisuuksia jo yli 20 vuotta niin missä muussa sitä käytetään kuin peruspascal koodissa? Miksi sitä tarvitaan muissa kielissä?
Kommentoi
Ilmianna
Jaa
6 VASTAUSTA:
Kyllähän ohjelmoinnin peruskäsitteitä käytetään kielestä riippumatta. Kielien ominaisuuksissa vaan on eroa että jos jollekin asialle ei ole syntaksia niin se sitten tehdään jotenkin muuten.

Siitähän ei tule mitään, että pitäisi jotenkin rajoittua jonkun ohjelmointikielen rajoituksiin.
Kommentoi
Ilmianna
Jaa
Miksi jokin closure on tärkeä ominaisuus (jos asiat voi tehdä muutenkin)?
Kommentoi
Ilmianna
Jaa
closuree kirjoitti:
Miksi jokin closure on tärkeä ominaisuus (jos asiat voi tehdä muutenkin)?
Selkeämpi koodi vaikka.
Kommentoi
Ilmianna
Jaa
Mihin noita closure:ta käytetään?
Ovatko ne tavallisia?
Kommentoi
Ilmianna
Jaa
cloo kirjoitti:
Mihin noita closure:ta käytetään?
Ovatko ne tavallisia?
Lue nyt vaikka siitä: https://en.wikipedia.org/wiki/Closure_(computer_programming)
Kommentoi
Ilmianna
Jaa
cloo kirjoitti:
Mihin noita closure:ta käytetään?
Ovatko ne tavallisia?
Vähän Delphimäisempi näkökulma asiaan:

https://www.google.fi/?q=procedure+of+object&gws_rd=ssl

Tämän ansiosta esim. Delphin TButton -luokassa voidaan suorittaa koodia, joka EI sisälly TButton -luokkaan, kun nappia painetaan.

Vastaavasti esim. Delphin TTimer -luokassa voidaan suorittaa koodia, joka EI sisälly TTimer -luokkaan, kun aikaväli on kulunut.

Koska TButton ja TTimer ovat VCL -komponentteja, niin silloin yksinkertaisinta on se, että käsittelijä määritellään esim TForm1 -luokassa.

Mutta mikään ei toisaalta pakota käyttämään TForm -luokasta perittyä luokkaa tapahtumakäsittelijän sijaintipaikkana.

Eli yhtä hyvin

TButton -luokan OnClick -tapahtumakäsittelijä
tai
TTimer -luokan OnTimer -tapahtumakäsittelijä

voi sijaita muussakin luokassa, tosin jos tapahtumakäsittelijä sijaitsee muussa kuin TForm -luokasta perityssä luokassa, silloin Delphin IDE ei tarjoa mahdollisuutta asettaa käsittelijä suoraan Object Inspectorissa, vaan silloin tapahtumakäsittelijä täytyy asettaa ajonaikaisesti näin:

Timer1.OnTimer := MyClass.HandleTimer1;

tai

TButton1.OnClick := MyClass.HandleButton1Click;

Samaa voi toki soveltaa silloinkin, kun tapahtumakäsittelijä on määritelty suoraan vaikkapa TMyForm -luokassa.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Delhissä on anonyymi metodi tai nimetön funktio, yllämainittu ei sitä vielä ole.
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/anonymousmethods_xml.html
Kommentoi
Ilmianna
Jaa
1 VASTAUS:
Mihin anonyymia metodia käytetään?
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Miten sulkeumat ja anonyymit metodit liittyvät toisiinsa?
Ilmianna
Jaa
JA vielä tällainen yksityiskohta:

JAVAsta puuttuu tuo "procedure of object" -konsepti !

Tämä vaikeuttaa JAVA -ohjelmointia.

Mielelläni en koodaa JAVAlla (koska Delphi on joka suhteessa parempi, M-Karin päinvastaisista väitteistä huolimatta).

Mutta jos on ihan pakko koodata JAVAlla, se kannattaa tehdä LINUXissa, ei WINDOWSissa.

Miksikö?

Koska LINUXissa voi helposti tehdä jotain sellaista, mikä JAVAssa ei muuten olisi mahdollista:

Kun JAVAsta puuttuu aito IFDEF, mikä Delphissä on.

LINUXissa asian voi kuitankin kiertää:

käytä ln -s hakemisto aliasnimi.

Tämä luo symbolisen linkin.

KOSKA JAVAssa lähdekooditiedostot sijoitetaan tietyllä tavalla hakemistopuuhun, niin tuon ln -s -käyttömahdollisuus antaa tavan tehdä se, mitä muissa ohjelmointikielissä tehdään IFDEFiä käyttämällä.

Eli kun aitoa IFDEFiä ei JAVAssa ole, niin sitten annetaan 2 erilaista ln -s käskyä (siis vain 1 niistä kerrallaan) jos halutaan kääntää samasta lähdekoodista 2 erilaista versiota.

Toki se "väärä" ln -s käsky pitää kumota ennen sen toisen vaihtoehdon käyttöä.

Onnistunee rm -käskyllä tai sitten esim. Midnight Commanderilla (mc).

Kannattaa myös lukea Delphin oma help, hakusanaksi "procedure of object".

HUOM: Uudehko Windows ja vanhempi Delphi -yhdistelmä edellyttää, että käyt Microsoftin sivuilta erikseen lataamassa katseluohjelman vanhempien Delphien käyttämää winhelp -formaattia varten.

JOS esim. käytät Windows 7 ja Delphi 7, niin tuon winhelp -katseluohjelman puute aiheuttaa sen, ettei Delphi integroitu HELP -toiminto toimi.

Uudemmissa Delpheissä on sitten helppikin muuutettu uudempaan chm -formaattiin.

JOS help -katseluohjelman asennus ei onnistu, hätävarana voit käyttää internetin hakukonetta, hakukriteeriksi:

"procedure of object" embarcadero

Valmistajan sivuilta löytyy myös web -pohjainen dokumentointi Delphin moniin eri ominaisuuksiin.

Winhelp ja chm toimivat sielläkin, missä nettiyhteyttä ei ole.
Kommentoi
Ilmianna
Jaa
2 VASTAUSTA:
"JAVAsta puuttuu tuo "procedure of object" -konsepti !"

Vanhaa tietoa. Javaan tuli Lamda lausekkeet vuosia sitten ja niillä saa saa hoidettua saman.

"Mielelläni en koodaa JAVAlla (koska Delphi on joka suhteessa parempi"

Valhe. Delphillä et saa mitenkään niin siististi toteutettua REST API komponentttia.

Javalla saa siisteimmillään tehtyä .war tai .ear paketteja.

Javan taaksepäinyhteensopivuus ja vakaus on myös huippua.

"Mutta jos on ihan pakko koodata JAVAlla, se kannattaa tehdä LINUXissa, ei WINDOWSissa."

Linuxia käyttävät käyttöjärjestelmät ovat defacto asemassa konesaleissa, joten tietystikään mitään Windowsia ei käytetä palvelinohjelmointiin.

Käyttöliittymäpuolella taas standardointi taas semmoista, että koodi käännetään selaimessa ajettavaksi.

"Kun JAVAsta puuttuu aito IFDEF, mikä Delphissä on."

Sellaista ei tarvitse Javassa.

"HUOM: Uudehko Windows ja vanhempi Delphi -yhdistelmä edellyttää, että käyt Microsoftin sivuilta erikseen lataamassa katseluohjelman vanhempien Delphien käyttämää winhelp -formaattia varten."

Se vanha Winhelp formaatti on deprekoitu. Koko Winhelp ohjelma voi lakata toimimasta missä tahansa käyttöjärjestelmäpäivityksessä.

"Winhelp ja chm toimivat sielläkin, missä nettiyhteyttä ei ole."

Itseasiassa vanha .chm tiedostoformaatti on myös deprekoitu. Se on tuettuna Windows 7:ssa vielä mutta uudemmissa sen ei tarvitse toimia Microsoftin puolesta. Saa vapaasti hoitaa itse katseluohjelmat kun Microsoftin jutut lakkaa toimimasta.
Kommentoi
Ilmianna
Jaa
Mikähän kumma muuten riivaa Delphi väkeä kun kaikki jutut on jotain kivikautista ja deprekoitua?

Miksi ette saa päivitettyä mitään? Kyllä nyt pitäisi koodin kääntyä Delphi 10.2 versiolla sinne palvelimeen ja käyttöliittymän tupsahtaa nätisti sieltä selaimeen.

Niin ja se palvelimeen käännettävä pulikka toki pitäisi saada johonkin docker imageen ja sieltä pudotettua pilveen.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
"Kyllä nyt pitäisi koodin kääntyä Delphi 10.2 versiolla sinne palvelimeen ja käyttöliittymän tupsahtaa nätisti sieltä selaimeen."

M-Karilla tuntuu olevan uskontona ohjelmisto, jonka palvelinosa on jossain pilvipalvelussa, ja käyttöliittymä sitten HTML5/CSS/JavaScriptillä tehtynä selaimessa toimiva.

Olen ulkomailla törmännyt erittäin heikkolaatuisiin nettiyhteyksiin.

JOS Suomessakin alkavat nettiyhteydet pudota laadultaan erittäin heikkolaatuisiksi,
silloin alkaa Suomessakin aikakausi, jossa:

a) ne yritykset, joiden tietojärjestelmät on rakennettu M-Karin suosimalla selainkäyttöliittymä/palvelin-yhdistelmällä, menevät konkurssiin, kun myyntiä ei voi tehdä kun selainpohjainen kassajärjestelmä ei toimi.

b) ne yritykset, jossa on Delphillä tehty paikallinen ohjelma ja Delphin omalla VCL:llä tehty käyttöliittymä, niissä myynti toimii toimipa netti tai ei.

Oikein tehty DELPHI -koodi voidaan suunnitella jopa niin, että ohjelma toimii kyllä ilman nettiyhteyttäkin (tai heikkolaatuisella nettiyhteydellä), mutta aina, kun kunnollinen nettiyhteys on olemassa, esim. varastotilanne ja myyntiluvut päivitetään keskuspalvelimelle.
Näin itse tekisin Delphillä yrityksen tietojärjestelmän, eli hyödyntää nettiyhteyttä silloin kun sellainen on tarjolla, mutta toimii paikallisesti oikein silloinkin, kun nettiyhteyttä jonkin teknisen vian takia ei ole käytettävissä.

Ehkä pian näemme tuohon a -ryhmään kuuluvien yritysten konkurssiaallon, samaan aikaan kun em. b-ryhmään kuuluvat yritykset sen kun porskuttavat.
Kommentoi
Ilmianna
Jaa
6 VASTAUSTA:
Kieltämättä tuossa on pointtia. Nykyisin on katastrofitilanne heti kun tuotannon palvelin on jumissa, pahimmillaan se oli joku reilu 6 tuntia kun Nebulalla tuli joku rautavika. Näin itsekin tekisin että pilvestä otetaan data, sitä työstetään paikallisesti omalla koneella ja työnnetään valmis tulos takaisin sinne pilveen ja näin vaikka käyttöliittymä olisikin tehty vaikka JavaScriptilläkin.
Kommentoi
Ilmianna
Jaa
"M-Karilla tuntuu olevan uskontona ohjelmisto, jonka palvelinosa on jossain pilvipalvelussa, ja käyttöliittymä sitten HTML5/CSS/JavaScriptillä tehtynä selaimessa toimiva."

Käyttöliittymäosa joka sisältää käyttöliittymän ja edustakoodin, tulisi pitää eri laitteessa kuin palvelinosa ja koodi joka huolehtii tiedon tallennuksesta ja hausta.

Käyttöliittymäosan toteutukseen standardi on HTML5 joka toimii selaimessa. Natiivia toki voi käyttää myös jos standardilla tavalla ei pysty tekemään.

Palvelinosan ei tarvitse olla pilvipalvelussa vaan voi olla vaikka lähiverkossa jossain purkissa jos siltä tuntuu. Pääasia että ei sotke sitä päätelaitteisiin joissa käyttöliittymät. Vastahan tuolla toisessa ketjussa sai kuulla kauhutarinoita hitaasta toiminnasta, swappauksesta, minuutteja kestävästä kääntämisestä ja muusta kauheudesta.

"Olen ulkomailla törmännyt erittäin heikkolaatuisiin nettiyhteyksiin."

Ei käyttöliittymän ajaminen tarvitse nettiyhteyttä vaan se tiedon siirto.

"a) ne yritykset, joiden tietojärjestelmät on rakennettu M-Karin suosimalla selainkäyttöliittymä/palvelin-yhdistelmällä, menevät konkurssiin, kun myyntiä ei voi tehdä kun selainpohjainen kassajärjestelmä ei toimi."

Miksi ei toimisi? Ei sovelluksen toimintaa tarvitse tehdä riippuvaiseksi jatkuvasti toimivasta yhteydestä vaikka toimisi puhtaasti selaimella.

Tietystikin kassakoneessa tulee offline käyttö automaattisesti kun se sovellus on näppärää toimittaa jossain purkissa mikä integroituu maksupäätteen käteiskassan kanssa.

Tietysti voisi integroida samaan keskusyksikkööön kassakoneen käyttöliitttymän päätteen kanssa, jolloin kannattaa tehdä hybridisovellus. Siinä käyttöliittymä olisi edelleen sama selainkäyttöliittymä mutta olisi pätkä natiivikoodia jossa integroidaan maksupääte ja selainkomponentti mikä hoitaa käyttöliittymää. Hybriditoteutuksen tekniikan sanelee käytännössä maksupäätteen integrointivaihtoehdot. Selainkomponentin saa monellakin tavalla.

"b) ne yritykset, jossa on Delphillä tehty paikallinen ohjelma ja Delphin omalla VCL:llä tehty käyttöliittymä, niissä myynti toimii toimipa netti tai ei.

Delphin VCL on vanhentunut ja se lakkaa toimimasta itsekseen jonkun päivityksen myötä. Se toimii vähintään niin pitkään kuin kyseisen Delphiversion tuki kestää millä se on käännetty. VCL näivettyy pois kun Windows API:sta vaikka siivoillaan GDI:tä ja muuta vastaavaa muinaista. Se on epäselvää kuinka pitkään kestää enintään mutta kyllähän se on selvää, että pitää alkaa vanhaa koodia siirtelemään vielä kun ehtii.

Muista että Delphi kehityksessä veroton vuosikulu työkalulla on 1306€ vähintään + muut kulut kuten työasemat ja palkat, että johtuen VCL->Firemonkey siirtokuluista ja työkalun hinnasta pidän tuota aika huonona vaihtoehtona kassajärjestelmään. Soveltuvuutta kassajärjestelmään heikentää myös se jos alustana on Windows, koska Windows + Delphi on epävakaa yhdistelmä.

Kassajärjestelmissä, jotka juurikin toimii offlinena ja sulautettuna, on toivottavaa että ovat vakaita. Päivitysten tekemät muutokset voi tehdä ylläpidosta todella kallista.

Ihan tiedoksi vaan, Windows 10 IoT versiot toimivat vastaavalla tavalla kuin Pro versio, että uusi release puolen vuoden välein ja uuden version jälkeen 1v aikaa siirtää sulautetut vehkeet uudemmaksi. Deplhin lisensointikäytäntö näkyy olevan suunniteltu maksettavaksi vuosittain mutta siirtymäaikaa on sielläkin. Aktiivinen tuki kestää vuoden ja noita kaiketi harmonisoitu Windowsin kanssa. Tietysti Delphikehittäjät optimoivat omia ylläpitokulujaan eikä tosiaankaan lähde säätämään VCL:ää vaikka Direct2D:lle silloin kun Microsoft vetää GDI:ltä töpselit seinästä vaan suunnittelevat tukikäytäntönsä niin, että heidän tuki loppuisi samaan aikaan.

"Oikein tehty DELPHI -koodi voidaan suunnitella jopa niin, että ohjelma toimii kyllä ilman nettiyhteyttäkin (tai heikkolaatuisella nettiyhteydellä), mutta aina, kun kunnollinen nettiyhteys on olemassa, esim. varastotilanne ja myyntiluvut päivitetään keskuspalvelimelle."

Mitäs ihmeellistä tuossa on?

"Näin itse tekisin Delphillä yrityksen tietojärjestelmän, eli hyödyntää nettiyhteyttä silloin kun sellainen on tarjolla, mutta toimii paikallisesti oikein silloinkin, kun nettiyhteyttä jonkin teknisen vian takia ei ole käytettävissä."

Ei siihen Delphiä tarvita. Selaintekniikalla onnistuu ihan hyvin. Käytännössä transaktiot vain laitetaan logiin ja kun yhteys palaa niin ajetaan muutokset. Olennainen juttu tietysti se, että koko kantaa ei tosiaankaan kannata replikoida vaan kura yhteyden päässä pidetään osaa datasta jota käsitellään parhaillaan ja jonka muutokset tulee siellä päätteessä, ja kakussa on data joka on jo kirjattuna eikä muutu.

Siitä tulee kyllä sitten harmia helposti jos päätteessä tarvitaan lukea dataa jota samanaikaisesti muutetaan muualla ja tehdään muutoksia järjestelmään sen datan pohjalta. Jos se data ei päivity, saadaan kannan sisältöä korruptoitua.
Kommentoi
Ilmianna
Jaa
ex-delphisti kirjoitti:
Kieltämättä tuossa on pointtia. Nykyisin on katastrofitilanne heti kun tuotannon palvelin on jumissa, pahimmillaan se oli joku reilu 6 tuntia kun Nebulalla tuli joku rautavika. Näin itsekin tekisin että pilvestä otetaan data, sitä työstetään paikallisesti omalla koneella ja työnnetään valmis tulos takaisin sinne pilveen ja näin vaikka käyttöliittymä olisikin tehty vaikka JavaScriptilläkin.
"Nykyisin on katastrofitilanne heti kun tuotannon palvelin on jumissa, pahimmillaan se oli joku reilu 6 tuntia kun Nebulalla tuli joku rautavika. Näin itsekin tekisin että pilvestä otetaan data, sitä työstetään paikallisesti omalla koneella ja työnnetään valmis tulos takaisin sinne pilveen ja näin vaikka käyttöliittymä olisikin tehty vaikka JavaScriptilläkin."

Jos samaa dataa muokkaa useampi, ja tehdään muutoksia jotka ovat riippuvaisia siitä datasta mikä on noudettu päätteeseen, saadaan helposti data korruptoitua.

Siihenkin on algoritmeja että voidaan oikaista muutettu data oikeaksi. Versionhallintajärjestelmien käyttö on tässä suotavaa. Tietyissä operaatioissa kannattaa vaan ilmoittaa käyttäjälle, että homma ei onnistu ennen kuin yhteys palaa.

Sehän on periaatteessa se ja sama onko se rauta vika etänä vai paikallisesti, että kahdennus on sitä varten. Sen sijaan yhteys voi pätkiä ja yhteyden ongelmilta suojautumista varten voi sijoittaa lähiverkkoon paikallisen serverin ja osa logiikkaa siihen vaikka.
Kommentoi
Ilmianna
Jaa
ex-delphisti kirjoitti:
Kieltämättä tuossa on pointtia. Nykyisin on katastrofitilanne heti kun tuotannon palvelin on jumissa, pahimmillaan se oli joku reilu 6 tuntia kun Nebulalla tuli joku rautavika. Näin itsekin tekisin että pilvestä otetaan data, sitä työstetään paikallisesti omalla koneella ja työnnetään valmis tulos takaisin sinne pilveen ja näin vaikka käyttöliittymä olisikin tehty vaikka JavaScriptilläkin.
Tosiaankin äärimmäistä offlinekäyttöä varten sopiva tietokanta voisi olla, yllätys yllätys, Git. Kyllä siihen menisi key->value store.

Siinä voi data haarautua toisistaan erilleen ja ne voi yhdistää sitten hyväksymällä. Ei kyllä tosiaankaan sovi kaikkiin tilanteisiin ja useimmissa tilanteissa tarvitaan sitä, että kun tieto tallennetaan niin se on varmasti oikein ilman hyväksyntää. Täysi offline siis ei aina onnistu järkevästi.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Nykyisin on katastrofitilanne heti kun tuotannon palvelin on jumissa, pahimmillaan se oli joku reilu 6 tuntia kun Nebulalla tuli joku rautavika. Näin itsekin tekisin että pilvestä otetaan data, sitä työstetään paikallisesti omalla koneella ja työnnetään valmis tulos takaisin sinne pilveen ja näin vaikka käyttöliittymä olisikin tehty vaikka JavaScriptilläkin."

Jos samaa dataa muokkaa useampi, ja tehdään muutoksia jotka ovat riippuvaisia siitä datasta mikä on noudettu päätteeseen, saadaan helposti data korruptoitua.

Siihenkin on algoritmeja että voidaan oikaista muutettu data oikeaksi. Versionhallintajärjestelmien käyttö on tässä suotavaa. Tietyissä operaatioissa kannattaa vaan ilmoittaa käyttäjälle, että homma ei onnistu ennen kuin yhteys palaa.

Sehän on periaatteessa se ja sama onko se rauta vika etänä vai paikallisesti, että kahdennus on sitä varten. Sen sijaan yhteys voi pätkiä ja yhteyden ongelmilta suojautumista varten voi sijoittaa lähiverkkoon paikallisen serverin ja osa logiikkaa siihen vaikka.
"Sehän on periaatteessa se ja sama onko se rauta vika etänä vai paikallisesti, että kahdennus on sitä varten."

Niin nuo verkkohemmot on työpaikalla erikseen, minä en sitä puolta hoitele. Mutta tietääkseni Nebulalla pitäisi olla näitä "alueita" ja eri frontteja on 3 kpl käytössä, kuulemma pitäisi kestää jopa ydinpommin että silti toimii, mutta niinpä rautavika vaan tuli Nebulalla ja pätkäisi toiminnan useamman tunnin ajaksi =D

Kyllä vain joku versionhallinta, kuten Git pitäisi olla tuossa mainitsemassani paikallisessa datan muokkauksessa käytössä.
Kommentoi
Ilmianna
Jaa
"M-Karilla tuntuu olevan uskontona ohjelmisto, jonka palvelinosa on jossain pilvipalvelussa, ja käyttöliittymä sitten HTML5/CSS/JavaScriptillä tehtynä selaimessa toimiva.

Olen ulkomailla törmännyt erittäin heikkolaatuisiin nettiyhteyksiin."

Ei HTML5/javascript toteutus vaadi enää välttämättä pilvipalvelua taustalle. Backend:iä voi pyörittää paikallisestikin.

"JOS Suomessakin alkavat nettiyhteydet pudota laadultaan erittäin heikkolaatuisiksi,
silloin alkaa Suomessakin aikakausi, jossa"

Mihin tämä väite perustuu? Käsittääkseni nettyhteyksien toimintavarmuus ja nopeus on kehittynyt huimasti, jos vertaa vaikkapa 90-lukuun.

"a) ne yritykset, joiden tietojärjestelmät on rakennettu M-Karin suosimalla selainkäyttöliittymä/palvelin-yhdistelmällä, menevät konkurssiin, kun myyntiä ei voi tehdä kun selainpohjainen kassajärjestelmä ei toimi."

Katso eka vastaukseni.

"b) ne yritykset, jossa on Delphillä tehty paikallinen ohjelma ja Delphin omalla VCL:llä tehty käyttöliittymä, niissä myynti toimii toimipa netti tai ei."

Katso eka vastaukseni. Jos nettiä ei oo, niin sun VCL:kin toimii maksimissaa yhden toimipisteen putiikeissa. Toki toimii samoin kun selainsovelluskin, sillä erolla että selainsovellus toimii alustariippumattomasti.

"Oikein tehty DELPHI -koodi voidaan suunnitella jopa niin, että ohjelma toimii kyllä ilman nettiyhteyttäkin (tai heikkolaatuisella nettiyhteydellä), mutta aina, kun kunnollinen nettiyhteys on olemassa, esim. varastotilanne ja myyntiluvut päivitetään keskuspalvelimelle.
Näin itse tekisin Delphillä yrityksen tietojärjestelmän, eli hyödyntää nettiyhteyttä silloin kun sellainen on tarjolla, mutta toimii paikallisesti oikein silloinkin, kun nettiyhteyttä jonkin teknisen vian takia ei ole käytettävissä."

Eli kun nettiä ei oo niin keskusvaraston tilanne on sun oikein tehdyn delphi sovelluksessakin käyttökelvoton.

"Ehkä pian näemme tuohon a -ryhmään kuuluvien yritysten konkurssiaallon, samaan aikaan kun em. b-ryhmään kuuluvat yritykset sen kun porskuttavat."

Päinvastoin. Lyödäänkö vetoa?
Kommentoi
Ilmianna
Jaa
+Lisää kommentti

Vastaa alkuperäiseen viestiin

Closure - Delphissä tunnetaan "procedureOfobject"

Closure - Delphissä tämä ohjelmointiin liittyvä konsepti tunnetaan nimellä "procedure of object".

Aika kauan on tullut tehtyä Delphi -koodausta, ennenkuin selvisi, että
Delphi -käyttäjäpiirin ulkopuolella samaa asiaa kutsutaan nimellä "Closure".

LAINAUS:
A far safer and simpler approach is to simply have the thread run what Delphi calls a procedure of object and C++Builder calls a closure
LAINAUS päättyy.

esimerkiksi Delphin TTimer -komponentti hyödyntää tätä ideaa:

TTimer -komponentissa on määritelty OnTimer -tapahtuma:

property OnTimer: TNotifyEvent;

ja tuo mainittu TNotifyEvent:

type
TNotifyEvent = procedure (Sender: TObject) of object;

Samaa TNotifyEvent -tapahtumatyyppiä on käytetty myös esim. TButton -komponentissa, jossa se suoritetaan aina, kun FORMilla olevaa nappia painetaan.

type
TfrmTestiohjelma_Mainform = class(TForm)
bnRunThread: TButton;
tmrCheckThrResults: TTimer;

procedure tmrCheckThrResultsTimer(Sender: TObject);

end;

// ... muuta koodia ...

procedure TfrmTestiohjelma_Mainform.tmrCheckThrResultsTimer
(Sender: TObject);
begin
if NOT TimesBufferReady
then Exit;

tmrCheckThrResults.Enabled := False;
bnRunThread.Enabled := True;

// ok:
ReportThrTimingResults;
end;

Ja tämä siis alunperin jo 1995 Delphi 1.0:ssa (joka jäi ainoaksi 16 -bittiseksi Delphiksi, uudemmat ovat 32 -bittisiä, ja kaikista uusimmista on olemassa myös 64 -bittinen versio).

5000 merkkiä jäljellä

Peruuta