- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Milyen széket vegyek?
- Egérpad topik
- Teljesen az AI-ra fókuszál az új AMD Instinct sorozat
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Fejhallgató erősítő és DAC topik
- AMD GPU-k jövője - amit tudni vélünk
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- TCL LCD és LED TV-k
Új hozzászólás Aktív témák
-
#6599
emvy
félisten
WonderCSabo
#6598
válasz
WonderCSabo
#6598
üzenetére
Igazad van, a metaadatok koze bekerul, de runtime tipusellenorzes ettol meg sajnos nincs:
public class IntegerList extends ArrayList<Integer> {
}
public static void main(String[] args) {
IntegerList l = new IntegerList();
ArrayList<Integer> l2 = l;
ArrayList l3 = l2;
ArrayList<Object> l4 = l3;
l4.add("Hello World");
System.out.println(l.get(0)); // "Hello World" sztring az IntegerList elso eleme
}Ehhez kepest:
Ezek persze mind megszokhatoak, csak csokkentik a tipusbiztonsagot.
-
#6598
WonderCSabo
félisten
emvy
#6596
WonderCSabo
félisten
Ebben tévedsz, a reflectionnel ebben az esetben valóban le lehet kérdezni az az Integer-t. Ezt használja ki a Guava/Guice/stb TypeToken/TypeLiteral megoldása:
Type genericSuperclass = IntegerList.class.getGenericSuperclass();
ParameterizedType pt = (ParameterizedType) genericSuperclass;
System.out.println(pt.getActualTypeArguments()[0]); -
#6597
Aethelstone
addikt
WonderCSabo
#6595
Aethelstone
addikt
válasz
WonderCSabo
#6595
üzenetére
Viszont a generic nem is azért van, hogy runtime kiderítsük, hogy pl. egy List-nél mi a <közötti> pontos típus. Az csak hab lenne a tortán, de speciel én abszolúte nem érzem hiányát.
-
#6596
emvy
félisten
WonderCSabo
#6595
válasz
WonderCSabo
#6595
üzenetére
> class IntegerList extends List<Integer> {}
vegulis meg igy se, mert az IntegerList az egy sima List lesz csak, Objecteket fog tarolni..
-
#6595
WonderCSabo
félisten
floatr
#6588
WonderCSabo
félisten
mert runtime elérhető a típusinformáció (Reflection).
Öööö tuti?
Ha van egy ilyened:
class IntegerList extends List<Integer> {}
Akkor igen.
De ha ezt írod:
List<Integer> list ...;
Akkor a büdös életben nem fogod kideríteni runtime, hogy mi volt a <> között pontosan. És biztos vagyok benne, hogy a legtöbben erre gondolnak a generikus alatt.
-
#6594
floatr
veterán
Aethelstone
#6592
floatr
veterán
válasz
Aethelstone
#6592
üzenetére
Mondjuk engem azért végtelenül bosszant az, ahogy mostanában alakulnak a dolgok a való életbeli projekteken: a legdurvább bleeding edge technológia Liferay alatt struts. Kicsit tényleg olyan fortran 77-es feelingje van az egésznek
-
#6593
floatr
veterán
Aethelstone
#6592
floatr
veterán
válasz
Aethelstone
#6592
üzenetére
És ez saccra a lambdával is így lesz. Ettől függetlenül gagyi...
-
#6592
Aethelstone
addikt
emvy
#6591
Aethelstone
addikt
egyszer irtam egy cuccot Hibernate fole, ami okos proxykat/wrappereket gyartott, amik a peldany getter/setter hivasait elkaptak runtime,
Azért azt Te is érzed, hogy ez nem egy tipikus/mindennapi use-case
Másrészt a Java fejlesztők 99%-a anélkül megy nyugdíjba, hogy valaha Reflectiont kellett volna használnia (Hacsak nem csinál saját annotációkat) -
En a generikus parameter tipusara gondoltam, nem ugy altalaban az RTTI-ra. Tehat arra, amit te is irsz. Hallottam mar a reflectionrol.
De gondolom mindenki irt mar olyan konstruktorokat, ami a generikus parameternek megfelelo osztaly objektumot is varta (kb. public SomeClass(T1 param1, T2 param2, Class<T1> clazz1, class<T2> clazz2, mert szukseg van ra .. -- egyszer irtam egy cuccot Hibernate fole, ami okos proxykat/wrappereket gyartott, amik a peldany getter/setter hivasait elkaptak runtime, na az tele volt ilyen hekkekkel).
-
floatr
veterán
-
#6587
emvy
félisten
Aethelstone
#6586
válasz
Aethelstone
#6586
üzenetére
Mint a ... ? A C++-al nem erdemes hasonlitani, mert ott nincsenek generikusok, csak templatek, az meg tok mas, a <> jelolesen kivul sok kozuk nincs egymashoz. A .Net-hez kepest miert kenyelmesebb a Java generikus-megvalositas?
-
#6585
emvy
félisten
Aethelstone
#6584
válasz
Aethelstone
#6584
üzenetére
Azert az, hogy runtime nem elerheto a tipusinformacio, nem annyira kenyelmes... meg ugye a boxing...
-
#6584
Aethelstone
addikt
WonderCSabo
#6583
Aethelstone
addikt
válasz
WonderCSabo
#6583
üzenetére
Nem elcseszett az, hanem egyszerűen csak sajátos. Nyilván a c++ template-hez hasonlítják sokan, de ez nem az.
-
#6583
WonderCSabo
félisten
beleszólok
#6579
WonderCSabo
félisten
válasz
beleszólok
#6579
üzenetére
Kicsit hosszú lenne itt részletezni (mást ne mondjak: tömböt gyárthatok elemi típusokból is, egyebeket csak objektumokból)
Fú, ne keverjük a szezont a fazonnal. Ennek a dolognak, amit említettél, nem sok köze van magához a listához és a tömbhöz, ez a Java (nagyon sokak szerint elcseszett) generikus működése miatt van.
Egyébként a python list, és a Java ArrayList ugyanaz, csak más szintaktikával tudod elérni a műveleteit.
-
#6582
Aethelstone
addikt
beleszólok
#6577
Aethelstone
addikt
válasz
beleszólok
#6577
üzenetére
Kicsit a "kőkorban" érzem magam miatta, amikor még PL/I-ben, Clipperben programozgattam.
Rossz a megközelítés. Akkor lennél a kőkorban, ha a tömböt hákolták volna meg dinamikussá. Egészen egyszerűen újabb adattípusokat vezettek be, amik már máshogy kezelendpk, mint a tömb. Ennyi.
-
#6581
Aethelstone
addikt
WonderCSabo
#6576
Aethelstone
addikt
válasz
WonderCSabo
#6576
üzenetére
Persze, értem én, de egy kicsit továbbgondoltam. Azért írtam, hogy dühöngés
-
#6580
floatr
veterán
beleszólok
#6577
floatr
veterán
válasz
beleszólok
#6577
üzenetére
Amit nem látsz más nyelvekben az az, hogy hogyan van ténylegesen implementálva a "tömb". Javaban az ArrayList és tsai alacsony szintig követhetően implementált dinamikus tömb. Hogy most beírhatsz-e olyat, hogy list[2578] = "foo"; az egy dolog, a hátterében működhet sokminden:
-- pl operátor overloading, ami egy saját metódust hív, amikor [] operátort talál
-- egy automatikus memóriafoglalás a háttérben 2578 + buffer méretig
-- máshol egy hash-alapú map jön létreEz az egész rajtad áll vagy bukik, de elvárni sok automatizmust a nyelvtől azt fogja eredményezni, hogy vagy a fordító, vagy a végrehajtás lassú lesz. Az meg a másik, hogy sok értelmét nem látom egy ilyen műveletnek, bár lehetnek specifikus esetek nyilván; ide specifikus ötletek kellenek, pl. treemap.
-
#6579
beleszólok
senior tag
WonderCSabo
#6578
beleszólok
senior tag
válasz
WonderCSabo
#6578
üzenetére
Hm. Lehet...
Nem vagyok igazán java-s.Kicsit hosszú lenne itt részletezni (mást ne mondjak: tömböt gyárthatok elemi típusokból is, egyebeket csak objektumokból)
-
#6578
WonderCSabo
félisten
beleszólok
#6577
WonderCSabo
félisten
válasz
beleszólok
#6577
üzenetére
viszont engem pusztán az zavar, hogy nincs olyan tömb, amihez utólag, másolás nélkül tudnék hozzáadni újabb elemeket
Én ezt most már nem értem...
Egyébként meg ArrayList és nem ListArray.
-
#6577
beleszólok
senior tag
WonderCSabo
#6576
beleszólok
senior tag
válasz
WonderCSabo
#6576
üzenetére
Az a baj, hogy nem igazán arra gondoltam, amit írtál.
Lehet, hogy a nyelvek oldaláról ez a helyzet, viszont engem pusztán az zavar, hogy nincs olyan tömb, amihez utólag, másolás nélkül tudnék hozzáadni újabb elemeket. Kicsit a "kőkorban" érzem magam miatta, amikor még PL/I-ben, Clipperben programozgattam.
Az egyéb objektum típusok más kategóriába tartoznak.
Persze nem lenne rossz, ha pl. egy ListArray elemeit is lehetne indexelni (mégiscsak rövidebb a [...] hivatkozást leírni, mint a .get(...)-t), de azért ez mégis másik történet. -
#6576
WonderCSabo
félisten
Aethelstone
#6573
WonderCSabo
félisten
válasz
Aethelstone
#6573
üzenetére
Én csak azt akartam mondani, hogy a párhuzam korrekt volt...
-
#6575
beleszólok
senior tag
Aethelstone
#6574
beleszólok
senior tag
válasz
Aethelstone
#6574
üzenetére
Lásd lambda hiánya, mint egyetlen példa...
Hány éven át sírt miatta a sok tudatlan?
(ha jól rémlik, a 7-es vagy 8-as talán már tud ilyet is) -
#6574
Aethelstone
addikt
Aethelstone
#6573
Aethelstone
addikt
válasz
Aethelstone
#6573
üzenetére
Plusz az a tapasztalatom, hogy a Java(egyéb nyelvek) fejlesztői nagyon sok esetben nincsenek teljesen tisztában a nyelv adta lehetőségekkel, hanem ahelyett, hogy ezen hiányosságaikat pótolnák, nyavalyognak, hogy miért nincs ez meg az a nyelvben, jóllehet ha nem is pontosan úgy, ahogy elképzelik, benne van, max. használni kellene pár design patternt, meg fantázia meg RTFM!
-
#6573
Aethelstone
addikt
WonderCSabo
#6572
Aethelstone
addikt
válasz
WonderCSabo
#6572
üzenetére
Az a helyzet, hogy kissé már unom ezt a "nyavalygást", ami itt egyesek részéről az utóbbi időben itt felmerült. Miért nincs operator overload, miért nincs lambda, miért van null és társai. Annak idején talán én írtam pár mondatot arról, hogy nem túl jó ötlet, hogy más programnyelvek "okosságait" próbálják beépíteni a Java-ba kontroll nélkül, mert a felhasználók nyavalyognak. Megnézik a Pythont, a JS-t, a Perlt, a C#-t és jaj de jó lenne, ha lenne...közben meg a nyelv eredeti logikájához semmi köze. Legutolsó kedvencem a default implementációk interfészben...de erről is már volt vita errefelé
Emberek, this is Sparta (this is Java)!! Kedvenc C++ tanáromtól annak idején megkérdeztem, hogy van-e nyelvi támogatás a C++-ban a közvetlen ősre(super vagy parent). Azt mondta, hogy nincs, de a C#-ben van. Ha kell, akkor használjam azt. Ennyi.
Nah zártam a mai dühöngésemet
-
#6572
WonderCSabo
félisten
Aethelstone
#6571
WonderCSabo
félisten
válasz
Aethelstone
#6571
üzenetére
De, jogos az összehasonlítás, mert azokban a nyelvekben, ahol van operátortúlterhelés (pl. python, C++), ott a collection osztályoknál és indexelő operátort használnak. Ezt hiányolja beleszólok.
-
#6571
Aethelstone
addikt
beleszólok
#6566
Aethelstone
addikt
válasz
beleszólok
#6566
üzenetére
Nem összehasonlítható. Az egyik tömb, a másik pedig egy collection egy elemére hivatkozás. Teljesen más tészta a két történet.
-
#6570
floatr
veterán
beleszólok
#6566
floatr
veterán
válasz
beleszólok
#6566
üzenetére
Ez is csak szépészeti beavatkozás lenne, hogy operátor vagy metódus. Az mondjuk tény, hogy c++ alatt ott kezdődik a probléma, hogy a new is operátor, amit át lehet definiálni. Mondjuk én nem kuporodtam miatta sírva a sarokba, mert a java-féle heap-kezelést lehetett vele utánozni osztály - pointer osztály párosokkal, de részletkérdés, hogy a[5] vagy a.get(5). Iterátorokat többet használja az ember, nekem sem rémlik h mikor címeztem direktbe pozíciót utoljára.
-
#6569
M_AND_Ms
veterán
beleszólok
#6568
M_AND_Ms
veterán
válasz
beleszólok
#6568
üzenetére
Csak a stackoverflow-nak nem ez célja. Problémákra a megoldást hozza, nem pedig a terjedelmes elméleti fejtegetéseket.
-
#6568
beleszólok
senior tag
Jim-Y
#6567
beleszólok
senior tag
Tudom, csak bosszantó, hogy ott van a rengeteg jó szakember egy tömegben és nem hagyják őket érvényesülni ezzel a ... nevezzem kicsinyesnek? ... hozzáállással. A lapcsalád rengeteg oldala közt talán elfért volna egy-két beszélgetős fórum is. Na mindegy, nem az enyém, csak mindig felmegy a vérnyomásom, mikor ilyet látok.
-
#6567
Jim-Y
veterán
beleszólok
#6563
Jim-Y
veterán
válasz
beleszólok
#6563
üzenetére
A stack szerintem alapvetően arra jó, hogy ha valahol elakadsz, akkor több mint valószínű, hogy találsz rá megoldást az oldalon, de ha csak + információt szeretnél felvenni, akkor nem a megfelelő platform. Pont amiatt amit írtál. Én ha bővíteni szeretném a spektrumom, akkor redditre és twiterre járok, itt megnyitom az érdekes linkeket és ezek alatt sokszor lehet is beszélgetni a kommentekben, és nem zárják be azzal, hogy offtopik
-
#6565
emvy
félisten
beleszólok
#6560
válasz
beleszólok
#6560
üzenetére
Az ArrayList az pont az, mint amit a dynamic array Pythonban, szoval ne szomorkodj tul sokat. Ugyanugy amortizalt O(1) az append, O(N) az insert, es O(1) az index..
-
#6564
emvy
félisten
beleszólok
#6560
válasz
beleszólok
#6560
üzenetére
A Scala sokkal fiatalabb nyelv. Egyébként terjed rendesen, a pénzügyi szférában már tolják rendesen. A compiler elég lassú még, a nyelv meg eleg nagy (komplex).
-
#6563
beleszólok
senior tag
WonderCSabo
#6561
beleszólok
senior tag
válasz
WonderCSabo
#6561
üzenetére
"closed as not constructive "
Ettől megyek a falnak, ha a stackoverflow szóba kerül...
Érdekes téma, értelmes társalgás, de "not constructive"
-
#6562
emvy
félisten
WonderCSabo
#6561
válasz
WonderCSabo
#6561
üzenetére
Egy a keves jo design döntés közül
(aki CPPben jaratos,az tudja, mirol beszelek...) Operator overloading + implicit konverziók = katasztrófa.. -
#6561
WonderCSabo
félisten
beleszólok
#6560
WonderCSabo
félisten
válasz
beleszólok
#6560
üzenetére
Igen, pythonban is van operátortúlterhelés. Javában nincs, hogy miért az itt olvasható. A Java kritikájának egyik első eleme az operátortúlterhelés hiánya.
-
#6560
beleszólok
senior tag
WonderCSabo
#6559
beleszólok
senior tag
válasz
WonderCSabo
#6559
üzenetére
Hát én python felől közelítem meg a témát, C++ nem mond sokat, de akkor szomorúan tudomásul veszem, hogy ez ilyen.
Tankjú.off: néha elgondolkodom rajta, hogy a scala miért nem terjedt el a java mellett...
-
#6559
WonderCSabo
félisten
beleszólok
#6558
WonderCSabo
félisten
válasz
beleszólok
#6558
üzenetére
Javában egy féle tömb van:
String[] array = new String[20]
Ennek futásidőben lehet méretet adni, szóval a C++ -os dinamikus memória lefoglalású tömbbel analóg. Ennek a mérete fix, és van indexelő operátora. Vannak osztályok, amik ezt a tömböt felhasználva változtatható méretű listát implementálnak, pl. ilyen az ArrayList. Valóban csak metódusokkal lehet elérni az elemeit, de ennek az oka alapvetően az, hogy Javában nincs operátortúlterhelés.
-
#6558
beleszólok
senior tag
beleszólok
senior tag
Lehet, hogy csak akartam kérdezni, de végül nem tettem meg? Pedig úgy rémlik, a napokban kérdeztem ilyet: javaban a dinamikus tömb fogalma nem létező dolog?
Azt tudom, hogy vannak mindenféle listák és hasonlók, de úgy tűnik, ezek elemeire nem lehet index-szel hivatkozni, get/set metódusok és hasonlók állnak csak rendelkezésre, a tömbök meg fix méretűként viselkednek.
Ezt jól látom vagy valamit elnéztem? -
-
Jim-Y
veterán
Én most vettem a laptopomba + memóriát 4 > 8, illetve a HDD-t kicseréltem SSD-re, és nagyon megköszönte a rendszer. Linuxot használok és itt is baromi látványos lett a javulás. Én az élettartamtól nem tartok..addig bőven nem tervezem használni a gépet, mire bemondaná az unalmast. Pedig most minden SSD-n van, nem csak a rendszer
-
#6552
emvy
félisten
beleszólok
#6550
válasz
beleszólok
#6550
üzenetére
> RAM-ból 16G azt hiszem, mostanság már majdhogynem alap.
Ja, csak a nyomorult gyartok nem raknak ennyit a gepekbe.
-
floatr
veterán
válasz
bucsupeti
#6549
üzenetére
Minimum egy i5-ös, 8+GB RAM, egy jobb intel integrált video és 6+ cellás akku. Ez eléggé energiatakarékos is, hogy kábel nélkül pár órát tudd használni. SSD-ről nem tudok nyilatkozni, de kicsit még tartok az élettartamától -- nagyobb rendszerek, alkalmazásszerverek esetén jól jöhet
-
#6550
beleszólok
senior tag
bucsupeti
#6549
beleszólok
senior tag
válasz
bucsupeti
#6549
üzenetére
Azt kihagytad, hogy nagyságrendileg mennyi rá a keret.
Így elég nehéz.
Nekem a kis játszadozásaimhoz elég egy virtualboxban futó linux 2-3GB RAM-mal (eclipse + xubuntu), egy több mint három éves Dell Latitude gépen, i5-2520m procival.
Ennél sokkal erősebb talán nem kell, ha nem valami extrém dologra fejlesztesz, de kiindulva az esetleges későbbi igényekből:min i5 kategóriájú, hardveres virtualizációt támogató processzor (nem vagyok képben, hogy most mik vannak, az i7 szerintem felesleges - a hardveres virtualizáció azért fontos, mert előbb vagy utóbb, de rákényszerülsz, hogy virtuális gépe(ke)t is futtass.
RAM-ból 16G azt hiszem, mostanság már majdhogynem alap.
Amit fontosnak tartok: minél nagyobb felbontású kijelző/monitor. Ha nem akarod sokat hurcolni, akkor valahol 15" körüli méret, ha hurcolni is akarod, akkor inkább külső billentyűzet és monitor a mindennapos munkára.
A kijelző lehetőleg matt - ez úgy vettem észre, nem egyedi igény részemről, sokan utálják a csillogó képernyőt.Típust nem mernék ajánlani. Régebben Thinkpad-re szavaztam volna (T60, T61 még jó gépek voltak), amíg nem volt Dell gépem, addig második helyen a Dell állt (Latitude vagy... asszem, precision ami fölötte van), mióta van, azóta nem tudom szeretni őket.
(egy elfogadható Latitude konfig közel fél milla! ) -
floatr
veterán
Alapvetően üzleti logikára koncentrálok a legtöbbször. Nekem kifejezetten jó, ha nullptr van, mert az exception megszakítja a tranzakciókat. Ha optional-t használnék akkor egy if-ben kéne eldobni a kivételt. A kapcsolódó rétegben try-catch néha szokott lenni, de legtöbbször azt is rábízom a konténer hibakezelésére, amit delegálok egy konkrét komponensnek. Ehhez képest az optional csak gurigázás a pamutgombolyaggal
Nem mondom, néha jobb választás lehet, mivel a kivételek kezelése nem feltétlenül cél. Ilyenkor a mechanizmus teljesítménye jobb tud lenni egy if-else megoldással, de ez inkább szépészeti megoldás. Ha valakinek ez problémát okoz, akkor el tudom képzelni ahogy egy merészebb JS frameworktől kifolyik a szeme.
-
#6547
axioma
veterán
Aethelstone
#6535
axioma
veterán
válasz
Aethelstone
#6535
üzenetére
OK, amennyiben exception-nel kiegeszited a null helyet, akkor igaz. Mas kerdes, hogy egy egysoros try-catch csak az IllegalArgumentException elkapasara (mondjuk) mennyire felelsleges bonyolitasa (=rosszabb olvashatosaga) a kodnak. Ha visszaterunk az adatsor kiertekelesre, ahol jonnek az ertelmes adatok 1..99, a hiba meg a -1, es az osszes feladat mindossze az atlagolas, akkor inkabb irnek egy if-et (persze nem a -1-re hanem megfelelo beszedes konstansra), hiszen a cel nem az hogy lealljunk es tovabb ne is csinaljuk a lekerdezest, hanem a jelolt adatot ne vegyuk figyelembe, kezeljuk mashogy (akar az meg egy statisztikai szamlalot novel). Ezt hiaba lehet leirni exception-nel is, en erosen agyuval verebre esetnek ereznem.
Sot, az exception eroltetese a hibajelzo visszateresi ertekkel szemben szerintem csokkenti a kod fuggvenyekre bontasi hajlandosagat. Azt elismerem, hogy igy meg a kepernyore is kikerulo nullpointerexc.-k jellemzoek tulsagosan... az arany kozeputat kene megcelozni. -
#6546
floatr
veterán
Aethelstone
#6543
floatr
veterán
válasz
Aethelstone
#6543
üzenetére
Attól függ. Ha private adattagokkal smúzolsz, akkor kell egy kis dinamikus proxy (cglib, asm), és már megint lelépi a kiccsákókat.
-
#6544
floatr
veterán
Aethelstone
#6543
floatr
veterán
válasz
Aethelstone
#6543
üzenetére
Hú megint hitvita...
-
#6542
floatr
veterán
Aethelstone
#6541
floatr
veterán
válasz
Aethelstone
#6541
üzenetére
Hogy egy ismerősömet idézzem az ilyen kiindulási alapoknál: "ebből még bármi lehet"
De ahogy érzedAzért ez a "heavyweight" kissé molesztáló a springre nézve
ahhoz képest h a j2ee-nek annó ez volt a light alternatívája -
#6540
WonderCSabo
félisten
WonderCSabo
félisten
Lehet, hogy ehhez a beszélgetéshez is vagy át kéne menni a Programozás topikba, vagy egy új topikot létrehozni, mert eléggé túlmutat a Java keretein.
-
#6537
Cathfaern
nagyúr
Aethelstone
#6535
Cathfaern
nagyúr
válasz
Aethelstone
#6535
üzenetére
"Üzleti logika szempontjából az üres lista pont annyit ér, mint a null referenciával rendelkező."
Nem igazán. Üzleti logika szempontjából az üres lista azt jelenti, hogy pl. egy lekérdezésnek nincs találata, a null referencia pedig azt, hogy valami programhiba történt. Előbbi esetben elég megjeleníteni az üres listát, utóbbi esetben viszont figyelmeztetni kell a usert, hogy nem az történt, mint amit szeretett volna. -
#6536
floatr
veterán
Aethelstone
#6532
floatr
veterán
válasz
Aethelstone
#6532
üzenetére
Én ezt springgel oldanám meg egy felhasználási területtől függő scope-ban élő beannel
(#6531) beleszólok globális változó mint olyan nem is szabad h legyen, mert nem menne át a kód review-n
A VM egyébként is moduláris a classloader tekintetében; szóval relatív a globális. Egy kontextusban lehet alkalmazásra nézve globális valami, de nem szabad elfelejteni, hogy több kontextus is szaladgálhat egy VM alatt. Workaroundként a public static változókat szokták néha használni, de nem bátorítanálak erre. -
#6535
Aethelstone
addikt
axioma
#6534
Aethelstone
addikt
Üzleti logika szempontjából az üres lista pont annyit ér, mint a null referenciával rendelkező. Viszont üres lista esetén le tudod spórolni az if (list!=null&&!list.isEmpty()) vizsgálatot egy sima list.isEmpty()-vel, sőt iterátor for ciklusban sem fog szétszállni nullpointerexceptionnal.
Egyébként jelen pillanatban egy kézenfekvő, bár kurvára idegesítő megoldása lenne a problémának, ha a nullpointerexception nem runtime lenne, hanem checked. Persze, az összes, jelenlegi kód összefosná magát tőle
-
#6534
axioma
veterán
Aethelstone
#6525
axioma
veterán
válasz
Aethelstone
#6525
üzenetére
A listas peldaddal nem ertek egyet. Mert lehet, hogy ervenytelen, lehet hogy ervenyesen ures, es lehet hoyg nem ures. Ha az ervenytelent az uressel jelzed, akkor nem tudod megkulonboztetni a vegen, hogy ez most egy hasznalhato adatsor vagy sem... (mint amikor rarakjak egy meresi adatsorra a -1 -et ervenytelennek, de amikor az utolso 100 adatbol statisztikat kell csinalni, bamban azt is beleatlagoljak... lattunk ilyet kiszallitott kodban, nem java volt, de nem kis rendszer resze). Termeszetesen a listat is tovabb lehet fejleszteni, hogy tudja magarol hogy ervenyes-e, de azzal csak technikailag szuntetted meg a null-t, az ertekadas le fog futni ervenytelen ertekre is - ott is ahol nem figyelsz ra, mert nem lathatoan jon vele az info, hogy itt me'g hiba is lehet, vagy ez mar lecsupaszitott tuti ertek. Az meg nyilvan abnormalis, hogy minden egyes hasznalat elott megprobalod kicsomagolni.
Jelzem hogy en nem akarom a null-t szamuzni mindenaron, csak megertem azt a fajta logikat is, es nem tartanam problemanak atterni ra, kicsit jobban absztraktalva lenne mar a fuggveny megirasakor, hogy van-e hibaag. Vagyis belatom, hogy meg lehetne azt nagyon jol es megszokas utan kenyelmesebb programozast biztositoan csinalni. (Nagyon absztraktul nezve ez kivalthatja az exception dobasi rendszert is, a visszateresi ertekbe is becsomagolhato, mondhatnank csak az exception vagy a valos ertek lehet benne, a try-catch meg oly mindegy hogy honnan kihamozott adat alapjan mukodik.) -
#6533
fordfairlane
veterán
beleszólok
#6529
fordfairlane
veterán
válasz
beleszólok
#6529
üzenetére
Szerintem a main-be tett publikus változó, az nagyjából megfelel a globális változónak, de OK, valóban, a javanak nincs olyan nyelvi konstrukciója, ami valódi globálist valósítana meg.
Egy public static változó vagy metódus szerintem tekinthető globálisnak.
-
#6532
Aethelstone
addikt
beleszólok
#6531
Aethelstone
addikt
válasz
beleszólok
#6531
üzenetére
Ha már nekem tudtál stackoverflow linket adni, akkor magadnak is kereshetnél.
http://stackoverflow.com/questions/4646577/global-variables-in-java
-
#6531
beleszólok
senior tag
Aethelstone
#6530
beleszólok
senior tag
válasz
Aethelstone
#6530
üzenetére
No igen, ez megint vallási téma?
Egyik oldal: getter/setter, másik oldal: inkább publikus, de legalább protected.
(bár ez lehet, hogy python specifikus volt, amiben nincs igazán protected... kicsit bizonytalan vagyok) -
#6530
Aethelstone
addikt
beleszólok
#6529
Aethelstone
addikt
válasz
beleszólok
#6529
üzenetére
Nos, bármelyik osztályban található public változó (property, adattag, kinek hogy tetszik) globálisnak tekinthető. Az más kérdés, hogy ha nem muszáj, márpedig sosem muszáj, nem definiálunk public változókat. Szerintem.
-
#6529
beleszólok
senior tag
emvy
#6527
beleszólok
senior tag
DI-t említeni sem mertem.
Különösen, hogy anno, PHP-vel játszadozva rövid úton oda jutottam, hogy ehhez már keretrendszer kell.
(és most megint valaki azt fogja mondani, hogy kötözködök)
Szerintem a main-be tett publikus változó, az nagyjából megfelel a globális változónak, de OK, valóban, a javanak nincs olyan nyelvi konstrukciója, ami valódi globálist valósítana meg.long vs 64 bit... jellemzően már eszembe sem jut, hogy még léteznek 32 bites rendszerek is. Bennem csak annyi volt, hogy a java long = 64 bites int, az meg már processzor szinten is elemi adat.
-
#6527
emvy
félisten
beleszólok
#6526
válasz
beleszólok
#6526
üzenetére
Java-ban nincs igazabol globalis valtozo, talan a szingleton all hozza legkozelebb, de neked meg erre sincs szukseged. A main-t tartalmazo osztalyodban legyen egy publikus AtomicInteger, aztan kesz.
Bar tuti jon valaki, aki elmondja, hogy dependency injectionnel lesz igazi enterprajz megoldas
Masik kerdesedre: az int az tuti atomic, a long az vagy atomic, vagy nem. Az int 32 bites, a long 64, a VM implementacionak garantalnia kell az intek atomikus irasat/olvasasat, a longoket nem. Belemehetunk abba, hogy ez miert van -- elsosorban azert, mert 32 bites architekturakon a 64 bites ertekek atomikus irasa teljesitmenyvesztessel jar.
-
#6526
beleszólok
senior tag
emvy
#6524
beleszólok
senior tag
Köszi.
(mondom: nagyon rég és nagyon keveset foglalkoztam ilyesmivel, most meg csak úgy felszínesen tesztelgetem, szóval nem lesz belőle komoly szoftver )Az az atomic integer érdekes egyébként... ez ugye elvileg egy globális változó lenne, amire sokan fújnak. (vagy rosszul értem?)
A másik érdekesség, amit minap fedeztem fel: az int, az atomic, a long (állítólag) nem az. Vajon miért?
Na mindegy... -
#6525
Aethelstone
addikt
axioma
#6513
Aethelstone
addikt
Tervezési minta kérdése.
Pl. ha List<?> a visszatérési típus, akkor ugyan fektessük már le, hogy ha üres, akkor nem null, hanem pl. new ArrayList<?>() és így tovább. Vagy pl. default értékek használata a privát propertyk esetén és sorolhatnám.
Sokan nem szeretik az ilyen kvázi felesleges tervezési mintákat, hanem a compilertől várják, hogy a slendrián kódokat tegye helyre...alapvetően sok igazságuk van, de ugyan, az emberi hülyeséget miért kellene már javítani?
Kedvencem egyébként, amikor pl. C-ben vagy Pascalban szól a compiler, hogy hiányzik a ";". Bassza meg, akkor rakja oda, ne dumáljon, az miért nem zavar senkit?
Az a baj, hogy a konkrét problémában valamit mindenképpen vizsgálni kell. A null az valóban rendszeridegen, egy olyan kvázi mittoménmilyen érték, aminek semmi köze az üzleti logikához.
-
#6524
emvy
félisten
beleszólok
#6522
válasz
beleszólok
#6522
üzenetére
Ez konkretan ugy nez ki, hogy van egy concurrentlinkedqueue, amibe a file reader tolja a sorokat, a masik oldalon meg van egy executorservice thread pool, ami szedegeti ki az elemeket, es egy AtomicInteger novelgetsz.
Ez kb. a Concurrency 101 elso hetenek consumer-producer peldaja egyebkent.
-
#6523
emvy
félisten
beleszólok
#6521
válasz
beleszólok
#6521
üzenetére
Nem hivjak valtozonak, erteknek hivjak. Mindegy.
-
#6522
beleszólok
senior tag
emvy
#6520
beleszólok
senior tag
Most, konkrétan csak annyit akarok, hogy az említett szövegfájlt végigolvasom egy szálon, több másikon meg feldolgozom a beolvasott adatokat. A feldolgozás abból áll, hogy megnézem, illeszkedik-e egy adott reg.exp.-re a kapott sor, ha igen, akkor növelek egy számlálót.
Egyelőre csak puszta kíváncsiság: sikerül-e java-ban gyorsabbra megírni ugyanazt, ami pythonban elég rendesen felgyorsította a számolást a soros, egyszálú feldolgozáshoz képest. (a regex illesztés cpu igényes művelet, nélküle 3-4sec, vele 22-24sec mire benyalja a teljes fájlt)
-
#6521
beleszólok
senior tag
floatr
#6519
beleszólok
senior tag
Funkcionális nyelvektől hülyét kapok, de komolyan.
Változónak hívják a konstansokat, miközben változó nincs bennük... Ott adtam fel, mikor megpróbáltam megérteni, hogy lehet egy számlálót létrehozni erlang/haskell nyelvek valamelyikében. (sikerült, de valami iszonyatos) -
#6520
emvy
félisten
beleszólok
#6518
válasz
beleszólok
#6518
üzenetére
Hat, attol fugg, hogy es mit akarsz kommunikalni, szinkron vagy aszinkron, etc. Ott vannak pl. a ConcurrencCollection-ok, de akar hasznalhatsz sima osztott referenciakat is alapveto szinkronizacios mechanizmusokkal (lock, condition, stb.) -- mindegyik problemas, mas-mas szinten..
-
floatr
veterán
Belezavarodsz, aztán hülyeséget csinálsz, mindkét esetben ugyanannyi haszna van a terméknek.
(#6516) beleszólok itt egy elég jó magyarázat az optional-ről [link] A funkcionális matyik imádják ezt is, de ha átfutsz az api nyújtotta lehetőségeken, akkor rengeteg körítés van ugyanazon probléma más megoldásához.
-
#6518
beleszólok
senior tag
beleszólok
senior tag
Java multithreading: mit szokás használni a szálak közti kommunikációra, ha nem akarok egy komplett keretrendszert beüzemelni miatta?
Saccra 50-100MB-os csomagokat küldözgetnék egy producerből több consumer szálnak.Pythonban egyszerűen a multithreading.Queue-t használtam (illetve a multiprocessing.Queue-t, miután kiderült, hogy létezik a GIL, ezért nincs használható multithreading a cPythonban, de nagyjából ugyanaz).
-
#6516
beleszólok
senior tag
floatr
#6515
beleszólok
senior tag
Engem érdekelne ez a téma, de itt úgy érzem, túlságosan off.
Átmehetnénk vele ide: http://itcafe.hu/tema/programozas_forum/friss.html ? -
floatr
veterán
Nem igazán tudok egyetérteni ezzel az egész nullptr savazással. Van most is optional, de sztem amennyi energiát ráfordít az ember, annyival a null-t is lehet kezelni.
Az viszont kétségtelen, hogy egy gyakorlatlan ember könnyen benézi, de ugyanez az ember az optional-be is is belezavarodik.
(#6514) Cathfaern nullptr hibák kihasználásával konkrétan rövidebb kódot lehet írni, ha tudja mit csinál az ember
-
#6513
axioma
veterán
Aethelstone
#6512
axioma
veterán
válasz
Aethelstone
#6512
üzenetére
Szerintem itt elvi uton van elteres; a lenyeg nem a case-en van, hanem hogy case nelkul nem tudsz erteket adni a celvaltozonak kozvetlen -- azaz hogy tevedesbol se tudod leirni, hgoy enOsztalyom=enFuggvenyem() es utana rad van bizva, hogy case-elsz vagy sem null miatt, hanem a visszateresi erteked muszaj vizsgalnod, azzal tudod kiszedni a valodi erteket belole.
-
#6512
Aethelstone
addikt
emvy
#6511
Aethelstone
addikt
Végigolvastam és értem is a koncepciót. Nyilván teljes nyelvi támogatás kell ahhoz, hogy igazán jó legyen.
Viszont csak megjegyzésképpen:switch ret {
case None: print "Nincs visszateresi ertek"
case Integer(i): print "Az Integer ertek: " + i.toString()
}switch ret {
case null: print "Nincs visszateresi ertek, mivel null"
case Integer(i): print "Az Integer ertek: " + i.toString()
}Nos, maximum itt annyi van, hogy a "rendszeridegen" null kerül eliminálásra..
-
#6511
emvy
félisten
Aethelstone
#6510
válasz
Aethelstone
#6510
üzenetére
Itt szepen es erthetoen leirjak (az elso valaszban).
De akkor roviden en is leirom -- egy klasszikus pelda a megoldasra: Option tipus.
Ha van pl. egy fuggvenyed, ami Integer ertekkel ter vissza, akkor a fordito garantalja, hogy az Integer lesz, es nem null. Ha egy masik, alapvetoen Integert visszaado fuggvenyed nem mindig tud visszaterni Integerrel, mert pl. kivetelt dobhat, vagy ilyesmi, es nincs mit visszaadni, akkor a fuggvenyed visszateresi erteke legyen egy Option ertek, amit viszont nem tudsz Integerkent hasznalni, csak ugy, ha mindenkepp ellenorzod, hogy van-e erteke vagy sem.
Option ret = enFuggvenyem();
switch ret {
case None: print "Nincs visszateresi ertek"
case Integer(i): print "Az Integer ertek: " + i.toString()
}Sokfele megoldas van, a lenyege az, hogy nem kerulhetsz olyan szituacioba, ahol elfelejted ellenorizni, hogy valami null-e vagy sem, mert a compiler garantalja, hogy vagy tuti van ervenyes ertek, vagy leellenorizted.
Ahogy Hoare is mondja (akit gondolom nem kell bemutatni):
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement.A lenyeg, hogy a nullreferencia nem egy szukseges rossz, hanem igazabol tok felesleges, amit a korai nyelvekbe raktak bele, hogy kicsit egyszerubb legyen megirni a compilert, es itt ragadt velunk. Csomo nyelvben (akar JVM alapu nyelvekben is) megoldottak, hogy ne legyen.
-
#6509
emvy
félisten
Aethelstone
#6508
válasz
Aethelstone
#6508
üzenetére
Mindenkinek az a normalis, amit megszokott. Gondolom a topicban senki nem haborodik fel azon, hogy a Java-ban van null erteku referencia, pedig talan a legrosszabb design hiba az egesz C/Java/C#/etc. nyelvi hagyomanyban, minden nap milliok futnak bele, pedig tipusos nyelvben siman el lehetett volna kerulni a letezeset (es akkor egyszeruen nem lenne NullReferenceException...).
-
#6508
Aethelstone
addikt
beleszólok
#6502
Aethelstone
addikt
válasz
beleszólok
#6502
üzenetére
Rossz a példa. A goto az ördög találmánya olyan nyelvekben, amelyekben lehet mellőzni a használatát. Ahol viszont nem lehet, ott jó. Ennyi.
-
#6507
floatr
veterán
beleszólok
#6505
floatr
veterán
válasz
beleszólok
#6505
üzenetére
Nem javasolta, mert felülcsaphatná a start metódust, te meg nem javasoltad mert felülcsaphatná a start metódust. Most hogy mondod, télleg lehet h van gyakorlati jelentősége...
-
#6506
Aethelstone
addikt
beleszólok
#6505
Aethelstone
addikt
válasz
beleszólok
#6505
üzenetére
Csak ismételni tudom magam. Nomen est omen...ha érted, hogy mire gondolok.
Arra próbáltam utalni, mégha nem is fejtettem ki az ominózus hozzászólásban, hogy alapvetően nem kérdés, de egyesek képesek vallási kérdést csinálni belőle, pont úgy, mint a politikából vagy a fociból. (Pedig csak az Arsenal
)Kb. 2 hozzászólással utána kifejtettem pontosan, hogy mire gondolok, de Te azt ignoráltad és azóta is ezen lovagolsz. Részemről zártam.
-
#6505
beleszólok
senior tag
floatr
#6504
beleszólok
senior tag
Nagy különbség:
- kötekedés: lásd fenn, semmi gyakorlati jelentősége.
- nem kötekedés: amellett, hogy egyetértettem vele, volt egy apró nézetkülönbség. Nevezetesen az, hogy szerinte vallási kérdés, hogy extends Thread vagy implements Runnable, szerintem meg amíg tartjuk magunkat az elvekhez, addig csak az utóbbi jöhet szóba. Ez szerintem nem kötekedés, csak kiegészítés. Hogy hosszabban is írtam, az meg azért volt, hogy talán sikerül az eredeti kérdezőt meggyőzni, hogy bármilyen apró, jelentéktelen feladatról legyen is szó, nem szabad az ilyen dolgokat félvállról venni, mert évek múlva lesznek csúf következményei... -
#6504
floatr
veterán
beleszólok
#6503
floatr
veterán
válasz
beleszólok
#6503
üzenetére
Ha olyan feladatod lenne, ami miatt a Thread-be kellene piszkálni, akkor nem java-ban kell implementálni. Nem is értem h miért nem final az osztály. Illetve értem ("that would break backward compatibility"), mert a legelső könyvek tele voltak Thread subclass-okkal.
A vitával kapcsolatban meg azért mondom h kötekedés, mert ugyanarról beszélt, mint te
-
#6503
beleszólok
senior tag
floatr
#6500
beleszólok
senior tag
Na, hogy kötekedjek is: de, lehet jó alap, csak megfelelő feladatot kell hozzá találni.
A fenti feladvány nem ilyen, de ha valamiért a Thread-be kellene belepiszkálni? - nem tudnék életszerű példát rá, de sokszor ért már meglepetés.(szóval ez kötekedés - csak hogy lásd a különbséget)
-
#6502
beleszólok
senior tag
Aethelstone
#6499
beleszólok
senior tag
válasz
Aethelstone
#6499
üzenetére
Na ja... anno még tanultuk a goto használatát. (COBOL, PL/I, BASIC)
Később azt mondták rá, hogy az ördögtől való. Minap olvastam valahol egy kis írást, amiben azt fejtegették, hogy mégsem, sőt...
Mondjuk a Te kódodnál két helyen is ott virít a warning, hogy itt baj lesz.
Ha csak dependency injection kell...akkor heavyweight!!!!!
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Gurulunk, WAZE?!
- Kertészet, mezőgazdaság topik
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- The First Berserker: Khazan
- sziku69: Fűzzük össze a szavakat :)
- Kerékpárosok, bringások ide!
- Diablo 3
- Nintendo Switch 2
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- MSI RTX 4070 SUPER 12GB GAMING X SLIM WHITE - 20 hónap garancia
- GIGABYTE RTX 4070 SUPER WINDFORCE OC 12GB - 20 hónap garancia
- iKing.Hu - Samsung S25 Ultra - Titanium Black - Használt, karcmentes
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
- Ikea Eilif Paraván - Asztali elválasztó
- Bomba ár! Fujitsu LifeBook U758 - i5-8GEN I 8GB I 256GB SSD I HDMI I 15,6" FHD I W11 I Garancia!
- QNAP TS-870U-RP 8 lemezes Rack NAS
- Bomba ár! HP ProBook 430 G8 - i5-1135G7 I 16GB I 256GB SSD I HDMI I 13,3" FHD I Cam I W11 I Gari!
- AKCIÓ! MSI B450 R5 5500 16GB DDR4 512GB SSD RTX 2070 8GB GDDR6 Rampage Shiva Zalman 500W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged