80-luku palasi

Mikäs kumma se on kun palstalle alkoi yks kaks tulvia viestejä jostain basicista, assemblerista, pascalista yms. 80-luvun jutuista?
Ilmoita


Do
X = MouseX
Y = MouseY
K = MouseK
If K = 1 Then
  @Piirra (X, Y)
Endif
Loop Until K = 2
End
'
Procedure Piirra (X, Y)
If X >= 100 And X <= 200 Then
LineTo (X, Y)
Endif
Return

' Oli se mukavaa aikaa, joku yö näin untakin vielä että koodailin Atari ST:llä grafiikkaa :)
1 VASTAUS:
Silloin taisi olla kaikki huonommin kuin nyt.
+Lisää kommentti
Niin esim. reactos projekti
http://www.reactos.org/
yrittää tuoda vielä windows käyttiksen.
Ilmoita
Tosin Pascal eroaa sillä noista muista että se toimii tänä päivänä ostetussa älykännykässä (ja se pystyy hyödyntämään sen ominaisuuksia)!
20 VASTAUSTA:
Ei oikein merkitystä kun samat asiat saa tehtyä ilman Pascalia siistimmin.
M-Kar kirjoitti:
Ei oikein merkitystä kun samat asiat saa tehtyä ilman Pascalia siistimmin.
Free Pascal ja Lazarus mahdollistavat ja sallivat ns. "siistien" (uusien) ominaisuuksien lisäämisen (muokkaamisen ja poistamisen) niihin. Kaikki on vain osaamisesta kiinni (sillä Lazarusta ja Free Pascalia kehitetään juuri niin).

Pascaliin voidaan lisätä myös assembly koodia.
La_zz kirjoitti:
Free Pascal ja Lazarus mahdollistavat ja sallivat ns. "siistien" (uusien) ominaisuuksien lisäämisen (muokkaamisen ja poistamisen) niihin. Kaikki on vain osaamisesta kiinni (sillä Lazarusta ja Free Pascalia kehitetään juuri niin).

Pascaliin voidaan lisätä myös assembly koodia.
Näytähän miten Free Pascalilla tehdään joku asia siistimmin kuin muilla.
M-Kar kirjoitti:
Näytähän miten Free Pascalilla tehdään joku asia siistimmin kuin muilla.
"tehdään joku asia siistimmin kuin muilla"

Siisteys ja kauneus on katsojan silmissä. Se mikä sinusta on siistiä, ei välttämättä ole muista minkään arvoista.

Tämä rutiini keskittää avautuvan ikkunan ja skaalaa näyttötilan mukaan sopivaksi ottaen valikkopalkin viemän tilan huomioon sen sijainnista riippumatta. Tämä on siistiä vielä senkin jälkeen kun suomi24 poistaa asiaan kuuluvat värit ja lihavoinnit.

procedure WindowSize43;
begin
- Form1.Width := Screen.WorkAreaWidth div 4 * 3;
- Form1.Height := Screen.WorkAreaHeight div 4 * 3;
- Form1.Top := Screen.WorkAreaHeight div 8;
- Form1.Left := Screen.WorkAreaWidth div 8;
end;

Anna nyt sinä vastineeksi, sen paremman kielen vastaava rutiini.
127.0.0.1 kirjoitti:
"tehdään joku asia siistimmin kuin muilla"

Siisteys ja kauneus on katsojan silmissä. Se mikä sinusta on siistiä, ei välttämättä ole muista minkään arvoista.

Tämä rutiini keskittää avautuvan ikkunan ja skaalaa näyttötilan mukaan sopivaksi ottaen valikkopalkin viemän tilan huomioon sen sijainnista riippumatta. Tämä on siistiä vielä senkin jälkeen kun suomi24 poistaa asiaan kuuluvat värit ja lihavoinnit.

procedure WindowSize43;
begin
- Form1.Width := Screen.WorkAreaWidth div 4 * 3;
- Form1.Height := Screen.WorkAreaHeight div 4 * 3;
- Form1.Top := Screen.WorkAreaHeight div 8;
- Form1.Left := Screen.WorkAreaWidth div 8;
end;

Anna nyt sinä vastineeksi, sen paremman kielen vastaava rutiini.
Huonollakin kielellä temppu käy näin:

'function windowSize43() {
' Form1.resizeTo(screen.availWidth * 0.75, screen.availHeight * 0.75)
' Form1.moveTo(screen.availHeight / 8, screen.availWidth / 8)
'}

Esimerkki vähän huono kun ikkunoiden kanssa puljaaminen on huonoa ohjelmointia. Näyttäisi silti menevän siistimmin ja tuo on enemmän kiinni rajapinnasta. Ihan standardirajapinnalla menee noin.

Selkeästi havaittavissa siistimpi toteutus kun tuossa ei tapahdu sijoituksia vaan kutsutaan oliota oikeaoppisesti.

Tästä on poistettu viesti sääntöjen vastaisena.

Tästä on poistettu viesti sääntöjen vastaisena.

Ei se käy että sotketaan kahta eri kieltä sekaisin, sitä paitsi tuo JavaScript osuus EI asettele ikkunaa, vaan hakee ikkunan koon.

Sinun piti antaa esimerkki joka tekee saman. Tee nyt JavaScript pätkä joka asettaa selaimenikkunan vastaavalla tavalla, huomioiden työpöydällä olevat valikkopalkit. Ei Lazaruksessa mene kahta riviä ikkunan koon hakemiseen.

"ikkunoiden kanssa puljaaminen on huonoa ohjelmointia"
Miellyttävä liittymä käyttäjälle, on erittäin tärkeä osa ohjelmaa, siitä riippuu hyvin paljon onko ohjelman käytettävyys surkea vai loistava. Siihen on pakko panostaa, kielestä riippumatta.

VINKKI JATKA TÄSTÄ JOS OSAAT
<!DOCTYPE html>
<html>
<body>

<button onclick="openWin()">Luo uussi ikkuna</button>

<script>
var myWindow;

function openWin() {
myWindow = window.open("", "", "width=xxx, height=yyy");
}

</script>

</body>
</html>
127.0.0.1 kirjoitti:
Ei se käy että sotketaan kahta eri kieltä sekaisin, sitä paitsi tuo JavaScript osuus EI asettele ikkunaa, vaan hakee ikkunan koon.

Sinun piti antaa esimerkki joka tekee saman. Tee nyt JavaScript pätkä joka asettaa selaimenikkunan vastaavalla tavalla, huomioiden työpöydällä olevat valikkopalkit. Ei Lazaruksessa mene kahta riviä ikkunan koon hakemiseen.

"ikkunoiden kanssa puljaaminen on huonoa ohjelmointia"
Miellyttävä liittymä käyttäjälle, on erittäin tärkeä osa ohjelmaa, siitä riippuu hyvin paljon onko ohjelman käytettävyys surkea vai loistava. Siihen on pakko panostaa, kielestä riippumatta.

VINKKI JATKA TÄSTÄ JOS OSAAT
<!DOCTYPE html>
<html>
<body>

<button onclick="openWin()">Luo uussi ikkuna</button>

<script>
var myWindow;

function openWin() {
myWindow = window.open("", "", "width=xxx, height=yyy");
}

</script>

</body>
</html>
"Ei se käy että sotketaan kahta eri kieltä sekaisin"

Missä minun esimerkissäni oli kahta kieltä sekaisin?

"sitä paitsi tuo JavaScript osuus EI asettele ikkunaa, vaan hakee ikkunan koon."

Väärin. Nimenomaan se muuntaa ikkunan Form1 kokoa ja sijaintia.

"Sinun piti antaa esimerkki joka tekee saman. Tee nyt JavaScript pätkä joka asettaa selaimenikkunan vastaavalla tavalla, huomioiden työpöydällä olevat valikkopalkit."

Kirjoittamani koodi teki saman, eli. Asettelee ikkunan Form1 huomioiden työpöydällä olevat valikkopalkit.

Jätit omasta esimerkistäsi ikkunan avauksen pois eikä missään luoda Form1 oliota joka on instanssi sille ikkunalle. Esimerkki oli siis täysin vastaava, eli käsitellään Form1 ikkuna oliota.

"Miellyttävä liittymä käyttäjälle, on erittäin tärkeä osa ohjelmaa, siitä riippuu hyvin paljon onko ohjelman käytettävyys surkea vai loistava."

Sitten siinä ei pitäisi olla mitään ikkunoiden käsittelyä. Käyttäjä voi muokata ympäristöään laittamalla komponentteja sinne ja tänne.

Eli siis ikkunaa ei pitäisi säätää omassa koodissa. Työpöytäympäristö tai käyttäjä hoitaa sitä.

Esim. tileable UI:llä jos ruutu jaettu vaikka näin: https://en.wikipedia.org/wiki/Tiling_window_manager#/media/File:Dwm-screenshot.png

Niin huomataan että koodissa tehty ikkunoiden käsittely on rikkinäistä. Ikkunan pitäisi käyttää sille varattu tila. Huomioi se että hyvässä käyttöliittymässä ei edes pitäisi ikkunoiden mennä päällekkäin missään kohtaa.

Tästä on poistettu viesti sääntöjen vastaisena.

M-Kar kirjoitti:
Huonollakin kielellä temppu käy näin:

'function windowSize43() {
' Form1.resizeTo(screen.availWidth * 0.75, screen.availHeight * 0.75)
' Form1.moveTo(screen.availHeight / 8, screen.availWidth / 8)
'}

Esimerkki vähän huono kun ikkunoiden kanssa puljaaminen on huonoa ohjelmointia. Näyttäisi silti menevän siistimmin ja tuo on enemmän kiinni rajapinnasta. Ihan standardirajapinnalla menee noin.

Selkeästi havaittavissa siistimpi toteutus kun tuossa ei tapahdu sijoituksia vaan kutsutaan oliota oikeaoppisesti.
Onko tälläinen ratkaisu parempi?
----8<---
procedure WindowSize43;
begin
Form1.resizeTo(screen.WorkAreaWidth * 0.75, screen.WorkAreaHeight * 0.75);
Form1.moveTo(screen.WorkAreaWidth / 8, screen.WorkAreaHeight / 8);
end;
---8<--
Kokeilun mukaan se tekee saman kuin "127.0.0.1" ratkaisu.
(ratkaistu niin että lisätty luokkaan pari uutta metodia)

Miksi ns. setterit on huono ratkaisu. Pascalissa sijoitusta voidaan käyttää kuten joissakin kielissä "settereitä " ( ja "gettereitä")?

Miksi reaaliluvut on siistimpi kuin kokonaisluvut?
Kysyjäkinkan kirjoitti:
Onko tälläinen ratkaisu parempi?
----8<---
procedure WindowSize43;
begin
Form1.resizeTo(screen.WorkAreaWidth * 0.75, screen.WorkAreaHeight * 0.75);
Form1.moveTo(screen.WorkAreaWidth / 8, screen.WorkAreaHeight / 8);
end;
---8<--
Kokeilun mukaan se tekee saman kuin "127.0.0.1" ratkaisu.
(ratkaistu niin että lisätty luokkaan pari uutta metodia)

Miksi ns. setterit on huono ratkaisu. Pascalissa sijoitusta voidaan käyttää kuten joissakin kielissä "settereitä " ( ja "gettereitä")?

Miksi reaaliluvut on siistimpi kuin kokonaisluvut?
Getterit ja setterit lisäävät riippuvuuksia olioiden välille ja vihjaavat myös siihen, että oliot tallentaa tilaa.
M-Kar kirjoitti:
Getterit ja setterit lisäävät riippuvuuksia olioiden välille ja vihjaavat myös siihen, että oliot tallentaa tilaa.
"Kokeilun mukaan se tekee saman kuin "127.0.0.1" ratkaisu."

Johan tuon sokeakin näkee kepillä, ettei ole muuta kuin sotkua koko paska. Ei varmasti toimi minkään kääntäjän alaisuudesssa. Ei ole Pascalia, eikä ole toimivaa JavaScript koodia.

"Getterit ja setterit lisäävät riippuvuuksia olioiden välille ja vihjaavat myös siihen, että oliot tallentaa tilaa."
Mitä sinä sössötät, opettele nyt edes vähän ennen kuin päästelet älyttömiä aivopierujasi julkisuuteen.
Soopaa-koko-roska kirjoitti:
"Kokeilun mukaan se tekee saman kuin "127.0.0.1" ratkaisu."

Johan tuon sokeakin näkee kepillä, ettei ole muuta kuin sotkua koko paska. Ei varmasti toimi minkään kääntäjän alaisuudesssa. Ei ole Pascalia, eikä ole toimivaa JavaScript koodia.

"Getterit ja setterit lisäävät riippuvuuksia olioiden välille ja vihjaavat myös siihen, että oliot tallentaa tilaa."
Mitä sinä sössötät, opettele nyt edes vähän ennen kuin päästelet älyttömiä aivopierujasi julkisuuteen.
"Ei varmasti toimi minkään kääntäjän alaisuudesssa."

Babel

"Mitä sinä sössötät, opettele nyt edes vähän ennen kuin päästelet älyttömiä aivopierujasi julkisuuteen."

Getteri on sitä, luetaan oliosta tilaa setteri sitä, että sinne asetetaan tilaa. Se on siis tarpeetonta riippuvuutta eikä se olio ole silloin immutable.

Getter ja setter on vähän semmoista, että kuvitellaan olion olevan vain datarakenne.

Sen sijaan kun käsketään oliota tekemään itselleen jotain, niin silloin toteutuu datan abstraktointi eikä tule riippuvuutta toisten olioiden välille mm. sillä tavalla, että toisen olion tarvitsisi tietää mitä dataa oliossa on.

Esimerkiksi jos on getteri joka lukee kellonajan oliosta ja sitten sitä käytetään vaikka tuhannessa paikassa koodia, ja sitten jos tätä oliota muutetaan miten se aika esitetään niin siitä seuraa se, että ne 1000 paikkaa missä tätä käytetään tarvitsee muokkausta.

Täyttä paskaa siis. Se kuka käyttää gettereitä ja settereitä olioissa, ei osaa olio-ohjelmointia.
Siis jos minulla on olion tietorakenteessa joku 8-bittinen muuttuja jonka jotain bittiä
pitäisi lukea tai muuttaa niin pascalissa voi olla "muuttuja" bitti6 joka on boolean tyyppinen (eli kyseinen "muuttuja" ei ota kantaa siihen missä muodossa se on olion sisällä) mutta muissa (yleisissä) kielissä pitää tehdä setteri ja getteri joka lukee ja muuttaa tuota bittiä (toki se voidaan Pascalissa tehdä myös tällä tavoin). Mutta jos sen sisäistä rakennetta muutetaan niin että se on vaikkapa boolean tyyppinen niin ei tarvitse muuttaa kuin kyseisen olion setteriä ja getteriä joka käsittelee tuota olion sisäistä muuttujaa. Pascalissa "muuttuja" bitti6 lukee ja kirjoittaa nyt sitten boolean-tyyppistä olion sisäistä muuttujaa (aikaisemman 8-bittisen tilalle). Eli muutoksia tulee vain olion sisälle ei noihin 1000:n paikkaan.
M-Kar kirjoitti:
"Ei varmasti toimi minkään kääntäjän alaisuudesssa."

Babel

"Mitä sinä sössötät, opettele nyt edes vähän ennen kuin päästelet älyttömiä aivopierujasi julkisuuteen."

Getteri on sitä, luetaan oliosta tilaa setteri sitä, että sinne asetetaan tilaa. Se on siis tarpeetonta riippuvuutta eikä se olio ole silloin immutable.

Getter ja setter on vähän semmoista, että kuvitellaan olion olevan vain datarakenne.

Sen sijaan kun käsketään oliota tekemään itselleen jotain, niin silloin toteutuu datan abstraktointi eikä tule riippuvuutta toisten olioiden välille mm. sillä tavalla, että toisen olion tarvitsisi tietää mitä dataa oliossa on.

Esimerkiksi jos on getteri joka lukee kellonajan oliosta ja sitten sitä käytetään vaikka tuhannessa paikassa koodia, ja sitten jos tätä oliota muutetaan miten se aika esitetään niin siitä seuraa se, että ne 1000 paikkaa missä tätä käytetään tarvitsee muokkausta.

Täyttä paskaa siis. Se kuka käyttää gettereitä ja settereitä olioissa, ei osaa olio-ohjelmointia.
"""""Ei varmasti toimi minkään kääntäjän alaisuudesssa."

Babel"""""

Babel on online JavaScript kääntäjä, ei se tuota sinun sotkuja pysty kääntämään. Noin siinä käy kun ei ohjelmoinnista tiedä yhtään mitään, paska puheiden todisteeksi käy joltakin sivulta kopioimassa toisten tekemää koodia, tietämättä mitä se tekee, tai mitä se vaatii toimiakseen.

Jumaliste, ei edes alkeita osaa, ja koko suomi24 on täynä tuota hiton soopaa.

"""""""Getteri on sitä, luetaan oliosta tilaa setteri sitä, että sinne asetetaan tilaa. Se on siis tarpeetonta riippuvuutta eikä se olio ole silloin immutable."""""""""
Voi hyvä isä mitä sontaa.
Soopaa-koko-roska kirjoitti:
"""""Ei varmasti toimi minkään kääntäjän alaisuudesssa."

Babel"""""

Babel on online JavaScript kääntäjä, ei se tuota sinun sotkuja pysty kääntämään. Noin siinä käy kun ei ohjelmoinnista tiedä yhtään mitään, paska puheiden todisteeksi käy joltakin sivulta kopioimassa toisten tekemää koodia, tietämättä mitä se tekee, tai mitä se vaatii toimiakseen.

Jumaliste, ei edes alkeita osaa, ja koko suomi24 on täynä tuota hiton soopaa.

"""""""Getteri on sitä, luetaan oliosta tilaa setteri sitä, että sinne asetetaan tilaa. Se on siis tarpeetonta riippuvuutta eikä se olio ole silloin immutable."""""""""
Voi hyvä isä mitä sontaa.
Tämä on validia Javascriptiä:

function windowSize43() {
Form1.resizeTo(screen.availWidth * 0.75, screen.availHeight * 0.75)
Form1.moveTo(screen.availHeight / 8, screen.availWidth / 8)
}

Ja Babel kääntää tuon.

"Babel on online JavaScript kääntäjä, ei se tuota sinun sotkuja pysty kääntämään."

Mikä hemmetin online?

"Jumaliste, ei edes alkeita osaa, ja koko suomi24 on täynä tuota hiton soopaa."

Siis sinä et osaa kun et kerran Javascriptiäkään tunne. Jos kirjoittamani koodi ei muka olisi validia niin näyttäisit siitä bugin mutta kun siinä ei ole bugia niin et pysty.
Kysyjäkinkan1 kirjoitti:
Siis jos minulla on olion tietorakenteessa joku 8-bittinen muuttuja jonka jotain bittiä
pitäisi lukea tai muuttaa niin pascalissa voi olla "muuttuja" bitti6 joka on boolean tyyppinen (eli kyseinen "muuttuja" ei ota kantaa siihen missä muodossa se on olion sisällä) mutta muissa (yleisissä) kielissä pitää tehdä setteri ja getteri joka lukee ja muuttaa tuota bittiä (toki se voidaan Pascalissa tehdä myös tällä tavoin). Mutta jos sen sisäistä rakennetta muutetaan niin että se on vaikkapa boolean tyyppinen niin ei tarvitse muuttaa kuin kyseisen olion setteriä ja getteriä joka käsittelee tuota olion sisäistä muuttujaa. Pascalissa "muuttuja" bitti6 lukee ja kirjoittaa nyt sitten boolean-tyyppistä olion sisäistä muuttujaa (aikaisemman 8-bittisen tilalle). Eli muutoksia tulee vain olion sisälle ei noihin 1000:n paikkaan.
No tuo on sitä mokailua taas.

Oikea tapa on tietenkin tuoda tieto olioon contructorissa.

Lähtökohtaisesti homma menee väärin jos on gettereitä ja settereitä tai jos käytetään sijoitusoperaattoria, eli se mikä on Pascalissa :=

Tästä on poistettu viesti sääntöjen vastaisena.

Tästä on poistettu viesti sääntöjen vastaisena.

Tästä on poistettu viesti sääntöjen vastaisena.

Nythän sitä voitas seuraavat sata viestiä jaaritella siitä mikä on täysi linja-auton rengas, ja montako kirjotus virhettä tein tuota kirjottaessani.

Loppu tulokseksi kelpaa vain se minkä sinä sanot täyden rengaan olevan, luultavasti se olis jotain sellaista kuin vanteelta pois otettuna 24 asteisena pimeässä huoneessa oleva rengans ja vain tuon rengaan voi sanoa olevan täysi.

Näin ne sinun jutut menee, niitä ei vain ymmärrä muut kuin tietotekniikan taitajat, kun sama tehdään sillä puolen.
Soopaa-koko-roska kirjoitti:
Nythän sitä voitas seuraavat sata viestiä jaaritella siitä mikä on täysi linja-auton rengas, ja montako kirjotus virhettä tein tuota kirjottaessani.

Loppu tulokseksi kelpaa vain se minkä sinä sanot täyden rengaan olevan, luultavasti se olis jotain sellaista kuin vanteelta pois otettuna 24 asteisena pimeässä huoneessa oleva rengans ja vain tuon rengaan voi sanoa olevan täysi.

Näin ne sinun jutut menee, niitä ei vain ymmärrä muut kuin tietotekniikan taitajat, kun sama tehdään sillä puolen.
Näyttää siltä että M-Karin viestejä ei ylläpito anna kyseenalaistaa, kaikki otetaan pois. No olkoon niin. Tästä eteen päin en osallistu huuhaa viesteihin vastaamalla.
Soopaa-koko-roska kirjoitti:
Näyttää siltä että M-Karin viestejä ei ylläpito anna kyseenalaistaa, kaikki otetaan pois. No olkoon niin. Tästä eteen päin en osallistu huuhaa viesteihin vastaamalla.
Ei varmaan kannata aukoa päätään kun robotti poistaa ne viestit. Opettele argumentoimaan.

Ylläpito on poistanut tästä viestin sääntöjen vastaisena.

Tästä on poistettu viesti sääntöjen vastaisena.

Tästä on poistettu viesti sääntöjen vastaisena.

Äkkiseltään tulee mieleen, että voisi funtsia miten esittää CSS:n JSON:n muodossa ja käyttöliittymän storessa olisi tuo rakenne ja muut mitä tarvitsee. Varmaankin voisi mallintaa sitä json:ia DOM CSS:n pohjalta.
Soopaa-koko-roska kirjoitti:
"""""Ei varmasti toimi minkään kääntäjän alaisuudesssa."

Babel"""""

Babel on online JavaScript kääntäjä, ei se tuota sinun sotkuja pysty kääntämään. Noin siinä käy kun ei ohjelmoinnista tiedä yhtään mitään, paska puheiden todisteeksi käy joltakin sivulta kopioimassa toisten tekemää koodia, tietämättä mitä se tekee, tai mitä se vaatii toimiakseen.

Jumaliste, ei edes alkeita osaa, ja koko suomi24 on täynä tuota hiton soopaa.

"""""""Getteri on sitä, luetaan oliosta tilaa setteri sitä, että sinne asetetaan tilaa. Se on siis tarpeetonta riippuvuutta eikä se olio ole silloin immutable."""""""""
Voi hyvä isä mitä sontaa.
"Babel on online JavaScript kääntäjä,"

Täh?? :D :D Melkoinen aivopieru :D
+Lisää kommentti
80-luvulla se oli hyvä, mutta sen jälkeen pelkkää persemäkeä. Ainakin näin omista kokemuksista, voi sen vannoa. Ennen mustaruutu ja koneelle annettiin komento mitä tehdä ja nykyään se kone tekee taustalla pahansuopaisia toimintoja, joilla nussastaan käyttäjän toiminnot yli mantereiden. Oksennan ja sanon että vittuun koko microsoft.
Itse jos olisi firman johtaja niin potkun perseelle saisi se joka käyttää windowsia. Esimerkiksi saihan se potkut avaruudestakin, siis liian myöhään, kun kyse oli jopa miljardeista.
Potkuja seuraa potkujen perään, mutta auttamasti porukka tuntuu olevan tuntumasta liian myöhässä. Ajatellaan että kun esim. win 95 imi vuolaasti kaiken, niin sen käyttöä jatkettiin monellakin taholla. Sama on edeellen muillakin versioilla, että ne on reikäjuustoa, eivätkä mitenkään turvallisia. Win 10 "turvallisin ikinä, again" ei ole tuonut helpotusta.

Jos joku tajuaisi että ihmiset on tyhmiä olioita, mutta kun se palkka sokaisee sen tajunnan ja ihminen "luulee" väärässäkin olevansa oikeassa. Jos tuosta joku uskaltaa väittää muuta, niin piruvie hänen täytyy tienata potaskasta.
No itse olen myös tyhmä olio, joka varmasti ahdeudesta tekee jopa mitä vain... :-)
Rahattomat ovat varmuudella viisaampia. He kun osaavat kartoittaa toimintaa laajemmalle, kuin joku joka saa kaikkea yli äyräiden, eikä sekään riitä.
Ilmoita
"Esimerkiksi jos on getteri joka lukee kellonajan oliosta ja sitten sitä käytetään vaikka tuhannessa paikassa koodia, ja sitten jos tätä oliota muutetaan miten se aika esitetään niin siitä seuraa se, että ne 1000 paikkaa missä tätä käytetään tarvitsee muokkausta."

Miksi et sitten kerro mikä / miten olisi parempi tehdä ratkaisu ilman getteriä?

En sitä paitsi koskaan tekisi getteriä joka palauttaa muotoiltuna dataa, tässä tapauksessa aina palautus timestamp-arvona ja tiedon muotoilulle on sitten omat tapansa esittää se tieto, mahdollisesti lokalisaatio-tiedon mukaan.
9 VASTAUSTA:
"Miksi et sitten kerro mikä / miten olisi parempi tehdä ratkaisu ilman getteriä?"

Ei pyydetä tietoja joita tarvitsee jonkun asian tekemiseen. Pitää tehdä niin, että objektia jolla on riittävät tiedot pyydetään tekemään asia.

Homma menee pieleen jos kuvitellaan objektien olevan datasäilöitä joilla on metodeita datan lukemiseen ja kirjoittamiseen.
En kyllä ymmärtänyt vieläkään? Eli jos objektilla on getteri, silloinhan sillä on riittävät tiedot asian tekemiseen. Jos luetaan tietoa paikasta A -> B, silloin syntyy riippuvuus, luettiin tieto sitten getterin tai perinteisen funktion kautta. Getteri voi myös tehdä / tarkistaa asioita ja palauttaa pyydetyn tuloksen.
ex-delphisti kirjoitti:
En kyllä ymmärtänyt vieläkään? Eli jos objektilla on getteri, silloinhan sillä on riittävät tiedot asian tekemiseen. Jos luetaan tietoa paikasta A -> B, silloin syntyy riippuvuus, luettiin tieto sitten getterin tai perinteisen funktion kautta. Getteri voi myös tehdä / tarkistaa asioita ja palauttaa pyydetyn tuloksen.
Idea vähän onkin se, että tietoa ei lueta vaan olio tekee sen asian sillä tiedolla.

Eli ei tehdä näin:

luku = olio.getLuku()
return luku +1

vaan käsketään:

olio.teeJotain()

getterit ja setterit on vähän semmoista, että olion käsitellään jonkinlaisena datasäiliönä.
ex-delphisti kirjoitti:
En kyllä ymmärtänyt vieläkään? Eli jos objektilla on getteri, silloinhan sillä on riittävät tiedot asian tekemiseen. Jos luetaan tietoa paikasta A -> B, silloin syntyy riippuvuus, luettiin tieto sitten getterin tai perinteisen funktion kautta. Getteri voi myös tehdä / tarkistaa asioita ja palauttaa pyydetyn tuloksen.
"""""
En kyllä ymmärtänyt vieläkään?
"""""
Enkä ihmettele yhtään, ei siinä ole mitään, mitä pitäisi ohjelmointi taitoisen kaverin ymmärtää.
Soopaa-koko-roska kirjoitti:
"""""
En kyllä ymmärtänyt vieläkään?
"""""
Enkä ihmettele yhtään, ei siinä ole mitään, mitä pitäisi ohjelmointi taitoisen kaverin ymmärtää.
Niin, gettereillä ja settereillä puljaavat ei ainakaan osaa olio-ohjelmointia.
M-Kar kirjoitti:
Idea vähän onkin se, että tietoa ei lueta vaan olio tekee sen asian sillä tiedolla.

Eli ei tehdä näin:

luku = olio.getLuku()
return luku +1

vaan käsketään:

olio.teeJotain()

getterit ja setterit on vähän semmoista, että olion käsitellään jonkinlaisena datasäiliönä.
Eli pitäisikö tuo käsittää näin jos käytetään jonkun toisen luokkaa niin tehdään sille perillinen ja lisätään sille uusi metodi joka tekee asian ennemmin kuin luetaan jonkun toisen oliosta getterillä tieto jota muuteetaan?
Luokan sisäinen tieto pitää olla "salattua". Gettereillä, settereillä, metodeilla, funktioilla miksi näitä nyt halutaan kutsuttavan, ne on rajapinta luokan toimintoihin ja tietoon, mutta itse luokan pitää olla aina 100% vastuussa siitä mitä sen tiedolle pystytään loppukädessä tekemään ja mitä se palauttaa. Ei tämä ole rakettitiedettä!

C-kielessä ei ole olioita, mitä nyt struct-rakenne on vähän sinne päin. Itse näen asian C-kielen näkökulmasta näin versus olio-ohjelmointi.

Header-tiedostot, eli h-tiedostot on julkinen rajapinta koodiin ja se "salattu" private-osuus toteutetaan vastaavasti c-tiedostossa.

Header-tiedostossa on siis
void teeJotain(); // Setteri
int haeJotain(); // Getteri

C-tiedostossa varsinainen toteutus:

int g_private_muuttuja = 0;

void teeJotain () {
printf("No minäpä teen\n");
g_private_muuttuja = 2017;
}

int haeJotain () {
return g_private_muuttuja;
}

Siis mitä pirun eroa tällä on siihen jos sinulla on olio tyyliin objekti.teeJotain(); tai objekti.haeJotain() ? Ainoastaan objekti toimii yhteisenä nimiavaruutena näille toiminnoille ja luokasta voidaan tehdä myös kopioita
aaaattt kirjoitti:
Eli pitäisikö tuo käsittää näin jos käytetään jonkun toisen luokkaa niin tehdään sille perillinen ja lisätään sille uusi metodi joka tekee asian ennemmin kuin luetaan jonkun toisen oliosta getterillä tieto jota muuteetaan?
Väärin.

Ei pidä tehdä luokkia joissa on gettereitä ja settereitä. Korjataan se vika siellä missä se on, eli tekemällä siistejä luokkia. Ja jos meinaan jonkun muun koodia käyttää niin jos se on niin paskaa että siinä on gettereitä ja settereitä niin ehkä voisi käyttää parempaa.
ex-delphisti kirjoitti:
Luokan sisäinen tieto pitää olla "salattua". Gettereillä, settereillä, metodeilla, funktioilla miksi näitä nyt halutaan kutsuttavan, ne on rajapinta luokan toimintoihin ja tietoon, mutta itse luokan pitää olla aina 100% vastuussa siitä mitä sen tiedolle pystytään loppukädessä tekemään ja mitä se palauttaa. Ei tämä ole rakettitiedettä!

C-kielessä ei ole olioita, mitä nyt struct-rakenne on vähän sinne päin. Itse näen asian C-kielen näkökulmasta näin versus olio-ohjelmointi.

Header-tiedostot, eli h-tiedostot on julkinen rajapinta koodiin ja se "salattu" private-osuus toteutetaan vastaavasti c-tiedostossa.

Header-tiedostossa on siis
void teeJotain(); // Setteri
int haeJotain(); // Getteri

C-tiedostossa varsinainen toteutus:

int g_private_muuttuja = 0;

void teeJotain () {
printf("No minäpä teen\n");
g_private_muuttuja = 2017;
}

int haeJotain () {
return g_private_muuttuja;
}

Siis mitä pirun eroa tällä on siihen jos sinulla on olio tyyliin objekti.teeJotain(); tai objekti.haeJotain() ? Ainoastaan objekti toimii yhteisenä nimiavaruutena näille toiminnoille ja luokasta voidaan tehdä myös kopioita
"Luokan sisäinen tieto pitää olla "salattua". Gettereillä, settereillä, metodeilla, funktioilla miksi näitä nyt halutaan kutsuttavan, ne on rajapinta luokan toimintoihin ja tietoon, mutta itse luokan pitää olla aina 100% vastuussa siitä mitä sen tiedolle pystytään loppukädessä tekemään ja mitä se palauttaa. Ei tämä ole rakettitiedettä!"

Se mikä tuossa menee väärin on se, että kun sitä tietoa haetaan tai taltioidaan, tuossa muodostuu riippuvuus kahden olion välille. Jos siellä joku getteri palauttaa jotain, pitää sen vastaanottavan luokan tietää mitä se on lukemassa.

Tuo myös johtaa helposti typerään rakenteeseen, että luokat tallentavat tilaa.

Ei niillä olioilla ole olennaisesti eroa muuttujiin ja jos koodissa on vaikka näin:

a = 1
b = a +2

niin tuohan on väärin, sillä siinä käytetään sijoitusta.

Sama pätee myös olioihin. Olioissa kun on setteriä niin silloinhan käytännössä sijoitetaan arvo johonkin tilaan.

Semmoinen hyvä lähtökohta olisi, että tilaa ei tallenneta mihinkään muualle kuin sinne missä se välttämättä tarvitaan. Käytännössä se olisi siellä ihan lopussa kun persistoidaan tietoa tai sitten käyttöliittymäpuolessa keskitetty tilan tallennus ettei turhaan kierrätetä dataa jonkun kannan kautta.

Ja kun data persistoidaan niin ideaalisestihan se käy kun funktioilla kun käskee rajapinnassa että lähettää tiedon johonkin säiliöön.

Silloin homma menee pieleen jos ohjelman kylvää täyteen olioita joilla olisi oma tila.

void teeJotain () {
printf("No minäpä teen\n");
g_private_muuttuja = 2017;
}

No tuossahan se menee pieleen. On sijoituslause.

Se on semmoista bugien viljelyä kun on olioita ja muuttujia joilla on tiloja koska logiikan oikea toiminta menee riippuvaiseksi siitä, missä tilassa eri muuttujat ja oliot ovat. Se ei siis riitä, että oliot vaan tarkistaa syötettään. Käytännössä olioiden pitäisi saada tilansa luonnin yhteydessä ja sen kestää olion ikänsä (kauan on siinä scopessa) ilman että sitä sen kummemmin muutellaan.

C:ssä homman voi tehdä näin kun määrittelee sen luokan, esim. näin:

typedef struct LuokkaTag { int x; int y; } Luokka

ja sitten olion tekee ihan vaan:

const Luokka olio = { 10, 20 };

Siinä on olio sitten luotuna ja luokan toteutus voi sisällyttää funktioita jotka ottavat parametrinaan sen olion.

Tuon sisäinen implementaatio voidaan kätkea kun ei avaa toteutusta ulospäin siellä headerissa. Funktiot joita toteutetaan voi käyttää yksityisiä funktioita joita voi pitää piilotettuna.

