Mélyen tisztelt Java devek...

...ti hogy bírjátok a Java csodás dátumkezelését? Vannak ilyenek, hogy: 

java.util.Calendar
java.util.Date
java.sql.Date
java.sql.Timestamp

És az új standard: 

java.util.LocalDateTime

Továbbá ez milyen agyfasz már, hogy a java.util.Date-nak van mindenféle kombinációban konstruktora, de a java.sql.Date-nak csak év-hónap megadására, többit settereken?

Szerk: Ok, ez csak az SQL-es DATE-nek felel meg, en az SQL-es TIMESTAMP-nak.

Ez külön kedvencem:

A year y is represented by the integer y - 1900.
A month is represented by an integer from 0 to 11; 0 is January, 1 is February, and so forth; thus 11 is December.
A date (day of month) is represented by an integer from 1 to 31 in the usual manner.

Mi ez az agyfasz, hogy a hónapokat 0-tól, a napokat 1-től indexeljük?

( gelei v | 2014. 08. 12., k – 21:32 )

> Mi ez az agyfasz, hogy a hónapokat 0-tól, a napokat 1-től indexeljük?
> Mi ez az agyfasz, hogy bármelyiket nullától indexeljük?

fix'd

De tényleg, kíváncsi lennék, hogy melyik baromarcúnak juthat eszébe olyan, hogy bármilyen számmal egyértelműen leírható tulajdonságot (idő, darabszámok, stb.) elkezdjen tologatni bármelyik irányba.

Igen, mert azt benéztem, mivel az nem az egész dátum+időt menti, hanem csak a dátumot. (Ld. fenn). Viszont nem az egész osztály deprecated (szép is lenne, mit adnál át JDBC-nek?)

Ugyanez az igaz a Timestamp osztályra.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

És mégis mi a jó Istenért jó az, hogy pl. a Timestamp osztálynál csak egy long-ot fogad el, és ha nem karom kézzel feltalálni újra a dátumszámítást, akkor egy másik, nem deprecated osztállyal számítom ki?

És egyáltalán, mi a jó istenért jó az, hogy a JDBC tök külön osztályokat használ ahelyett, hogy lett volna egy DateTime osztály (mint pl. a .NET-ben), amit megírnak normálisan és azt használ minden?

És az meg miért jó, hogy leírod a nyílvánvalót, ami ugyanazt, amit a Java Docs-ban is el tudtam olvasni? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezt konkrétan majd megválaszolja valamelyik javas(asszony :D), én úgy tizenöt éve nem láttam java forrást. :)

Viszont arra még emlékszem, hogy I/O műveletek kapcsán anno hasonló kérdések merültek fel bennem (file, stream stb.), amit csak mostanában kezdek megérteni... talán...
A Dependency inversion principle-re gondolok. Mintha ahhoz lenne valami köze. Feltételezem, itt is valami hasonló elképzelés vezette a kiagyalókat.
Vagy nem. Csak találgatok.

( BaT | 2014. 08. 12., k – 22:33 )

Sehogy, mind szar. Próbáld csak ki, tetszőleges javas dátumkezelési kérdés stackoverflow-n tuti kap olyan választ, hogy hogyan csináld Joda-Time-mal, és mindig ezerszer értelmesebb mint ami alapból van. De még az apache commons DateUtils is jobb.

Szerk: a java8-as date apit még nem ismerem, csak reménykedem benne hogy végre sikerült összehozni valami értelmeset.

( hrgy84 | 2014. 08. 13., sze – 03:21 )

A legviccesebb tulajdonkeppen az, hogy a java.util.Date, amit normalisan lehetne parameterezni es hasznalni, na az deprecated, es helyette nincs semmi, csak a java.util.Calendar, amit meg parameterezni is agyfasz. Ehhez egyaltalan nem kell akarnod SQL-ezni, siman csak egy ora appletet irni.

Azt csodalom, hogy a parameter nelkuli Date konstruktor meg nem deprecated, mert tulajdonkeppen harom-ot sorbol behelyettesitheto. Idiotak.

Egyebkent meg a lenezett Rubyban es Pythonban is kepesek voltak osszetakolni egy core Date/DateTime parost, es minden rohadt gem, minden nyuves kis library azt hasznalja, es nem harom kulonbozo osztaly negy leszarmazottjat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( NevemTeve | 2014. 08. 13., sze – 12:53 )

