Newsgroup: it.lavoro.informatica
Titolo: Boolean.getBoolean(String)

Parsing di un booleano? No. Va a vedere se la system property specificata nel parametro e' "true".
 
Cosa si erano bevuti gli ingnegneri della Sun al tempo?


quello che vuoi tu è valueOf(String s)
 
ma sono d'accordo che lo potevano chiamare getBooleanProperty
 
-- 
Soprano


Non e' codice mio. 
 
Prova a immaginarti la situazione...ore perse per capire come mai una variabile del genere continua ad essere valorizzata a false. Non e' che Boolean.getBoolean salti proprio all'occhio :D
 
Tra l'altro la variabile era PAYPAL_SANDBOX (sempre a false), mica robette.


Come Integer.getInteger o Long.getLong. Non vedo cosa ci sia di strano, 
c'e' scritto nel javadoc.
Per il parse si usano i metodi parse* ma anche valueOf.


Mi sbilancio, forse il nome che non ci azzecca nulla e che e' fuorviante?


In genere dovrebbe saltare all'occhio che un metodo get, che dovrebbe 
servire a reperire il valore di una proprieta' d'istanza e che quindi 
non ha argomenti, ha invece un argomento ed e' statico come lo sono le 
system properties.

 specificata nel parametro e' "true".
 
vedo che ci sono per altri tipi, mai conosciuti e usati. in effetti 
decisamente controintuitivo; un po' come se alla domanda "quanti anni 
hai?" uno rispondesse con gli anni di esperienza lavorativa.
 
 


Sai com'e', le persone normali (ma quelle eccezionali come te sono evidentemente diverse) *NON* si aspettano che una classe Boolean esponga metodi per leggere dalla system property. Meno che meno da un metodo il cui nome non menziona la system property.
 
In OOP si dovrebbe seguire almeno il Single Responsability Principle. Qui viene palesemente violato.


Ora che ricordo non e' la prima volta che pesto questa merda. Evidentemente l'errore scappa. Non per niente esistono thread su Stackoverflow:
 
http://stackoverflow.com/questions/21410683/boolean-getbooleantrue-returns-false
 


Sara' anche controintuitivo, ma visto che in genere i metodi getter non 
hanno argomenti e non sono statici, io sospetto ed intuisco che debba 
leggere e capire quanto scritto nel javadoc.
Mentre "quanti anni hai?" e' una formula di rito, una locuzione 
idiomatica, per cui non e' ambigua, previa conoscenza della lingua.

 Sara' anche controintuitivo
 
Quindi sei d'accordo che il nome e' sbagliato.


 
 
qui si può confutare facilmente la prima parte della tua affermazione.
 
Ci sono anche dei metodi getter che prendono in input un argomento,
il quale funge da chiave per recuperare un valore.
 
Giusto tre esempi banali:
 
 -request.getAttribute("attr");
 -request.Parameter("attr") 
 -map.get(key)
 
 
a parte questo, condivido che il nome del metodo non è intuitivo
e può trarre in inganno; d'altra parte, bastano 2 secondi per
andare su google e trovare la documentazione:
 
 
https://docs.oracle.com/javase/7/docs/api/java/lang/Boolean.html#getBoolean(java.lang.String)
 
 
 
tanto per parlare di un problema che fa perdere un sacco di tempo
per poi scoprire che era una cagata, come spesso accade nell'informatica.


Non ne sarei cosi' sicuro, magari hai ragione tu.
Nello specifico, il package di Boolean e' java.lang, come anche di 
System, dove il suo intento e' "Provides classes that are fundamental to 
the design of the Java programming language.". Casi simili in java.lang, 
ma anche nei subpackage, ce ne sono anche altri, fatto sta che facendo 
parte del linguaggio la conoscenza e' data per assunta.
Per cui non mi aspetto che il principio di responsabilita' sia applicato 
in modo cosi' pedissequo come vorresti, che invece e' sacrosanto in 
oggetti di business.
D'altra parte converrai che a volte il confine della responsabilita' non 
sempre e' cosi' ben definito, nello specifico il metodo getBoolean deve 
fare il parse di una system property il cui valore dovrebbe essere o 
true o false, per cui di chi e' la responsabilita': di System o di Boolean?

 andare su google e trovare la documentazione:
Ecco forse e' proprio questa la chiave di tutto. Nell'IDE che uso io, 
basta portare il cursore del mouse sul metodo per ottenere il javadoc in 
un tooltip, senza scomodare google (che tra l'altro, di giorno in 
giorno, mi sta sempre piu' sul cazzo)

 true o false, per cui di chi e' la responsabilita': di System o di Boolean?
 
Per me e' ovvio: System.getBooleanProperty(key)


 
 
std::cin >> std::boolalpha >> b;
 
it's better
 
 
 
 
 
 


più che altro non c'entra una sega.

 Dubito che si possano dare per assunti tutti i metodi dentro java.lang.
Since: JDK1.0 significa che sono vent'anni che quel metodo fa il suo 
porco mestiere. E dopo vent'anni, se permetti, dei dubbi e rimbrotti di 
un chicazze' qualsiasi mi ci spazzo il culo.
 

 un chicazze' qualsiasi mi ci spazzo il culo.
 
ROTFL! Solo un imbecille che non ha le basi minime di programmazione puo' scrivere una stronzata simile. Un pezzo di codice puo' benissimo funzionare anche per 100000000 di anni e fare comunque schifo.
 
D'altronde non sono certo il solo ad ammettere che problemi ne esisono:
 
"But much of our frustration is not even with the Java language itself. The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project... "
 
Questo e' Gavin King. Ora spazzati il culo anche con lui e con Hibernate, CDI, EJB3, eccetera eccetera.

 leggere e capire quanto scritto nel javadoc.
 
beh per come la penso io dover andare a leggere la documentazione è 
esattamente quello che intendo per controintuitivo :-)