Oliokielien jutut ovatkin suurelta osin syntaksista herkkua ja työkaluja scopettamiseen.
+Lisää kommentti
"Käytännössä olioiden pitäisi saada tilansa luonnin yhteydessä ja sen kestää olion ikänsä (kauan on siinä scopessa) ilman että sitä sen kummemmin muutellaan."

Tuo varmaan toimii jossakin minimaalisen jutun tekemisessä. Yhden oman projektin kohdalla yksi iso olio luodaan heti alussa joka muodostaa datan pienemmistä olioista ja näitä pienempiä olioita suoritetaan vielä säikeistettynä rinnakkain. Täysin mahdoton ajatus, varsinkaan isomman olion kohdalla ettei mitään tilaa saisi muuttaa ajon aikana.

Samalla periaatteella varmasti graafiset rajapinnat kuten OpenGL ja DirectX ovat täysin bugisia kökköä, mitä viimeksi niillä koodailin niin erilaisia tiloja niissä asetellaan ja tarkastellaan ajon aikana paljonkin.
11 VASTAUSTA:
"Tuo varmaan toimii jossakin minimaalisen jutun tekemisessä."

Toimii laajoissakin jutuissa ihan hyvin.

"Yhden oman projektin kohdalla yksi iso olio luodaan heti alussa joka muodostaa datan pienemmistä olioista ja näitä pienempiä olioita suoritetaan vielä säikeistettynä rinnakkain."

Miksi noin hankalasti? Suurin osa asioista ratkeaa sillä kun on jokin syöte, ja siitä pitää saada saada tuloste. Poikkeuksia toki on vaikka se datan persistointi, että siellä on sivuvaikutuksena se, että data menee säiliöön.

Piirrettäessä juttuja, siellä on semmoinen poikkeus, että säiliön sijasta muutetaan bittejä ruudulla rajapinnan kautta. Mutta kyllä se voi niinikään tapahtua myös yhden tilan tallennuksen kautta, että lähetetään muutos siihen tilaan, ja siinä yhteydessä päivitetään tilaa. Tilan päivitys toki voi tapahtua myös funktiona että annetaan sille parametrinä tila ja se palauttaa sitten muutetun tilan.

Temppu on havainnollistettu tässä: https://camo.githubusercontent.com/9de527b9432cc9244dc600875b46b43311918b59/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f6d656469612d702e736c69642e65732f75706c6f6164732f3336343831322f696d616765732f323438343739302f415243482d5265647578322d657874656e6465642d7265616c2d6465636c657261746976652e676966

Harvinaisia poikkeuksia löytyy kyllä mutta siitä tietää että on menossa pieleen jos tiloja on siellä ja täällä.

Tuo tilojen välttäminen ja muuttumattomat rakenteet poistaa valtavasti virheitä ja siksi sitä varten on niitä työkaluja. Ohjelmointikieliäkin.
Delphillä en projektiani koodaa, mutta siinä on saman tyylinen toteutus kuin Delphin TCanvas-luokassa:
canvas.brush.color = "#F00";
canvas.pen.style = PenStyle.SOLID;
canvas.drawTo (x, y);
canvas.rectangle (x, y, w, h);

Siinä niitä "settereitä" on ja toki tilan vaihdoksessa pitää huomioida ettei saman tilan takia tehdä asioita tuplasti. Tuossa on jo Canvas-class, Brush-struct, Pen-struct. Eikä ole yhtään hankalaa, homma toimii ihan hyvin :)
ex-delphisti kirjoitti:
Delphillä en projektiani koodaa, mutta siinä on saman tyylinen toteutus kuin Delphin TCanvas-luokassa:
canvas.brush.color = "#F00";
canvas.pen.style = PenStyle.SOLID;
canvas.drawTo (x, y);
canvas.rectangle (x, y, w, h);

Siinä niitä "settereitä" on ja toki tilan vaihdoksessa pitää huomioida ettei saman tilan takia tehdä asioita tuplasti. Tuossa on jo Canvas-class, Brush-struct, Pen-struct. Eikä ole yhtään hankalaa, homma toimii ihan hyvin :)
Sitten voisi miettiä, että miksi et vain tekisi esimerkiksi näin:

canvas.addPen(new Pen('punaliitu', Color::RED, Pen::SOLID)
canvas.drawRectangle('punaliitu', x, y, w, h)

Tuossa canvas säilöisi kyniä ja kynillä piirrettyjä juttuja ja se olisi käyttöliittymässä tilaa säilövä asia.
Siksi koska tuossa joutuisi ennen varsinaista piirto-operaatiota etsimään silmukassa "punaliitu" kynää, lisäksi tuossa on vain yksi kombinaatio, punainen kiinteä viiva. Omassa totutuksessa voi säilyttää punaisen värin (ei vie saman tilan takia muutosta eteenpäin), mutta tyylin voi vaihtaa esim. Pen::DASHDOT, eli vie muutoksessa eteenpäin vain ne tilat mitkä vaihtuu oikeasti.
ex-delphisti kirjoitti:
Siksi koska tuossa joutuisi ennen varsinaista piirto-operaatiota etsimään silmukassa "punaliitu" kynää, lisäksi tuossa on vain yksi kombinaatio, punainen kiinteä viiva. Omassa totutuksessa voi säilyttää punaisen värin (ei vie saman tilan takia muutosta eteenpäin), mutta tyylin voi vaihtaa esim. Pen::DASHDOT, eli vie muutoksessa eteenpäin vain ne tilat mitkä vaihtuu oikeasti.
Se on O(1) operaatio hakea säiliöstä tavaraa.
Visiossa on haave tehdä tyyli-editori, jonka taustalla on CSS, eli siis tyylimääritykset voi tehdä tekstinä suoraan tai editori kokoaa CSS-määritykset piilossa valintojen mukaan. border: 1pt solid red; border-top-style: solid; border-top-width: 1pt; border-top-color: #F00. Näitä kombinaaitoita voi olla useita erilaisia riippuen tekeekö tyylin editori vai muokkaamalla suoraan CSS tekstinä, siinä siis taustalla tuo nykyinen Canvas-toteutus.

No tämä on tämmöinen oma harrasteprojekti työn ohella, alkaa tulemaan kohta vuosi siitä kun aloitin, illassa muutama tunti koodaillen, mukavaa puuhaa kun ei tarvi kiireen kanssa säheltää :)
ex-delphisti kirjoitti:
Visiossa on haave tehdä tyyli-editori, jonka taustalla on CSS, eli siis tyylimääritykset voi tehdä tekstinä suoraan tai editori kokoaa CSS-määritykset piilossa valintojen mukaan. border: 1pt solid red; border-top-style: solid; border-top-width: 1pt; border-top-color: #F00. Näitä kombinaaitoita voi olla useita erilaisia riippuen tekeekö tyylin editori vai muokkaamalla suoraan CSS tekstinä, siinä siis taustalla tuo nykyinen Canvas-toteutus.