> Mi ez az agyf@sz, hogy a hónapokat 0-tól, a napokat 1-től indexeljük?

Az éveket meg 1900-tól. Speciel ezt a döntést akkor hozták, amikor a Java feltalálóit még pelenkázták, lásd gmtime(3), localtime(3).

( zZsOlTi v | 2014. 08. 13., sze – 12:59 )

"Mi ez az agyfasz, hogy a hónapokat 0-tól, a napokat 1-től indexeljük?"

Talán anno a standard C mintájára csinálták így. 


int    tm_sec   Seconds [0,60]. 
int    tm_min   Minutes [0,59]. 
int    tm_hour  Hour [0,23]. 
int    tm_mday  Day of month [1,31]. 
int    tm_mon   Month of year [0,11]. 
int    tm_year  Years since 1900. 
int    tm_wday  Day of week [0,6] (Sunday =0). 
int    tm_yday  Day of year [0,365]. 
int    tm_isdst Daylight Savings flag.

Ebben igazatok van (legalább tudom végre, miért volt ismerős a 0. hónap), de akkor is nagy marha volt, aki ezt így kitalálta.
Ha a hónapok nullával indulnak, akkor a napok miért eggyel? És viszont...
Még az sem indok, hogy a bitekkel akartak spórolni, mert a 12 és a 11 is csak négy biten írható le.

Kernel környékén én el tudom hinni, hogy számít ez (valószínűleg sokat kell buherálni azt a struktot, vagy legalábbis bőven van olyan usecase, ahol sokat kellhet). Magasabb szinten viszont tényleg agyfasz. Jó, megengedem, ott is lehet, hogy számít, akkor származtasson egy olyan osztályt, amiben nincs fölösleges matek a human olvashatóság miatt (vagy fordítva, tökmindegy), aztán aki másodpercenként kiscsillió ilyet akar átcsavarni, az használja azt...

Ahhoz képest most dobták ki a régi osztályokat, mert mindenki leszarozta, szétnézel Stackoverflowon, mindenki azt mondja, hogy irány az 1.8-as osztály és/vagy valami 3rd party libet javasol rá. És Java-ban, ahogy látom, mindenre ez van. Egyesek próbálják megideologizálni, hogy a választás szabadsága, de a helyzet az, hogy azért vannak ezek a libek, mert a Java fejlesztői igenis retardáltak voltak egy csomó mindennel kapcsolatban és láthatóan sokaknak ez nem jött be.

Ahhoz nem kell szart ennem, hogy rájöjjek, hogy nem jó.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az akkori tudást és befektetett energiát nézed le. Arra próbáltam felhívni a figyelmed, hogy egy nagy nulla vagy hozzájuk képest, de ennek nem vagy tudatában. Igazából csak szégyellheted magad.

A stackoverflow-n, a dokumentációkban, szinte az össze nagy java-s blogon megemlítették az elmúlt két évben, hogy ez lesz az új irány. De ott intelligensen tették, elmagyarázva, mi a gond a régi iránnyal; a gond a stílusoddal, a fölösleges túlzásoddal, és ezek alapján az intelligenciaszinteddel van.

Az nem tudás, hogy nekiállnak tervezni egy magas szintű nyelvet, *alkalmazásfejlesztésre*, majd gondolkodás nélkül átveszik a szart.

Az egész sokkal kevésbé zavarna, ha a másik oldalon nem azt tapasztalnám, hogy ezt próbálják letolni a torkomon, mint a világ legjobb nyelve/környezete ilyen blődségekkel, mint "de sok közül választhatsz!".

Ha nem csak szerintem lenne ennyi szar, akkor nem lennének ilyen projektek, mint az Apache Commons, vagy akár mondhatnám a C++ Boostot is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

https://www.youtube.com/watch?v=Ee_QsWJ8lrs

> egy nagy nulla vagy hozzájuk képest

Az ilyen kijelentések mindig elkeserítenek, mert sosem veszik figyelembe, hogy itt egy embert hasonlítasz össze egy teammel. Látatlanul azért nem merném, kijelenteni, hogy saxus hülyébb, mint egy véletlenszerűen kiválasztott egyén a Java teamből.

...mi a helyzet atomjanival? :)

Amúgy pont a tapasztalat mindatja velem, hogy Javanal néhol nagyon nem tudták eldönteni, hogy mégis mit akartak. Értem én. Hogy pont az alapokat nehéz letenni, de ha fos, ne nevezzük már jónak, csak mert egyesek megcsinálták.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Értelmes döntés született annó, [...] Te pedig a tervezőket leretaldáltozod.

Az "értelmes" elég szubjektív, de attól még, hogy valami több éven át működik, még nem feltétlenül lesz logikus vagy értelmes.

Például nézzük a .NET-et: adott a DateTime osztály, ami gyakorlatilag mindent tud, ami kellhet. Nem kell külső lib, nem kell a legújabb verziójú környzetet erőltetni, stb. Csak működik.

Mondjuk a Java védelmében egy mondat: nekik azért rendelkezésre állt az a tapasztalat, ami a Java tervezőinek anno nem volt.

Meg azértaz elején ott is rontottak el dolgokat, Ld. System.IO névtér, amiről a CLR via C# is megemlékezik.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( styg v | 2014. 08. 13., sze – 20:59 )

Azt javaslom, hogy számok helyett használd a Calendar konstansait, pl: java.util.Calendar.JANUARY. Akkor egyáltalán nem kell foglalkoznod azzal, hogy 0 vagy 1, vagy mennyi.

( BaT | 2014. 08. 13., sze – 22:30 )

Most jut eszembe, múltkor foglalkoztam olyannal, hogy szükségem volt a hét napjainak neveire egy adott Locale-nek megfelelően, és annak megfelelő sorrendben. A hét napjainak neveit egy DateFormatSymbols objektumtól lehet lekérni, ami visszaad egy String tömböt. Egész pontosan egy 8 elemű tömböt, aminek az első eleme egy üres String. Ez azért van, mert ezt a tömböt a Calendar megfelelő konstansaival lehet indexelni, amiben vasárnaptól szombatig vannak a konstansok, 1-től 8-ig. A Calendartól lehet megtudni, mi a hét első napja, ez szintén a Calendar megfelelő konstansát adja vissza. Tehát a kívánt collection előállításához nem lehet egy egyszerű ciklust használni basic matekkal, mert akkor épít a kód arra, hogy milyen struktúrájú a visszakapott tömb és milyen értékei vannak a konstansoknak. Ehelyett azt csináltam, hogy egy Calendar objektumot beállítottam a hét első napjára, azt léptettem naponként egy ciklusban, és attól kértem vissza a hét napját, amivel indexeltem a tömböt.

Mostanában hegesztgettem egy powershell scriptet, abban az eventlogból lekért események létrehozási idejeikkel matekozok, ég és föld a különbség. Ott a _legnagyobb_ bajom az volt, hogy ha egy formátumstringben TimeStampet akarsz kiíratni, nincs olyan beépített formátum ami nem írja ki a töredékmásodperceket ha az nem 0...

( kmARC v | 2014. 11. 04., k – 12:44 )

Ha már feléledt a topik, hozzá is tennék, bár az egész stílus méltatlan ami itt folyt.

A tájékozott szoftverfejlesztő nem agyatlanul anyázik, hanem megtanulta, és megértette, miért jó a hónapokat 0-tól számozni, míg a napokat 1-től. A matematikus pedig szép kategóriaelméleti indoklást is ad. Ennek hiányában én egy egyszerűsített magyarázattal szolgálok.

- A nap egy numerikus adat. Vagy 28,29,30,31 lehet belőle egy hónapban[1]. Mint numerikus adat, ezen belül is egész szám, a gép erre kitalált adattípusát használjuk. Mivel 28..31 között változhat, ezért logikus is, hogy egy tetszőleges egész típussal ivatkozzunk rá. 1-től kezdeni ezt a számozást pedig intuitív.
- A hónap ezzel szemben nemcsak numerikus adat, de ennél specifikusabb: egy lista (enumeráció, tömb, stb.) egy tagja. Mindig[1] tizenkettő van belőle. Ezáltal a gép szintén ilyesmire kitalált konvencióját használjuk, az eltolást, offsetet (persicsb már említette sokat sejtetően, de nem vagyok benne biztos, hogy mindenkinek tiszta volt ebből). Január ezek szerint 0 eltolással számolható, december pedig 11-gyel.

A legjobb módszer arra, ha valami ismeretlennel találkozunk az, hogy megnézzük, mi az, miért van úgy, miért nem máshogy van, mi volt a mögöttes gondolat, stb. Így csak okosabban jöhetünk ki a játékból. A buta fikázás ezzel szemben csak frusztrációt fog okozni, amikor magunknak is beismerjük hogy mi voltunk a hülyék. Jobb tehát elkerülni :-)

[1] Nagyon ritkán (többszázévente, a Gergely-naptár óta nem is tudom volt-e) előfordul, hogy még többet kell korrigálni, de erre most inkább ne készüljünk fel.

" A hónap ezzel szemben nemcsak numerikus adat, de ennél specifikusabb: egy lista (enumeráció, tömb, stb.) egy tagja."
Pontosan. A hónapok egy felsorolás elemei, az, hogy melyik az első hónap az évben, az megállapodás kérdése. Eléggé régen márciusban kezdődött az év, ezért OKTóber a nyolcadik, NOVember a kilencedik és DECember a tizedik hónap volt.
Felsorolásokat pedig konvenció szerint 0-tól indexelünk.

Hjajj, és vajon még mennyi fasságot taultam középiskolában, ami megragadt bennem, de egyszerűen: nem igaz...? Mondjuk pont ettől nem dől össe a világ, de akkor is. :-(

Szóval én úgy tanultam, hogy erdetileg rövidebb évvel számoltak (amit a wiki alá is támaszt, tehát végülis annyira nem tévedett), de a július, augusztus toldás volt, a linkek alapján viszont így van, átnevezés.

De ennyi erővel a napok sem numerikus érték, mert a hónap második napja nem kétszer akkora az elsőnél. Attól, hogy nincs neve, ugyanúgy rá lehetne erőltetni azt a logikát, hogy a hónap első napja nullás offset.

De nem tesszük, mert homályos ideológiai csapongásokon kívül semmi nem indokolja. :)

(Arról nem is szólva, hogy az enumok sem feltétlenül nullától kezdődnek, sőt, olyan szabály sincs, hogy a számoknak feltétlenül egymást követőeknek kell lennie.)

Jó, megértettük, teljesen jogos hogy agyfasz van meg mindenki figyelmét elkerüli hogy te mit akarsz, mivel egyértelműen az a jó, és különben is megérdemeljük hogy ilyen hülyék legyünk hogy fel se fogjuk hogy mire van szükséged és ha nem úgy van akkor márpedig nem olvasol utána, stb. stb.

Nézd, hiába mondod, a Java - elvileg - egy magas szintű, általános célű programozási nyelv kifejezetten felhasználói programok fejlesztésére. A felhasználók meg azt várják el, hogy a január az 1, a december az 12. Ehhez képest, ami szembe jön az API-n az egy kőkorszaki C-s struktúra Java osztály reprezentációja.

Te hoztad fel az enumokat példának, ezzel szemben köszönőviszonyban sincs az API az Enumokkal. Jöhetnék megint a .NET DateTime structjának DayOfWeek propertyjével, ami pontosan az általad leírt módon működik és enumot ad vissza, de azt hiszem, ameddig kritika nélkül elfogadod, hogy amit a Java csinál az tökéletes és nem is lehet jobban csinálni, addig nem nagyon tudunk vitázni. (Bár a tökéletességnek ellentmond, hogy az alap class libraryban is többféle verzió van már alapvető dolgokra, adatszerkezetekre és akkor még nem beszéltünk ilyenekről, mint Apache Commons...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

En sem, ha valaki 2014-ben egy regota deprecated API-t hasznal. Az o problemaja, csak ne vetitse ugy ki, hogy "mindenszar, ami nem olyan, mint a C#". Ez mergezi a szakmat. Ahelyett, hogy megnezni, mi a kurrens megoldas, es miert az, anyaz, tanulas helyett.
Lehetne sok mindent mondani a C#-rol is (most eppen melyik a hasznalando UI API? WinForm, WPF vagy eppen valami mas? Entity Framework vagy ADO.NET? Ott is megvan az agyfasz, csak arrol sosem hallunk.

A kurrens megoldás egyébként nem rossz. Leszámítva, hogy az összes többi API a régi vagy saját megoldást használja (ld. java.sql.Timestamp). És nem arról van szó, hogy minden szar, ami nem olyan, mint a C#/.NET (mert ott is vannak, amit kb. verzióról verzióra átvariálnak, ld. Task Parallel Library), hanem arról, hogy vannak dolgok a Java-ban, amik alapvetően vannak elkúrva és több megoldás (ld. Apache Commons) születetett annak javítására. De ugyanezt elmondhatnám a C++-ról is (ld. Boost), és ennek ellenére mindig akad valaki, aki kardoskodik, hogy de ez akkor is így van jól, mikor valójában az egyetlen indok az, hogy így vették át valahonnan máshonnan és/vagy "csak". Holott szvsz. az, hogy ilyen alapvető dolgokra több replacement is születik az csak és kizárólag annak a jele, hogy valami alapvetően el van rontva.

Ha meg már WinForms/WPF: szvsz. értelmes ember ma már nem kezd el projektet WinForms alatt, maximum, ha valami gyors tesztpad kell neki, amire kb. 3 gombot akar feldobni. Az EF meg tudtommal része/ráépül az ADO.NET-re, de az EF-et nem ismerem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Entity Framework vagy ADO.NET?

Kiegészítve saxus-t: az Entity Framework egy ADO.NET-re épülő ORM library. ORM-mel konkrétan tele van a Java ökoszisztéma is, a .NET-nél legalább van egy hivatalosan támogatott library, az Entity Framework, amitől csak akkor érdemes eltérni, ha valami olyan spéci dolgot akar az ember, amire most példát sem tudnék mondani. :)

Jó nyelv lenne az a C#, ha Windows-on kívül máshol is működne. Nem a nyelvvel van a baj, hanem azzal, hogy lassan megszűnik a platform amin futna.

A szervereken Linux megy, a mobiltelefonokon, tableteken Android, mindkettőn a java (vagy olyasmi) a nyerő, a házi PC szegmens meg szépen lassan nullára írja magát.

Érdemes a cikket elolvasni. 2004-ben íródott és a Microsoft bukását vetíti előre. Azóta 10 év eltelt és már .NET 1.1 nem fut sehol sem :)

Igazából azt lehet megnézni, hogy mi valósult meg és miben tévedett a cikk.
- Az internetes programok (webapp) sok helyen kiszorították a Windows API-t, de nem mindenhol. (Multimédia, letöltés, vásárlás, internet keresés, facebook,... mind web alkalmazás lett, de a szövegszerkesztés, játlék,... nem.)
- Egy szót sem ír akkor még az Androidról, ami a legkomolyabb fenyegetés jelenleg

Sokminden történt az elmúlt 10 év alatt, de a Linux desktop éve azért még nem jött el. Maradjunk annyiban, hogy a mai Linuxokon lényegesen többet meg lehet oldani, mint Windows alatt, de azért van még mit ledolgozni a hátrányból.

Ami számomra nem tiszta, hogy a Microsoftnak miért nincs még mindig Application Repository-ja, amikor az összes Linux, Mac, Android,... rendszernek van. Gondolom valami tröszt-ellenes törvény lehet mögötte.

> Maradjunk annyiban, hogy a mai Linuxokon lényegesen többet meg lehet oldani, mint Windows alatt

Miért, mit nem lehet megoldani Windows alatt, amit Linux alatt igen?

> Ami számomra nem tiszta, hogy a Microsoftnak miért nincs még mindig Application Repository-ja

Van neki, több is. (Windows Store, Xbox Store, Windows Phone Store, felkészül: OneGet) Épp azon dolgoznak, hogy összevonják őket egybe, és ugyanazok az alkalmazások futhassanak minden eszközön.

Maga az irány nem rossz, de még messze van az igazitól.
(a Windows10-zel nagyot lendítettek rajta, hogy minden irányba méretezhetőek lettek)

De úgy összességében még sem a kínálat, sem a funkcionalitás nem jutott el odáig, hogy a böngészőt/IDE-t/stb-t innen frissítsem... :-\
--
blogom

Jaj! Érdekelne, hogy a Windows 8 a grafikusait honnan szerezte. Gondolom karitatív munkát végeztek és pár csövest megkértek a híd alatt, hogy tervezzék meg a Windows 8 kinézetét.

Gondolkoztam, hogy az új notebook-hoz vegyek-e Windows-t, de amikor láttam, hogy csak Windows 8-at lehet kapni, akkor úgy döntöttem, hogy nincs az a pénz, amennyiért ilyet tennék a gépemre.

Szép kockák vannak benne: kék, zöld, narancssárga, meg lila. Talán Commodore 64-en még jól mutatott volna.

Fizetős, de egyrészt vanni indie csomag, ami hobbifejlesztéshez bőven jó, illetve van egy csomó (education, startup, stb.) kedvezményre lehetőség.

De a Xamarin nem csak Androidra fordít, hanem iOS-re, Androidra, Windows Phone-ra, és még ki tudja mire. Simán behozza az árát ahhoz képest, hogy mindenre külön fejlesztesz.

Miért nincs ilyen Java-s? Vagy valami Ruby-s, Pythonos?

Mindegyiket amit nézegettem, mindnek volt valami baja.

Flex alap téma csúnya, nincs kedvem theme-zni, pedig nem lenne rossz (AS3-at csípem). + Linuxra már nem oké desktop appnak
Qt-t néztem, nem lenne rossz, de brutál összetett és C++-t is felszedni hozzá (bár fél év egyetem volt), hááát... JS-hez meg nem nagyon van rendes tutorial
Ruby + Python keretek: általában csak mobilappra jók, desktopra nem.

Valami ötlet?

Ha tudsz C#-ban programozni, akkor hogyhogy nem ismered a java világot? Állásinterjún tapasztaltam, hogy időnként a vizsgáztató is összekeveri a kettőt, mert annyira hasonlítanak.

Már kaptam olyan kérdést, hogy tudom-e mit csinál a StringBuilder java-ban?

A C# talán kicsit modernebb, letisztultabb. Kb. újraírták a java-t, csak kihagyták belőle a történelmileg kialakult baromságokat, mint például Date. Könnyű jó nyelvet létrehozni, ha van miről másolni. A dolgot ott cseszték el, hogy nem lett hordozható nyelv. A java Windows, Linux, Mac, Android, FreeBsd,... mindegyikén elfut, kb. nulla módosítással.

Gondolom fogalmad sincs, hogy a java mekkora kalap szarként kezdte az 1.0-s időkben. Sokkal hosszabb utat tett meg, mint a C#, éppen ezért sokkal több a kódban maradt vakvágány. Szerencsére már elég sok deprecated osztályt kivágtak belőle a kukába, de még azért lehetne gyomlálni.

> Ha tudsz C#-ban programozni, akkor hogyhogy nem ismered a java világot?

what did I just read?

> A dolgot ott cseszték el, hogy nem lett hordozható nyelv.

Ezt már néhány különböző threadbe beírtam a napokban, a C# hordozható. A .NET library nem is, csak kevésbé. Amellett, hogy multiplatform játékokat (Unity) simán lehet vele csinálni, vagy mobilappokat fejleszteni minden nagyobb platformra (Xamarin), akár egy Arduino-jellegű boardon (Netduino) is tudsz futtatni C# kódot.

Definiálja már nekem valaki, hogy mit jelent a hordozhatóság.

Ha egy Windowsra megirt appot valtoztatas nelkul tudok Linuxon/OS X-en futtatni, akkor beszelhetunk hordozhatosagrol. Ez perpill legfeljebb a WinForms alapu appokra all meg C#-nal, es azoknal is kisse ingatag labon.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Valóban hordozható, csak az egy bajom, hogy értelmes applikációt nem lehet a hordozható résszel írni.

A Linuxra megírt programok kb. 0.001%-a mono-s, mert tényleg eszméletlenül hordozható a nyelv. De ha már olyan extra igényeid vannak, mint pl. UI, akkor inkább hagyd a fenébe az egészet.

Elkezdtem nézegetni a mono-t, de a megfelelő ingyenes dev környezet (monodevelop az vicc) és értelmes ui miatt dobtam az egészet.

Tudom, van a Gtk#, ami a szar Gtk-t degradációja, Windows Forms, ami a Commodore 64-es időket idézi a [20,34,45,61] window méretezéssel, ahelyett hogy automatikusan számolná ki a méreteket. Lehet mondani, hogy a WPF milyen tuti, csak rohadtul nem hordozható, ami meg hordozható szart sem ér.

"Ha tudsz C#-ban programozni, akkor hogyhogy nem ismered a java világot?"

Mert az, hogy egy programnyelvet ismerek messze nem függ össze azzal, hogy a hozzá tartozó frameworkoket, libeket, környezeteket is jól ismerem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hát, tudod már egy jópár éve feltalálták az API doksit. Ezt java alatt elég szépen összehozták.
Sőt, az MSDN library sem rossz.

Esetleg a Gtk-sokat, Gtk#-ot informálni lehetne erről a fantasztikus találmányról. Bevallom, a Gtk#-ból azért szerettem ki, mert már 3 napja a GTK forrását túrtam, hogy vajon mi a frászhalált csinál a függvény, ami úgy festett a neve alapján, hogy jó lehet nekem.

