Newsgroup: it.comp.java
Titolo: Scusate ma in ottica aziendale

chi stabilisce le librerie da usare.
oppure lo sviluppatore a capocchia sceglie quelle che piacciono di piu.
 
Esempio
 
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import org.apache.commons.lang.time.DateUtils;
 
ovvero 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
a capocchia o c'è una logica ?
 
 
 
 
-- 
Non mi fido di una cosa che sanguina per cinque giorni e non muore.
( Mr. Garrison )

 a capocchia o c'è una logica ?
 
quelle non sono 4 librerie, ma 4 classi!
 


e poi se anche fossero librerie non ha nessuna importanza,
quelle istruzioni sono semplici dichiarazioni per poter
utilizzare nomi corti invece di nomi lunghi.
 
 
 

 a capocchia o c'è una logica ?
 
Cazzate a parte che scrivi: il programmatore decide.
 
-- 
Al3xI98O
«L'importante non è cadere, ma sapersi rialzare»

 ovvero 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
ovvero 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
gia in 4 che si sono misurati su chi ce l'aveva piu lungo, e questo solo 
per trattare una data, figuriamoci per trattare cose piu serie.


 utilizzare nomi corti invece di nomi lunghi.
 
come ho gia detto piu volte i programmatori java non capiscono un cazzo, 
gli devi spiegare le cose 4 volte, gli mancano proprio le basi, 
altrimenti una rispostaa come la tua non sarebbe mai stata scritta


 a capocchia o c'è una logica ?
 
la logica c'e', ma e' un segreto e non te la diciamo.
Puoi scoprirla da te, leggendo la doc.
 
Ciao Jack

 altrimenti una rispostaa come la tua non sarebbe mai stata scritta
 
Certo, avere una gestione degli import così duttile e funzionale
è roba proprio da... :-D Non si sa dire XD Meglio il COBOL che ti permette
di... Ma in COBOL c'è una gestione ottimizzata degli import??? O_o
 
 
 
 
 

 per trattare una data, figuriamoci per trattare cose piu serie.
 
Una data *E'* una cosa seria, soprattutto in informatica.
 
 

 trattare una data, figuriamoci per trattare cose piu serie.
 
Giuro che prima o poi capirò quel che scrivi


 a capocchia o c'è una logica ?
Intanto le librerie utilizzate nel tuo esempio non sono 4 ma solo 2, di 
cui una (rt.jar) non la si puo' evitare perche' fa parte del runtime java.
La libreria commons-lang.jar e' abbastanza comune, utilizzarla o meno ha 
come unico scopo quello di non riscoprire ogni volta l'acqua calda. Tra 
l'altro essendo protetta dalla licenza Apache, non pone nemmeno limiti 
di utilizzo.
In definitiva, la tua domanda e' mal posta e fa trasparire l'ignoranza 
in materia di chi la pone, se mai ce ne fosse stato bisogno.
 
Mi rendo anche conto che essendo che in cobol le date, intese come tipo 
dati, non esistono, ti puo' essere sembrato strano. Ma in realta' 
trattare le date e' un'operazione complessa, proprio per i multiformi 
aspetti che una data puo' assumere. Ad esempio, trattare una data 
gregoriana e una data lunisolare (come nel calendario ebraico) 
riconducendole ad un unico orario definito nello spazio, nel tempo e 
nella storia con implicazioni culturali, in cobol potrebbe essere 
parecchio complesso (valuto non meno di 10000 righe di codice), in java 
c'e' appunto il tipo Calendar, che riduce i gradi di liberta' 
semplificando enormemente i conti limitando il codice a poche righe.
 

 semplificando enormemente i conti limitando il codice a poche righe.
 
ma ,lo vedi che sei un saccente di merda?
In informatica si usano solo 2 calendari, il gregoriano e il giuliano, 
quello ebraico al quale tu ti riferisci viene usato solo in ambito 
religioso o teologico. La formulazione di quel calendario non passerà 
mai tra i byte di un computer.
SEI PROPRIO UN SACCENTE DI MERDA.
DIO CI LIBERI DAI SACCENTI! CAZZO!


 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
comunque su questo concetto nessuno ha sviluppato una discussione, il 
che dimostra che non avete la piu pallida idea di cosa sia sviluppoare 
bene, rispettando logiche aziendali.
ma la cosa assunrda è che nemmeno vi fermate a riflerre che esistono 
librerie ridondanti e che probabilmente nessuna delle 4 ha uno sviluppo 
completo in grado di coprire tutte le casistiche in un trattamento date.


 mai tra i byte di un computer.
Hai detto la tua ennesima cazzata, da superficiale supponente quale sei.
Come se l'informatica trattasse solo di bolle e fatture.
Inoltre se parlo di "orario definito nello spazio, nel tempo e nella 
storia con implicazioni culturali" intendo che anche nei casi piu' 
semplici, anche utilizzando il calendario gregoriano, lo stesso orario, 
inteso come istante nel tempo, in due fusi orari distinti viene 
rappresentato con due date diverse, e con i tuoi PIC 9(7) COMP-3 col 
cazzo che indichi una data certa.
Ti posso garantire che chi tratta su mercati internazionali, includendo 
quello cinese, col cazzo che fa capire le date gregoriane ai cinesi.
 

Delta11 in data mercoledì, 16/12/2015 ha detto:
 
MA non te ne eri andato alle 14.06?


 a capocchia o c'è una logica ?
 
in ambito Java accade spesso di trovare classi da packages
diversi che fanno più o meno le stesse cose e ognuno può
scegliere se usarle e quali usare oppure se nessuna di queste
lo soddisfa, scriverne di proprie. Questione di mentalità!
 
Ma tu coglione non puoi capire... ho visto un programmatore COBOL
tenere segretissima una ridicola routine per stampare gli importi
in lettere... una discreta testa di cazzo! Forse eri proprio tu!
 
 
 


 
 
Sono 4 classi non librerie.
Le prime 3 sono di sistema ed i progettisti hanno preferito fare 3 
classi invece che una
Avranno avuto le loro ragioni.
La 4 è di apache fundation, qui chissà perchè avranno voluto farsi una loro.
Ma nel mondo open è cosi,quanti framework esistono per gestire 
particolari funzionalità,classi che non fanno parte della lib std?
Basti pensare ai framework per gestire GUI in C++ (ce ne sono a decine) 
o per l'accesso ai database.
 
 
 


Come al solito la tua superficialita' corredata da un quantitativo 
industriale d'ignoranza non ha pari. Ho il sospetto che l'unica 
accezione che conosci del verbo riflettere si quella riferita agli 
specchi (di fatto non sai neanche scriverlo bene, usi "riflerre").
Secondo te da 4 include (che non sono 4 librerie) si puo' capire quale 
sia l'ambito e se ci sia qualche ridondanza?
Poi spiegami qual e' la logica aziendale secondo la quale una data 
espressa in qualsiasi parte del mondo debba essere considerata allo 
stesso modo.
Mi viene il dubbio che tu non abbia mai comprato un biglietto aereo, 
dove le date di arrivo e di partenza sono espresse nell'orario locale 
dei relativi luoghi di arrivo e di partenza. E ti posso garantire che 
non c'e' compagnia aerea che non utilizzi un computer per fare i biglietti.
 

 mai tra i byte di un computer.
Tutto cio' che segue sono classi java, e come tali passano *solo* tra i 
byte di un computer (esen):
IslamicCalendar is a subclass of Calendar that that implements the 
Islamic *civil and religious* calendars.
ChineseCalendar is a concrete subclass of Calendar that implements a 
traditional Chinese calendar.
DangiCalendar is a concrete subclass of Calendar that implements a 
traditional Korean calendar.
HebrewCalendar is a subclass of Calendar that that implements the 
traditional Hebrew calendar.
CopticCalendar implements the Coptic calendar system.
IndianCalendar is a subclass of GregorianCalendar that numbers years 
since the birth of the Buddha.
etc.etc.


Centra nulla con Java, ma ho fatto un'App per l'iPhone (chiamata epiciclis) che mi da' le effemeridi di qualche oggetto celeste (pianeti, roba del catalogo Messier, stelle, ecc.), beh e' un gran casino, bisogna rapportare i vari calendari (i thailandesi ad esempio non usano il nostro calendario), i fusi orari, i vari tempi, date e posizioni a UTC per fare i calcoli e poi ri trasformare il tutto in ora locale.
Gran casino insomma, facile sbagliarsi.
Per fortuna la classe che si occupa del calendario in iOS (non cosi semplice da usare inizialmente) lavora con l'UTC, e trasforma automaticamente in data e ora locale quando visualizzi a schermo, facilitando molto il lavoro.
 
Poi oh, uno se la puo' cavare tranquillamente con solo il giorno giuliano, gestendo a manina, il salto fatto dal calendario gregoriano (che i cristiani ortodossi non usano), l'anno bisestile, il leap second, i fusi orari, l'ora legale, ecc.
Sono sicuro che in COBOL e' facilissimo...
 
Ciao Jack


AH AH AH AH AH AH NO NON ERO IO
quella routine è da pirla tenerla segreta è riportata su qualsiasi 
manuale di cobol AH AH AH AH
 
HAI RAGIONE SONO UN COGLIONE!



Il fatto e' che bisticciare con traduzioni, appropriate o meno, non 
giustifica comunque l'infondatezza della questione posta dall'op. Vorrei 
sottolineare che l'op stesso, ha utilizzato il termine "libreria" per 
identificare cio' che invece sono inequivocabilmente classi, utilizzando 
dunque un termine sicuramente improprio.
Vorrei anche far notare che il post originale era un cross post, tutti 
quelli che hanno risposto sull'altro ng, hanno inteso il termine 
libreria esattamente nella comune accezione italiana, quindi non tanto 
genericamente un jar, che e' un agglomerato arbitrario di file, ma un 
insieme di funzionalita' consistenti, come succede in altri linguaggi, 
ad esempio in C ma non solo.
Il fatto poi che gli autori di una libreria decidano di distribuire il 
loro prodotto in un jar, e' semplicemente una prassi comunemente 
adottata dal mondo degli sviluppatori java. Per questo, nello specifico 
esempio citato dall'op, ho citato i jar in cui le classi importate erano 
in origine, significando unicamente che quei jar in particolare 
includono di fatto una libreria.
Venendo alla tua citazione, vorrei far notare che non e' l'unica pagina 
web dove *non* viene utilizzato il termine library, ma ci sono altre 
pagine dove il termine jar viene utilizzato per identificare lo 
specifico contenitore di una library. Vedi ad esempio 
https://docs.oracle.com/javase/7/docs/technotes/guides/jpda/examples.html