No tämä on tämmöinen oma harrasteprojekti työn ohella, alkaa tulemaan kohta vuosi siitä kun aloitin, illassa muutama tunti koodaillen, mukavaa puuhaa kun ei tarvi kiireen kanssa säheltää :)
Äkkiseltään tulee mieleen, että voisi funtsia miten esittää CSS:n JSON:n muodossa ja käyttöliittymän storessa olisi tuo rakenne ja muut mitä tarvitsee. Varmaankin voisi mallintaa sitä json:ia DOM CSS:n pohjalta.

Sitten editorin toiminnot muuttaisi sitä rakennetta ja sama rakenne voidaan visualisoida. Aina kun muutos tulee niin päivitetään rakennetta ja tehdään refreshiä.
M-Kar kirjoitti:
Äkkiseltään tulee mieleen, että voisi funtsia miten esittää CSS:n JSON:n muodossa ja käyttöliittymän storessa olisi tuo rakenne ja muut mitä tarvitsee. Varmaankin voisi mallintaa sitä json:ia DOM CSS:n pohjalta.

Sitten editorin toiminnot muuttaisi sitä rakennetta ja sama rakenne voidaan visualisoida. Aina kun muutos tulee niin päivitetään rakennetta ja tehdään refreshiä.
Kaikesta huolimatta tulee mieleen, että voisi avaa itse kullekin tiedon ja ymmärryksen portin kohti tulevaa taloudellista ja teollista behaviorismia. Vaikka usein kuuleekin aivan järjettömiä mielipiteitä, on kuitenkin tosiasia, että rakenne ja muut mitä näyttelee keskeistä osaa pohdittaessa peräänkuulutettua lakonisuutta. Jopa editorin toiminnot muuttaisi kuvailee huomaamattomia haittatekijöitä.
ex-delphisti kirjoitti:
Kaikesta huolimatta tulee mieleen, että voisi avaa itse kullekin tiedon ja ymmärryksen portin kohti tulevaa taloudellista ja teollista behaviorismia. Vaikka usein kuuleekin aivan järjettömiä mielipiteitä, on kuitenkin tosiasia, että rakenne ja muut mitä näyttelee keskeistä osaa pohdittaessa peräänkuulutettua lakonisuutta. Jopa editorin toiminnot muuttaisi kuvailee huomaamattomia haittatekijöitä.
Tuo ei sitten ollut minun kommentti, mikä lie seko translatorin tekoaivopeiru?
M-Kar kirjoitti:
Äkkiseltään tulee mieleen, että voisi funtsia miten esittää CSS:n JSON:n muodossa ja käyttöliittymän storessa olisi tuo rakenne ja muut mitä tarvitsee. Varmaankin voisi mallintaa sitä json:ia DOM CSS:n pohjalta.

Sitten editorin toiminnot muuttaisi sitä rakennetta ja sama rakenne voidaan visualisoida. Aina kun muutos tulee niin päivitetään rakennetta ja tehdään refreshiä.
Miksipä ei noinkin.
ex-delphisti kirjoitti:
Miksipä ei noinkin.
Ja ajatus tosiaankin se, että koko editoriin ei tarvitse silloin yhtään mitään muuta tilaa tallentavaa paikkaa ja se aika tehokkaasti poistaa virheet koodista ja tekee siitä siistiä. Ei voi siis tulla bugia mikä ilmenee kun "canvas" onkin eri tilassa kuin varsinainen CSS mitä tuotetaan.
+Lisää kommentti
Kunpa koodari koppais kadunmiehen koeajamaan ja parantelis ohjelman asiakasvihamielisyyden pois. Mutta ei koodari jaksa, tekee vain sen verran muistiinpanoja, että itse ymmärtää kuu,auden päästä miten ohfelmaa käytetään..

Ei koodari osaa arvata miten mies kadulta tulkitsee ohjeen. Eikä koodarilla ole tähän ollut mitään lääkettä vuosikymmeniin, eikä tule.

Pitäis tehdä sellaista, mitä ei jaksa. Pitäis tehdä luettelo asioista joita ohjelma voi tehdä. Ja asian valinnan jälkeen pitää tapahtua se tekeminen vaikka mies kadulta ei osaisikaan osoitta väylää sormella jokaiselle bitille.
1 VASTAUS:
"Kunpa koodari koppais kadunmiehen koeajamaan ja parantelis ohjelman asiakasvihamielisyyden pois."

Kadunmiehet koeajelevat paljonkin ohjelmia.

"Mutta ei koodari jaksa, tekee vain sen verran muistiinpanoja, että itse ymmärtää kuu,auden päästä miten ohfelmaa käytetään.."

Ei. Ohjelmoijilla on helposti vuodeksi eteenpäin kaikenlaisia töitä mitä ohjelmalle tarvitsee tehdä. Kyse on priorisoinnista ja siitä vastaa yleensä ne jotka ovat sen rahakasan päällä. Asiakaspalaute etenkin varhaisessa vaiheessa on myös tärkeä priorisointiin vaikuttava asia.
+Lisää kommentti

Vastaa alkuperäiseen viestiin

80-luku palasi

Mikäs kumma se on kun palstalle alkoi yks kaks tulvia viestejä jostain basicista, assemblerista, pascalista yms. 80-luvun jutuista?

5000 merkkiä jäljellä

Peruuta