Non mi pare una proposta molto utile. In cosa sarebbe diversa una ImmutableList dalla attuale List? In tutti i casi mi pare che JetBrains non abbia mai preso in considerazione una KEEP che non fosse originata da loro, anche se ascoltano i commenti alle loro KEEP.
Uberto Uberto On Sat, 16 May 2020 at 20:26, Francesco Vasco [email protected] [it-torino-java-jug] <[email protected]> wrote: > > > Ciao Uberto, > permettimi una precisazione. > In Kotlin List è una generica lista a cui è possibile accedere, non è una > lista immutabile. > > > Per cui qualsiasi lista mutabile e' anche una lista immutabile > > Per cui qualsiasi lista mutabile e' anche una lista. > > Le collezioni immutabili sono state proposte > https://github.com/Kotlin/kotlinx.collections.immutable/blob/master/proposal.md > se sei interessato c'è una implementazione di riferimento > https://github.com/Kotlin/kotlinx.collections.immutable/ > > Comunque puoi sempre considerare di utilizzare i metodi di Java "List.of" > o "Collections.unmodifiableListOf" e fare il cast a List. > > Ciao, > Vasco > > Il sabato 16 maggio 2020, 17:11:12 CEST, Uberto Barbini > [email protected] [it-torino-java-jug] < > [email protected]> ha scritto: > > > > > Parlando di compromessi, in Kotlin una List (immutabile) e' la superclass > di MutableList. Per cui qualsiasi lista mutabile e' anche una lista > immutabile... > > Quindi tu ricevi una lista immutabile, ma magari in un altro thread > qualcuno sta mutando quella stessa lista... oppure tu la ricevi immutabile, > ma fai un check se implementa MutableList (99% si) e quindi puoi cambiare > tutto. > > Capisco i motivi (performance nel typecast?), ma personalmente non sono > convintissimo sia stata una buona scelta. > > Iterator poi potevano anche fare a meno di esporlo del tutto, imho. > > Uberto > > On Sat, 16 May 2020 at 12:20, Simone Bordet [email protected] > [it-torino-java-jug] <[email protected]> wrote: > > > > Ciao, > > On Sat, May 16, 2020 at 11:54 AM Francesco Vasco [email protected] > [it-torino-java-jug] <[email protected]> wrote: > > Durante l'ultimo interessante incontro di Simone, si è affrontato il > tema delle interfacce delle collection con metodi opzionali (qualsiasi cosa > questo voglia dire in OO). > > Opzionali nel senso che ci sono, ma poi vengono implementati con > "throw new UnsupportedOperationException()". > > > Il punto che vorrei approfondire è che questa scelta avrebbe > semplificato, altrimenti ci sarebbero state 500 classi (vado a memoria). > > Sono curiosi di questa affermazione, poiché mi sembra una esagerazione, > Scala ha una sua implementazione con questa differenziazione, Kotlin > differenzia le interfacce e condivide l'implementazione con Java. > > Avevo premesso che stavo dicendo numeri a caso (ho menzionato il > passaggio da 50 a 500 per enfatizzare il discorso). > > I numeri più precisi e la discussione sul design si trovano qui: > > https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html > > Il discorso era che è molto difficile fare un design perfetto per > qualcosa usato in modo molto generico e quindi con un sacco di use > cases. > Si devono accettare dei compromessi. > Nelle Java collections hanno accettato i metodi che lanciano > UnsupportedOperationException che se guardate su qualsiasi libro di > teoria OO vengono descritti come un abominio. > E lo hanno fatto per ridurre al minimo il numero di interfacce da > "spiegare" ad uno sviluppatore. > > "When all was said and done, we felt that it was a sound engineering > compromise to sidestep the whole issue by providing a very small set > of core interfaces that can throw a runtime exception." > > Ora, non è che mi trovi molto d'accordo. > Penso che la soluzione di Kotlin sia un compromesso migliore anche se > non è perfetto neanche quello. > > Per fare un esempio, sia Java che Kotlin hanno List.listIterator(int) > che è ovviamente inutilizzabile in ambiente concorrente (l'indice che > viene passato come argomento può non essere più valido quando viene > chiamato listIterator(int)). > Quindi, abbiamo una astrazione abbastanza generica come List che non > può essere usata per implementare una List concorrente. > L'implementazione può "provare" e sperare che l'indice sia buono - ma > rischio di avere non l'elemento che voglio oppure lancio > ArrayIndexOutOfBoundsException, oppure lascio stare e lancio > UnsupportedOperationException. > E allora, vogliamo aggiungere anche le interfacce "NonConcurrent"? > > Il discorso che facevamo era proprio sui compromessi. > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > > >
