Hur delar man fält i Java som är ej statiska? - JavaFX

Permalänk
Skrivet av Teknocide:

Jag ser inte hur du skulle behöva ha static på fältet. Som sagt, det kommer sluta funka om du använder komponenten två gånger.

Skickades från m.sweclockers.com

Du har helt rätt. Jag testade öppna två fönster och anropa denna statiska metod. Där med så delade dessa två fönster samma variabel.

Jag har dock inget problem med detta. Men det skulle vara fint om man kunde ha två fönster som inte påverkade varandra. Så du rekommenderar att inte använda static?

Jag ser inte hur jag ska kunna lösa problemet Jag vet att jag kan generera ett objekt av klassen, men i detta fall ser mitt program ut så här:

När jag trycker på "Select X-axis column" så trycks knappen ned och hålls där. Efter jag klickar på kolummen "Friday" så kopieras "Friday" till fältet där det står "Friday".

Förklaringen till detta kan sammanfattas som:

  • Varje tabell har en lyssnare som känner utav om musen klickar på tabellen

  • Lyssnaren tar kolumnnamnet och skickar det till en annan klass

  • Den andra klassen är fönstret

Permalänk
Medlem
Skrivet av heretic16:

Jag har inte sett några stora program som är skrivna i dessa språk.

Nix. Jag har bara lyssnat på vad marknaden kräver. C för hårdvaruprogrammering och C++ för grafik samt Java för applikationer och PHP för servrar.

Jag försökte förklara för en kund att Java går utmärkt att programmera med inbyggda system. Men kunden ville köra allt i C. Jupp, det kostade en del att utveckla Med Java så hade jag endast behövs spendera 30% av tiden.

Jag flyr från de system som fortfarande vill använda PHP.

Permalänk
Medlem
Skrivet av heretic16:

Så i framtiden så är det icke OOP som är det mest attraktiva? Kan det inte ha med att folk förstår sig ej på OOP? Jag menar, fulprogrammerare finns det gott om.

Med tanke på att även java får allt mer stöd för funktionellt tänk med saker som RxJava så skulle jag definitivt säga att de funktionella delarna ökar i popularitet. Tycker personligen det är extremt smidigt i rätt context.

Brukar säga att språk borde matcha vad det är för tjänst man utvecklar. (Dock har jag en kanske lite för stark kärlek till micro-service system)

Permalänk
Medlem
Skrivet av Alling:

OK. Marknaden är ju i regel trög med den typen av förändringar, men den funktionella snöbollen är i rullning.

Är skeptisk till att marknadens tröghet är problemet, Lisp dök upp på 50-talet och ML på 70-talet. Vad skulle göra att snöbollen är i mer rullning nu än valfritt annat årtionde? Haskell är häftigt så länge man håller sig inom dess safe space, men så fort man ska börja prata med libbar, OS eller liknande känns det inte fullt så kul. Prestandan lämnar också en del att önska.

I så fall uppfattar jag Erlang som mer redo för produktionslösningar, då det faktiskt snurrar på mycket hårdvara.

Visa signatur

CachyOS | 2x1440p 165Hz IPS | 7800X3D | 6950XT | 64GB@6GHz | 2x4TB SN850x

Permalänk
Skrivet av AfterShock:

Jag flyr från de system som fortfarande vill använda PHP.

Jag flyr från C och C++. Det har inget med att jag är okunnig. Snarare tycker jag att koden skrivs på ett sådant lustigt sätt. Varför ens sätta s_ före en variabel? Vad är syftet med detta brutala "rulla apelsin på tangentbord"-skrivsätt för att namnge variabler osv?

Permalänk
Skrivet av AfterShock:

Med tanke på att även java får allt mer stöd för funktionellt tänk med saker som RxJava så skulle jag definitivt säga att de funktionella delarna ökar i popularitet. Tycker personligen det är extremt smidigt i rätt context.

Brukar säga att språk borde matcha vad det är för tjänst man utvecklar. (Dock har jag en kanske lite för stark kärlek till micro-service system)

Jag som nyss börjat bli van med OOP....

Permalänk
Medlem
Skrivet av heretic16:

Jag flyr från C och C++. Det har inget med att jag är okunnig. Snarare tycker jag att koden skrivs på ett sådant lustigt sätt. Varför ens sätta s_ före en variabel? Vad är syftet med detta brutala "rulla apelsin på tangentbord"-skrivsätt för att namnge variabler osv?

Varför skulle man sätta s_ före en variabel i C eller C++? Det låter som att du sett kod som använder ungersk notation och kopplat ihop det med C/C++ av någon anledning. Men i C/C++ får du namnge dina variabler hur du vill (med vissa tekniska begränsningar förstås), precis som i Java. Ungersk notation är något de flesta rekommenderar att inte använda, inklusive skaparen av C++ Bjarne Stroustrup.