c'entra, e' un modo,e non ambiguo o strano,di leggere true/false e 
convertirlo in boolean.
Naturalmente C++
 


Non credo che si possa pensare di condensare tutto il comportamento  di 
un metodo nel suo nome, per cui ho sempre ritenuto il javadoc una 
risorsa fondamentale, l'unica alternativa e' quella di guardarsi i 
sorgenti, cosa che mi capita di frequente.
In ogni caso guardo con un certo sospetto il termine "intuitivo", non 
per partito preso ma per esperienza. Un esempio abbastanza 
esemplificativo e' proprio windows, di cui ricordo non senza 
divertimento l'annuncio di "finester 95, la version lumbarda" che 
recitava appunto "facilissim de dupera'". Per non dimenticare: 
https://www.youtube.com/watch?v=i58_d9WBz8Q
 
:-)

 Naturalmente C++
 
si da il caso che la discussione fosse proprio sul fatto che quel metodo 
non servisse a quello.
il metodo di parsing dei boolean in java non è ne ambiguo ne strano, al 
di là dei tuoi (molto presunti) syntactic sugar.


Ecco, questo e' un chiaro esempio di come un linguaggio ad oggetti, il 
C++, condensi il comportamento dei metodi nei loro nomi!
:-)


Lol, ti davi arie di conoscere Java e non hai mai visto Boolean.valueOf?


No e' un esempio di come l'overloading degli operatori venga spesso abusato. Servirebbe per cose come
 
Complex c1 = ...
Copmlex c2 = ...
c1 + c2
 
dove il nome (o meglio il simbolo utilizzato) sono super chiari e parlanti e invece spesso finisce in follie come queste
 
http://www.scala-graph.org/guides/core-initializing.html
 

 sorgenti, cosa che mi capita di frequente.
 
siamo d'accordo, ma delle api devono seguire un principio di coerenza: 
c'è una classe System che già accede alle proprietà di sistema, uno quei 
metodi si aspetta di trovarli lì e non sparpagliati un po' ovunque. che 
sia documentato mi pare il minimo, ci mancherebbe anche fossero non 
documentati... :-)

 it's better
 
LOL...
 

 Parsing di un booleano? No. Va a vedere se la system property specificata nel parametro e' "true".
 
Si`, e` un comportamento del cazzo, a cui hanno dato un nome del cazzo. Quella funzionalita`, semplicemente, non dovrebbe stare li`.

 leggere e capire quanto scritto nel javadoc.
 
PROPRIO perche` i metodi getter non hanno argomenti e non sono statici, e hanno uno scopo preciso, crearne uno con quel nome, con argomenti e statico, e con lo scopo che si prefigge quel metodo, e` un pasticcio.
 
"Io sospetto ed intuisco che debba leggere e capire quanto scritto nel javadoc" va palesemente contro il POLA: 
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
 


Del senno di poi sono piene le fosse.
Il javadoc e' del 1995, forse prima, il pola e' del 2001. Inoltre il 
pola tratta tratta di "users", e dubito che certe classi/metodi possano 
far parte della user interface.


 
 
 
Su questo hai ragione
 
 
 


public static Boolean valueOf(String s)
Returns a Boolean with a value represented by the specified string. The 
Boolean returned represents a true value if the string argument is not 
null and is equal, ignoring case, to the string "true".
 
 
 
E' quello che fa quello che ho scritto.
 
 
public static boolean getBoolean(String name)
Returns true if and only if the system property named by the argument 
exists and is equal to the string "true". (Beginning with version 1.0.2 
of the JavaTM platform, the test of this string is case insensitive.) A 
system property is accessible through getProperty, a method defined by 
the System class.
If there is no property with the specified name, or if the specified 
name is empty or null, then false is returned.
 
 
 
Questa e' la tua lamentela
 
Se speri che io conosca a memoria tutta la libreria java sei fuori 
strada,se mi serve qualcosa e non ricordo cerco,per di un linguaggio di 
cui mi frega poco.
I manuali sono li apposta
 

 conosca il C++ usa operator >> e operator << per gli stream.
 
A mio parere si. Ma e' opinabile. In ogni caso sono talmente noti ai programmatori C++ che non rappresentano un reale problema.


Neppure io la conosco a memoria, ma cose come Integer.valueOf() sono arcinote.

 Del senno di poi sono piene le fosse.
 
Non ci vuole un IQ come quello di Einstein per capire che "does exactly what it says on the tin" e` un principio che vale per qualunque oggetto di design, API incluse. Donald Norman, poi, il suo "The Design of Everyday Things" l'ha scritto sette anni prima della nascita di Java, e ti invito a leggerlo. Il POLA afferma esplicitamente "a programmer should try to think of the behavior that will least surprise someone who uses the program, rather than that behavior that is natural from knowing the inner workings of the program". E questo vale anche per chiunque usi le API che quel programmatore scrive.

 Se speri che io conosca a memoria tutta la libreria java[...]
 
Il problema e` che non sai neanche le basi. Ma parli uguale.


Tranquillo,anche da me
 

 Tranquillo,anche da me
 
Certo certo, lol.