Azután beláttam, hogy a mono nem az a platform, amin fejleszteni akarok.

API doksival önmagában kitörölheted. Dokumentációba nekem beletartozik az is, hogy kapok egy áttekintést, hogy mi ez, hogy épül fel, hogyan kellene használni, mire jó egy lib/fw, mire nem jó, mik az általános buktatók. Az API doc önmagában egy nagy lóf...

Másrészt az, hogy ismerem a C#-ot, az egy dolog. Az, hogy ismerek még ráépülő dolgokat (WPF, WinForms, kis mértékben WCF, Windows Services, és különböző dolgokat a Frameworkből) az nem jelenti azt, hogy mindent ismerek Pl. ha most holnap nekem ASP.NET-ezni kellene, elején szenvednék vele, mert egyáltalán nem ismerem. Igen nagy valószínűség szerint meg tudnám csinálni, ha nekiállok utánaolvasni, hogy hogyan működik, de attól még nem ismerem. Hiába .NET mindkettő.

Ugyanez igaz a Java-ra: attól, hogy ismerem a Java nyelvet valamennyire, nem ismerem a Java-ban készült Frameworkok, libek API-jait. Kétlem, hogy ha valakinek pl. azt mondják, hogy holnap akkor írjon egy Eclipse plugint és korábban pl. képfeldolgozást csinált Java-ban, akkor ne küszködne eleinte az Eclipse saját ökoszisztémájával, ameddig meg nem ismeri, nem szerez benne tapasztalatot.

Vagy ugyanígy: lehet valaki jó PHP-s, ha neked Drupal/Symphony/Zend/stb. szakértő kell.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Vannak ilyen "ezer éves" konvenciók, hogy ma a Person három Children-je közül a másodikat 1-gyel jelöljük.

Tudom, hülyeség, de ebben nőttünk fel, s mind szeretjük, ha rajtunk kívülállók ezt nem akarják megerőszakolni, így a teljes JPA, a Collection framework, és nagyjából minden programnyelv* arra épül, hogy a "Person" entitás tömbként (listaként, setként) tárolt elemeit, illetve úgy általában minden felsorolás-jellegű típust 0-val indexelünk, és az ég adta világon semelyik szoftverfejlesztő ezt nem találja megerőszakolásnak.

Lehet, tényleg egy matematikust kéne bevonni a társalgásba, hogy végre páran megértsék, hogy attól, hogy valamit _ők_ """"""logikusnak"""""" gondolnak, attól még nem lesz igaz.

Vannak ilyen ezer eves konvenciok, hogy a januar az ev elso honapja, es nem a nulladik. Tudom, hulyeseg, de ebben nottunk fel, es mind szeretjuk, ha rajtunk kivulallok ezt nem akarjak megeroszakolni az informatika neveben.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A kedvenc programnyelvem speciel a vb.net es abban van egytol indulo indexeles, na most mit szolsz?

De most komolyan, tenyleg azert kezdodik nullaval a rohadt honapok szamozasa, mert egy tomb indexelesenel annyira nagyon bonyolult lepotyogni, hogy month-1?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ennek a vitának semmi értelme sincs, amikor kizárólag az idióták programoznak úgy, hogy


if( date.getMonth() == 1 ) /* do nothing */;

Értelmes ember ezt csinálja:


if( date.getMonth() == GregorianCalendar.FEBRUARY ) /* do nothing */;

Hogyha nem r=1 sugarú komplett idióta írja a programot, akkor nem ütközik bele ebbe az egetrengető problémába. Bevallom őszitén, életemben nem néztem még meg, hogy az intexelés 0-tól, 1-től, vagy 249-től kezdődik. Mindegy. Ha tömbbe rakom, kivonom belőle a GregorianCalendar.JANUARY-t.

Igen, igazad van abban, hogy nem az offszettel kell játszani, de valamikor nem tudod elkerülni. Például azt, hogy "5 hónap múlva milyen hónap lesz", nem tudod szépen a konstansokkall/enumokkal kiszámolni.

De miért jön be a fröcskölődés itt hogy így az idióták programoznak? Nem kell nagyon megerőltetni magad, hogy tudj olyan esetet mondani, amikor nem elég az enumod...

