Closure - Delphissä tunnetaan "procedureOfobject"

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.

Miksi jokin closure on tärkeä ominaisuus (jos asiat voi tehdä muutenkin)?

closuree kirjoitti:

Miksi jokin closure on tärkeä ominaisuus (jos asiat voi tehdä muutenkin)?

Selkeämpi koodi vaikka.

Mihin noita closure:ta käytetään?
Ovatko ne tavallisia?

cloo kirjoitti:

Mihin noita closure:ta käytetään?
Ovatko ne tavallisia?

Lue nyt vaikka siitä: https://en.wikipedia.org/wiki/Closure_(computer_programming)

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.

Mihin anonyymia metodia käytetään?

"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.

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.

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.

"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.

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.

Lue lisää

"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.

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.

Lue lisää

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.

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.

Lue lisää

"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ä.

"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?