Permalänk
Datavetare
Skrivet av perost:

Varför skulle man sätta s_ före en variabel i C eller C++? Det låter som att du sett kod som använder ungersk notation och kopplat ihop det med C/C++ av någon anledning. Men i C/C++ får du namnge dina variabler hur du vill (med vissa tekniska begränsningar förstås), precis som i Java. Ungersk notation är något de flesta rekommenderar att inte använda, inklusive skaparen av C++ Bjarne Stroustrup.

Att inte koda typen som del av namn finns numera även med i CppCoreGuidelines, regel NL.5.

Vidare så har C och C++ divergerat rejält som språk, att idag klumpa ihop C med C++11 och senare är ungefär som att klumpa ihop Pascal och Java. Alla dessa må vara olika imperativa språk, men modern C++ har väldigt lite gemensamt med C!

Java:

static void printPersonsOlderThan(List<Person> roster, int age) { for (Person p : roster) { if (p.getAge() >= age) { p.printPerson(); } } }

C++11

// finns även list<> i standard C++, men i 99 fall av 100 är vector<> bättre static void printPersonsOlderThan(vector<person> roster, int age) { for (auto p: roster) { if (p.getAge() >= age) { p.printPerson(); } } }

Fast detta blir lite mer komplicerat i Java, C++17