Esetleg valamit a kerdesre? Meg mindig nem latom, mi ertelme van 0-tol szamozni a honapokat, mikor ket egesz kivonasa minden esetben atomi muvelet, gyakorlatilag a processzornak erre kulon utasitasa van. Meg ha szorozni, vagy hatvanyozni kellene, akkor legalabb egy picit megertenem.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Nem értem. Tényleg nem. Megfogalmazom szépen, hogyan ne legyen az ember buta, olvasatlan. Erre csak jön a böffentés.

Az angol wikipedia oldal első mondatában, míg a magyar fordítás második mondatában tárgyalják, hogy "1 alapú" az évszámozás.

De az a legdurvább, hogy ha még 0-val is kezdődne, akkor sem lenne eggyel kevesebbel indexelve, mivel továbbbra sem felsorolás lenne, hanem egy mennyiség számozása, az évszám.

A fent említett elméleti matematikus már őrjöngene, de én csak azt kérdezem: Miért gondolja bárki is, hogy ennyire okosabb, mint a Java standardok, de még inkább: Unix standardok magalkotói...?

"Miért gondolja bárki is, hogy ennyire okosabb, mint a Java standardok, de még inkább: Unix standardok magalkotói...?"

Csak erre a kérdésre reagálva, kontextusból kiragadva: azért láttunk már karón varjút, "ez, akkor jó ötletnek tűnt", technológiai limitációkat, amik azóta is megkövülve kvázi-szabványok, stb. Szóval sosem baj az, ha valaki megkérdezi, hogy "ezt így mégis miért?".

Így van, igazad is van abban az esetben, amint tud rá jó, - ellentmondásra vezető - ellenpéldát mondani. Lásd URL osztály, ami - sokak számára érthetetlen módon - névfeloldást csinál. (Huhhh, ehhez citation needed).

Itt viszont pont, hogy kategória-elméleti kérdésről van szó (tehát megalapozott matematikai érveléssel eldönthető); a hónap, bármit is csinálunk, egy nevesített, felsorolás jellegű információ, aminek - természetéből adódóan - van egy sorszáma. És úgy látszik páran ezt a sorszámozást - a programozásban megszokott konvencióktól eltérően - hirtelen egytől akarja kezdeni.

És amíg megkérdőjelezné az illető, addig nincs is probléma. Itt viszont nagypofájú "agyfaszok", meg "ezeréves konvenciók" röpködnek.

Szerk.: Én ráadásul a "megkérdőjelezés" alatt általában nem egy rosszindulatú, a hibát kiemelő kérdésre gondolnék, hanem érvelésre azzal kapcsolatban, hogy ez miért nem optimális (esetleg teljesen rossz), és mi lenne a jó megoldás/konvenció. Namost ez itt - természetesen- teljes mértékben hiányzik.

"Huhhh, ehhez citation needed"

java.net.URL.equals(java.lang.Object) a kérdéses metódus, ami problémás.

Lásd: http://docs.oracle.com/javase/7/docs/api/java/net/URL.html#equals(java…

"Two URL objects are equal if they have the same protocol, reference equivalent hosts, have the same port number on the host, and the same file and fragment of the file.

Two hosts are considered equivalent if both host names can be resolved into the same IP addresses; else if either host name can't be resolved, the host names must be equal without regard to case; or both host names equal to null."

Ezért is ajánlott a java.net.URI használata.

Elsőre arra tippelnék, hogy mivel a különböző kultúrákban másik napon kezdődik a hét (vasárnap/hétfő az első nap), illetve néhány calendar szoftverben akár szerdára is állíthatod, ezért tisztán numerikusként tekinthető. De ez csak egy tipp.

Ha azt mondod most, hogy egy random kódban a day_of_week() visszatér 3-mal, nem tudnám biztosan megmondani, hogy ez most szerda vagy csütörtök, vagy esetleg kedd, ha 0-val indexelnénk mégis.

( Csab | 2014. 11. 05., sze – 12:49 )

Talán team building volt a Date osztály tervezésénél és mindenki hülyére itta magát. Nem kell mindjárt a legrosszabbra gondolni.

A CORBA API tervezésekor pedig éppen egy éves sörtúra volt?
Lásd: org.omg.DynamicAny._DynAnyFactoryStub
vagy:
org.omg.DynamicAny.DynAnyFactoryPackage.InconsistentTypeCodeHelper

De a legjobb a Spring Frameworkben lévő hírhedt:
org.springframework.aop.framework.AbstractSingletonProxyFactoryBean
http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/fra…

"Convenient proxy factory bean superclass for proxy factory beans that create only singletons."