American horizon ha scritto:
migliorabile ha scritto:
x American horizon: la libreria standard COMPRENDE le collezioni.
Con il solo compilatore, senza la libreria standard, puoi solo compilare, ma non eseguire alcunche', perche' ti mancherebbe l'intero framework di esecuzione (classloader, accesso al filesystem per la lettura della classe, input/output, ...).
Ne sono consaevole, ma resta il dubbio sul perchè c'è una distinzione tra array (statici) e vettori (dinamici). Non sarebbe stato meglio mettere a disposizione i vettori e bona, considerando che sono più flessibili degli array? E' chiaro che se ciò non è stato fatto una spegiazione deve pur esserci..
Provendendo da actionscript 3 sta cosa degli array statici mi suona prorpio limitante, e se tiriamo in ballo pure il package collection, le hashmap, i vettori, bhe mi viene semplicemente il mal di testa perchè non capisco il motivo di un tale calderone di metodi che alla fine potevano essere semplificati in uno (magari non nel caso delle hashmap, ma i vettori e gli array si dato che sono praticamente la stessa cosa)
Ciao,
in risposta (parziale) alla tua domanda, ricordo qui una risposta che già ho dato altrove sul forum; se un linguaggio di programmazione ti scatena forti dubbi e perplessità, allora quel linguaggio di programmazione NON è il linguaggio adatto a te.
Nello specifico, Java deriva in un certo modo da C++
Nel linguaggio C e C++ (versioni standard ovvio) non esiste neppure il concetto di un vettore ridimensionabile in automatico, perchè questa cosa è totalmente al di fuori della filosofia del linguaggio C (e quindi del C++)
Molti programmatori che leggono e scrivono qui sul forum sono giovani programmatori, e purtroppo non hanno avuto l'opportunità di vivere in prima persona le evoluzioni storiche dell'informatica moderna (diciamo dagli anni '70 in avanti). Avendo tu queste informazioni, ti renderesti conto immediatamente che la tua stessa domanda risulta comprensibile certo, ma totalmente priva di fondamento.
A parte il fatto che il linguaggio Java in futuro potrebbe anche essere modificato completamente, tutto è possibile, si deve partire nel ragionamento dalle caratteristiche interinseche del linguaggio C (e quindi del C++). Tale linguaggio trova la sua massima potenza nella gestione dei puntatori a oggetti in memoria, quindi gli ideatori del linguaggio hanno ben pensato che ogni struttura dimamica dovesse essere risolta via codice esplicito, nella forma di funzioni (oppure di classi).
Inoltre il linguaggio C è stato ideato con lo scopo di offrire un linguaggio di programmazione di livello quantomeno intermedio, ovvero che permettesse una compilazione in assembly la più efficace possibile, con lo scopo quindi di evitare al programmatore la stesura di codice assembly, sollevandolo da tale compito improbo attraverso il C (o C++) e lasciando la generazione dell'assembly al compilatore. In particolare il C++ ha una filosofia ibrida, nel senso che è stato creato come un linguaggio OO comunque compatibile con il C, e le estensioni OO offrono al programmatore una "marcia in più", caricando però maggiormente il compilatore (che in effetti a volte deve generare codice un poco arzigogolato, a causa delle caratteristiche della programmazione OO, aliena al linguaggio C originario)
Seguendo la medesima filosofia, ovvero della massima efficienza sul codice assembly (e quindi NON della massima comodità per il programmatore), si ha che ogni manipolazione di strutture dinamiche (vettori, code, alberi ecc.) deve essere ideata dalla mente del programmatore (o dai programmatori che hanno scritto le librerie di classi) perchè ogni struttura di dati dinamica necessità di suoi algoritmi specifici per essere manipolata, nel modo più efficiente possibile (non importa se poi risulti scomodo da usare, i "vecchi" programmatori erano ben abituati a soffrire... )
E' per quello che il concetto di "vettore con auto-resize" è del tutto alieno al linguaggio C e ai suoi derivati (una soluzione generica sarà sempre inefficiente ove applicata ad un caso specifico)
In un certo senso il linguaggio Java si accoda (e anche il C#), sostituisce i puntatori (pericolosi da gestire) con i riferimenti, ma la filosofia è quella, le strutture dinamiche le devi fare a codice, non sono automaticamente integrate nel linguaggio medesimo (nello specifico le trovi già pronte sotto forma di libreria, e non a caso non si tratta di un UNICO grande oggetto dimamico che soddisfa ogni possibile esigenza in modo inefficiente, bensì una miriade di classi specializzate che tentano di risolvere un determinato problema nel modo più efficiente possibile)
Questa è la filosofia di base; prendere o lasciare.