tuple<int, string> functionReturingTwoThings(); void someFunction() { auto [some_int, some_string] = functionReturningTwoThings(); ... // use "int some_int" and "string some_string" }

Och om man har rena funktioner (som i matematisk rena) i C++11 så kommer de evalueras direkt vid kompilatortillfället om det är möjligt, d.v.s. argumenten har kända värden när det hela kompileras. DET är riktigt coolt, för att inte tala om att det körs riktigt snabbt!

Direktöversättning av definitionen av Fibonacci-serien till funktioner (väldigt dålig algoritm tidskomplexitetsmässigt)

Java (restriktion i Java, finns ingen anledning varför man ska använda signed int här, men unsigned int finns inte!)

int fib(int n) { if (n < 2) { return n; } return fib(n - 1) + fib(n - 2); }

C++17

constexpr unsigned fib(unsigned n) { if (n < 2) { return n; } return fib(n - 1) + fib(n - 2); }

En anrop med konstant 45 tar på min jobblaptop (i7-5600U) 4,9 s i Java medan det är omedelbart i C++ då kompilatorn ersatt anropet med dess matematiska resultat.

Och inte ett s_ i sikte trots C++ exempel

Som Herb Sutter gjorde en gång en presentation med titeln: "Not your fathers C++". Har man inte titta på C++ på ett par år så vet man överhuvudtaget inte hur det ser ut idag. C++11 och senare är på många sätt ett nytt språk även jämfört med tidigare C++ (och sättet man programmerar har definitivt förändrats)!

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
99:e percentilen
Skrivet av sniglom:

Är skeptisk till att marknadens tröghet är problemet, Lisp dök upp på 50-talet och ML på 70-talet. Vad skulle göra att snöbollen är i mer rullning nu än valfritt annat årtionde? Haskell är häftigt så länge man håller sig inom dess safe space, men så fort man ska börja prata med libbar, OS eller liknande känns det inte fullt så kul. Prestandan lämnar också en del att önska.

I så fall uppfattar jag Erlang som mer redo för produktionslösningar, då det faktiskt snurrar på mycket hårdvara.

Vi pratar lite förbi varandra. När jag skriver att "den funktionella snöbollen är i rullning" menar jag inte enbart språk som faller under benämningen purely functional. Minst lika mycket syftar jag på det funktionella tankesättet inom programmering som helhet, i de stora imperativa språken. Framförallt rena (pure) funktioner, men även den mer allmänna betydelsen av "funktionell" som bara handlar om att se (rena eller orena) funktioner som data (som kan skickas runt och returneras precis som alla andra värden).

Och jag står fast vid att funktionell programmering (både i form av rent funktionella språk och tankesätt i andra språk) är på uppgång. Jag har inget "bevis" för det på rak arm, men det är uppfattningen jag fått under mina datateknikstudier på Chalmers (internationellt framstående inom FP), med allt vad det innebär av att lära sig om framsteg i branschen, lyssna på gästföreläsare, diskutera med andra med samma intresse samt allmänt hänga med i vad som händer.

Det betyder inte att (rent) funktionell programmering kommer "ta över", "döda paradigm x" eller liknande. Men jag ser branschen inspireras av bland annat Haskell, och jag tycker att vi programmerare har otroligt mycket att tacka det sistnämndas (och andra liknande språks) utvecklare för. De har lagt decennier inte bara på att driva utvecklingen framåt rent tekniskt/akademiskt, utan också outtröttligt lyft fram viktiga aspekter som ofta bara har viftats bort som oviktigt strunt av självutnämnda experter som sedan sätter sig och skriver nästa NullPointerException eller härva av obegriplig sidoeffektsbaserad spagettilogik.

Det betyder inte heller att (rent) funktionell programmering borde användas i alla lägen. Som vanligt gäller det att välja rätt verktyg för uppgiften. Inte heller är det så att det inte finns några som helst nackdelar med FP; det viktiga är att det finns enorma fördelar.

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Medlem
Skrivet av Alling:

Vi pratar lite förbi varandra. När jag skriver att "den funktionella snöbollen är i rullning" menar jag inte enbart språk som faller under benämningen purely functional. Minst lika mycket syftar jag på det funktionella tankesättet inom programmering som helhet, i de stora imperativa språken. Framförallt rena (pure) funktioner, men även den mer allmänna betydelsen av "funktionell" som bara handlar om att se (rena eller orena) funktioner som data (som kan skickas runt och returneras precis som alla andra värden).

Det kan jag definitivt hålla med dig om.

Skrivet av Alling:

Och jag står fast vid att funktionell programmering (både i form av rent funktionella språk och tankesätt i andra språk) är på uppgång. Jag har inget "bevis" för det på rak arm, men det är uppfattningen jag fått under mina datateknikstudier på Chalmers (internationellt framstående inom FP), med allt vad det innebär av att lära sig om framsteg i branschen, lyssna på gästföreläsare, diskutera med andra med samma intresse samt allmänt hänga med i vad som händer.

För mig är det en distinkt skillnad på uppgång och att snöbollen är i rullning. Just för att funktionella språk har haft uppgångar och nedgångar genom åren. Om det nu spelar roll för argumentationen, har jag också datateknisk chalmersbakgrund.

Skrivet av Alling:

Det betyder inte heller att (rent) funktionell programmering borde användas i alla lägen. Som vanligt gäller det att välja rätt verktyg för uppgiften. Inte heller är det så att det inte finns några som helst nackdelar med FP; det viktiga är att det finns enorma fördelar.

Finns definitivt fall där den funktionella paradigmen gör sig utmärkt. Jag tycker själv Erlang är väldigt intressant språk.

Visa signatur

CachyOS | 2x1440p 165Hz IPS | 7800X3D | 6950XT | 64GB@6GHz | 2x4TB SN850x

Permalänk
Datavetare

@sniglom & @Alling

är det inte så att vad som faktiskt har hänt är att en rad begrepp och finesser som traditionellt bara återfunnits i "funktionella språk" nu har letat sig in i de stora språken som Java, C# och C++ (och JavaScript har alltid haft det)?

Ser då ingen trend att något av de funktionella språken tagit sig ur sin extrema nischtillvaro.

Även om det finns sätt att hantera "mutable state" i funktionella språk brukar det knappast vara speciellt lättillgängligt och puritanerna burkar vara rätt snabba med eldkastaren om man försöker sig på något sådan. Det är en sak som kommer säkerställa att det förblir en nisch, för CPUer är helt optimerade för att hantera "mutable state" och utan enkelt access till den får man horribel prestanda.

Java8 har ju anonyma funktioner (lambda), vilket C# haft sedan länge och C++11 också har. I alla dessa tre språk stöds även "closures", vilket ihop med lambda-funktioner (funktioner som inte är bundna till ett namn) ger väldigt trevliga möjligheter. Till skillnad från många funktionella språk ger Java, C# och C++ möjlighet till att jobba med "mutable" state i closures (intressanta sätt att skjuta sig i fötterna här, framförallt i C++ men också väldigt kraftfullt om det används rätt).

C++11 kan göra specialoptimeringar för "rena" funktioner, en funktion måste sakna sidoeffekter för att kunna deklareras "constexpr" (så blir lite som uppdelningen i den rena- och monad-världen i Haskell). Skillnaden är att C++ lyckas integrera det på ett sätt som är realistiskt att förklara för någon annan Men i likhet med Haskell blir det kompileringsfel om man bryter mot renheten, vilket är precis vad man vill!
Här har Java/C# lite att jobba på i framtida versioner.

Håller vi oss till Java8 streams så har man ju realiserat vissa av de teoretiska fördelar man ofta hört kring automatisk parallellisering av kod i funktionella språk.

Så koncepten från funktionella språk har definitivt slagit igenom på bred front, däremot har de traditionellt funktionella språk stannat kvar som extremt smala nischer. Det är riktigt trevligt för att tvinga alla att alltid använda OOP är ett garanterat recept för spagetti, OOP har sina områden (UI-programmering är ett fall där OOP ofta är helt rätt) men finns väldigt många områden där OOP också är helt fel (typ de flesta för normal affärslogik).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer