Newsgroup: it.lavoro.informatica
Titolo: a proposito di pascal



http://e-collection.library.ethz.ch/eserv/eth:3059/eth-3059-01.pdf






Qui sopra un url al reference manual del pascal cosi come concepito da 

Wirth

A scanso di equivoci non è spiegato il turbo pascal di Borland,Delphi o 

qualsiasi altra implementazione se non quella pensata da Wirth e 

pubblicata nel 1973.



Puntatori:

il linguaggio prevedeva i puntatori (al contrario di come ricordavo)

Ha un operatore new per allocare memoria dinamica ed un operatore nil di 

assegnamento per inizializzare o deallocare (questa ultima è una ipotesi 

visto che non esiste un operatore free o delete o qualunque altro)

Si puo supporre che il linguaggio preveda una specie di GC per la 

deallocazione della memoria dinamica (il reference non lo spiega)







Moduli:

Un modulo un programma

Non esiste il concetto di inclusione di header

Infatti in altre implementazioni furono poi aggiunti questi costrutti.





Libreria:

Non esiste una libreria (qualcosa per dare funzionalità un po come la 

std library del C) , il linguaggio pensato è tutto li.





Non esiste il concetto di moduli esterni anche scritti in altri linguaggi





Insomma un linguaggio limitato (la carenza di moduli per un progetto un 

po complesso è molto limitante) per attività nel mondo reale ma in fondo 

era nato a scopi didattici.





















https://books.google.com.mx/books?id=PLs1_BwfL-oC&pg=PA194&lpg=PA194&dq=wirth+the+programming+language+pascal&source=bl&ots=UkxSH1lDOI&sig=tJGVU8jICqV_MyTw6gPRCmQzYH4&hl=it&sa=X&ved=0CFYQ6AEwCDgKahUKEwjJi8iQ4vLIAhXUV4gKHVziAMI#v=onepage&q=wirth%20the%20programming%20language%20pascal&f=false




Un altro book




 Insomma un linguaggio limitato 



Ma limitato sara` il tuo cervello, capra ignorante!


 Non esiste il concetto di inclusione di header



Una volta o l'altra mi devi spiegare perché gli header ti piacciono tanto.

IMHO de facto oggi sono un anacronismo; lo scopo era essere 

maledettamente veloci nella compilazione (so come è fatto un modulo, 

anche grande, caricando un file di dimensioni minuscole), ma con la 

velocità in grado di sviluppare qualunque PC da supermercato odierno non 

danno un gran plus (come ti dicevo, Python non li ha, Java non li ha, C# 

non li ha, Ruby non li ha...).



-- 

Ciao!

Luca




 il linguaggio prevedeva i puntatori (al contrario di come ricordavo)



ma quando mai. all'università insegna(va?)no il C dopo il pascal 

praticamente solo per insegnarti la gestione della memoria e i 

puntatori.



ciao

d.



-- 

"Anche quelli che sostengono che tutto è predeterminato guardano bene,

prima di attraversare la strada." -- Stephen Hawking




Non limitarti a leggere l'indice del manuale.


 puntatori.



I puntatori esistevano eccome fin dall'inizio quello che non ha mai avuto, IMHO per fortuna, era l'aritmetica del puntatori: potente, comoda ma fonte di una marea di errori tra i più subdoli e pericolosi.



Ciao

  Francesco


 ma quando mai.



Ma quando sempre. Mi sa che ti devi andare a rivedere il Pascal; ripeto 

il riferimento sul mio testo universitario: Peter Grogono, programmare 

in Pascal, 1983, Muzzio 1983, cap. 8.1, pag. 272.



Ciò che in Pascal manca, ed è la peculiarità di C, è l' _aritmetica_ dei 

puntatori. Ci si fanno cose molto simpatiche, ma è molto, molto, molto 

pericolosa.



-- 

Ciao!

Luca




Luca Menegotto <otluca...@DELETEyahoo.it> ha scritto:


Vero, ed è per questo che può essere non necessaria.








 ha scritto:


Quotabile.






Luca Menegotto <otluca...@DELETEyahoo.it> ha scritto:




..PHP non li ha ;-)








 pericolosa.



Sempre però limitandosi strettamente alle primissime versioni di Wirth. 






'stardo... :D



No, dai, l'aritmetica dei puntatori non c'era nemmeno nel TurboPascal.



-- 

Ciao!

Luca


 No, dai, l'aritmetica dei puntatori non c'era nemmeno nel TurboPascal.



Forse nelle primissime versioni alfa... :-) Comunque c'erano svariate altre versioni più vecchie, come il Pascal UCSD, quello per mainframe, ed altri. Bisognerebbe vedere se pure tutte queste erano totalmente prive dell'aritmetica dei puntatori. 

Chiaro che, anche se fosse, il Pascal è giustamente rigoroso, di per sè non ti fa certo pigliare un puntatore e manipolarlo come un numero qualsiasi (in Delphi ci sono dei bypass).


 pericolosa.



...ed e`, in fin dei conti, "syntactic sugar".


 ma quando mai. 



Ancora?

Il Pascal originale di Wirth prevedeva i puntatori ("Pascal User Manual and Report", "Pointer Types", sez. 6.3, pag. 145).

Informatevi prima di parlare.


 No, dai, l'aritmetica dei puntatori non c'era nemmeno nel TurboPascal.



Certo che c'era, invece. L'operatore Inc() serviva proprio ad incrementare i puntatori tipizzati.






 maledettamente veloci nella compilazione



Non e` quello lo scopo degli headers. Lo scopo e` isolare interfaccia da implementazione. Tu puoi fornire una libreria compilata e gli header files con i prototipi delle funzioni contenute. Il supporto degli header, pero`, non e` un fattore determinante nella scelta di un linguaggio (puoi fare lo stesso in Java, separando interfaccia e implementazione, puoi fare lo stesso in Delphi con interface/implementation in una unit, puoi fare lo stesso con un paradigma Pimpl in C++, ecc...). Il problema di enoquick e` che e` chiuso nel suo piccolo mondo, e qualunque cosa all'esterno lo spaventa.



Il concetto (non gli header in se stessi) è nato per la separazione  tra 

interfaccia pubblica e parte privata mettendoli in file separati.

Forse che Ada non ha il concetto di header anche se li si chiama parte 

pubblica di un package ed è fisicamente separato dal file che contiene 

la parte privata ?

Java non li ha,per forza,tutto il codice di una classe sta in un solo 

file il quale ha un path ben definito e congruente con il nome della classe.

C# non lo conosco,suppongo che abbia lo stesso concetto di java.

Python,pur non conoscendolo bene,ha comunque la clausola import che 

dovrebbe essere simile alla use di perl.

Un modo per localizzare un altro modulo avvalendosi comunque di una 

variabile d'ambiente PYTHONPATH equivalente a PERLPATH in perl.

Comunque qui si tratta di un linguaggio degli anni 70,non dimentichiamolo.

A quell' epoca,con le capacità elaborative esistenti, importare un 

modulo in modo completo per la compilazione voleva dire usare 

inutilmente la cpu per una analisi del modulo

Con l'header si risparmia tempo almeno (si importa solo la parte pubblica).

Questo avviene ancora oggi sia in Ada che in C,C++

Poi modificando la parte privata di un modulo si risparmia tempo di 

compilazione (non occorre ricompilare i moduli che usano il citato 

modulo) anche se oggi non è cosi importante come negli anni 70 (ma i 

tempi possono farsi sentire su grossi progetti anche oggi).


















All' università pascal (che conoscevo già) fu usato solo per lo studio 

di algoritmi.

Poi dal secondo semestre del primo anno già si passò al C.

Ma comunque sono piu di 20 anni che non tocco un pascal,i ricordi sono 

quelli che sono.

Per questo ho cercato il ref del linguaggio di Wirth.






 Ma comunque sono piu di 20 anni che non tocco un pascal[...]



Sarebbe veramente meglio che tu stessi zitto.




 compilazione 



La compilazione selettiva dei moduli si chiama "make", ed esiste dalla notte dei tempi. 



no non c'entra nulla.

gli header in c contengono le dichiarazioni, dicono al compilatore

che le funzioni sono definite da qualche parte con quella firma. poi è il

linker che va a cercare le definizioni e le collega. 

gli altri linguaggi hanno meccanismi diversi: in java ad esempio il

compilatore vuole vedere direttamente le librerie e gli oggetti 

vengono risolti a runtime anziché essere linkati staticamente. ad ogni

modo l'amico dovrebbe spiegare perché la considera una carenza, se un

linguaggio non fa uso degli header vuol dire che banalmente non gli servono.


 linker che va a cercare le definizioni e le collega. 



Per carità, direi invece che questi benedetti header differiscono solo dall'estensione .h, per il resto sono trattati dal compilatore tali e quali a qualunque altro tipo di include. Tanto è vero che frequentemente dentro il cosiddetto header, oltre a dichiarazioni, trovi intere funzioni con tutto il sorgente.





Ho scritto concetto di inclusione di header.

In pratica il concetto di separazione tra interfaccia e implementazione 

in un modulo.

Poi ogni linguaggio puo fare come vuole

Se prendiamo i linguaggi che usano un compilatore classico (traduce in 

codice nativo) +  linker compreso,questi hanno il concetto di 

separazione tra parte pubblica/privata di un modulo.

Anche Ada,famoso per la sua rigorosità, ha questi concetti.

Ma non è questo il punto,al pascal di Wirth il concetto di parte 

pubblica/privata di un modulo non serviva in quanto un programma => un 

modulo.






Concordo, anch'io sono curioso di capire il fatto della carenza.


 Non e` quello lo scopo degli headers. Lo scopo e` isolare

 > interfaccia da implementazione



Ovvio, come ovvio che si può fare - ma è una scelta - in altri linguaggi.

La mia affermazione è la risposta che mi sono dato a: perché separare 

interfaccia da implementazione? qual è il plus?



-- 

Ciao!

Luca




 Concordo, anch'io sono curioso di capire il fatto della carenza.





Il concetto di header era legato al concetto di modulo che nel pascal di 

Wirth era uno solo.

In se poteva prevedere i moduli (collegati poi dal linker) ma se 

prevedeva i moduli avrebbe dovuto prevedere il modo per fare vedere 

almeno l'interfaccia pubblica da un altro modulo.




 variabile d'ambiente PYTHONPATH equivalente a PERLPATH in perl.



PYTHONPATH serve per cercare i moduli se non sono nella stessa dyrectory 

o in quelle sottostanti.



-- 

Ciao!

Luca



Tempi di compilazione,in caso di modifica della parte privata non c'è 

bisogno di compilare il resto.

Possibilità di scrivere codice avendo solo l'interfaccia.












Dettagli,comunque il concetto è quello di PERLPATH

Anche in perl non c' è bisogno di impostare PERLPATH per i moduli di 

sistema o che stanno nella stessa dir. del programma.




 Fesserie, come al solito. Importare un modulo significa semplicemente

 > "linkare" un modulo, ed e` esattamente cio` che avveniva in quegli



Vero; ma come avrebbe fatto il compilatore a dichiarare formalmente 

corrette delle invocazioni, se non avesse avuto una mappa in cui 

orientarsi (gli headers)? Gli headers entrano in gioco proprio nella 

fase di compilazione. Se il compilatore dovesse esaminare un intero file 

d'insieme, in effetti ci metterebbe qualcosa di più; una quantità 

ridicola di tempo oggi, qualcosa di più allora.

La parte di linking in C avviene solo nel momento in cui tutti i moduli 

sono compilati.



-- 

Ciao!

Luca






 Certo che c'era, invece. L'operatore Inc() serviva proprio

 > ad incrementare i puntatori tipizzati.



Vero, non me lo ricordavo. Peraltro, io ricordo che in qualche misura 

era 'filtrato' (incremento della dimensione dell'oggetto cui il 

puntatore fa riferimento). Esiste(va) un puntatore generico da fare 

incrementare e decrementare 'a la C'?



-- 

Ciao!

Luca




 Con l'header si risparmia tempo almeno (si importa solo la parte pubblica).



si, peccato però che dopo debba passare il linker.




 Non e` quello lo scopo degli headers. Lo scopo e` isolare interfaccia da

implementazione. Tu puoi fornire una libreria compilata e gli header files

con i prototipi delle funzioni contenute. Il supporto degli header, pero`,

non e` un fattore determinante nella scelta di un linguaggio (puoi fare lo

stesso in Java, separando interfaccia e implementazione, puoi fare lo stesso

in Delphi con interface/implementation in una unit, puoi fare lo stesso con

un paradigma Pimpl in C++, ecc...).



Cmq IMHO Java ha offerto il miglior supporto per il programmatore

nella separazione fra interfaccia ed implementazione, soprattutto

perché fin dall'inizio ha impostato il tutto con l'equazione:



Un file = una classe



Questo permette di organizzare il software in maniera molto più

ordinata e con più facilità (non per niente nel corso degli anni

è diventato il nuovo Pascal a livello didattico).








 linguaggio non fa uso degli header vuol dire che banalmente non gli servono..



Infatti gli header sono ormai superati.






 interfaccia da implementazione? qual è il plus?



Non c'e` un plus, in realta`. E` solo cio` che e` implementato in C/C++. Si puo` distribuire l'header, con i prototipi delle funzioni da chiamare, senza necessariamente aprire il sorgente. Per esempio, ogni distribuzione C ha file header con le definizioni delle funzioni di libreria. Che nessuno, ovviamente, guarda mai. 






 Possibilità di scrivere codice avendo solo l'interfaccia.



Ti ci vorrei vedere a spulciare tonnellate di righe di header per capire i prototipi delle funzioni dichiarate. La possibilita` di scrivere codice avendo solo l'interfaccia te la da` la documentazione, non il file header.


 Un file = una classe



Purtroppo e` facilmente bypassabile creando inner classes.






 Per carità, direi invece che questi benedetti header differiscono solo dall'estensione .h



E difatti e` cosi`.




 modulo.



Falso. In Pascal, come in qualunque linguaggio, si possono costruire eseguibili da piu` moduli, semplicemente compilandoli e linkandoli separatamente. Continui a dire sciocchezze.




 almeno l'interfaccia pubblica da un altro modulo.



LOL :) NON SERVE AVERE L'EQUIVALENTE DEGLI HEADER, IMBECILLE!




 incrementare e decrementare 'a la C'?



Oggi esiste il generico Pointer, in Delphi. In Pascal, no. Ma tutte le operazioni di aritmetica dei puntatori avvengono, per lo piu`, su puntatori tipizzati.






 incrementare e decrementare 'a la C'?



Oggi in Delphi e Freepascal c'è sicuramente il tipo generico Pointer. Su questo sono proibite tutte le operazioni aritmetiche, giustamente. 

Cosa però facilmente (e pericolosamente) aggirabile facendo vari cast da pointer ad integer e viceversa.

D'altra parte questo tipo generico è utile quando richiami certe funzioni di libreria C, ma internamente ad un programma Pascal non ce n'è necessità, si usano i puntatori tipizzati, molto più sicuri.






Che è quello che ho spiegato,sopratutto valido per quei tempi (anni 70)




  tanto e` vero che devi mettere dei guard come #pragma (nei compilatori microsoft) o giocare di #ifdef/#define/#endif (negli altri) per evitare doppie inclusioni.



Un vero punto di forza degli header :-))








Ma almeno si risparmiano i tempi di compilazione

Con il linker i moduli vanno linkati,non si puo fare a meno (esistono 

anche i linker incrementali oggi).





A parte void* (puntatore generico) anche C e C++ hanno i puntatori 

tipizzati.




 ha scritto:


Sì è vero, ma non è automatico: le inner classes le usi solo se

sei esperto, altrimenti ti affidi all'organizzazione su esposta,

e cioè un file = una classe. Che è ottima per i programmatori

che stanno imparando e per quelli anche un po' più avvezzi.



E cmq usando le inner classes in un file .java, con la compilazione

in bytecode ottieni senza colpo ferire gli opportuni file .class,

in maniera trasparente, senza preoccuparti di nulla.






 per cui se ciò che sto dicendo è una castroneria per Java, urla.



Non ti preoccupare, C# ha "scopiazzato" tutto quello che gli poteva

servire da Java ;-)








 Non esiste un "concetto di inclusione di header". L'inclusione di header e` la

concatenazione di file. Il contenuto dell'header e` semplicemente preso e

incollato nel file sorgente, nel punto in cui lo includi, tanto e` vero che devi

mettere dei guard come #pragma (nei compilatori microsoft) o giocare di

#ifdef/#define/#endif (negli altri) per evitare doppie inclusioni.



E a volte proprio queste sequenze di #ifdef/#define/#endif rendevano

i sorgenti di difficile comprensione.







Ma anche fonte di potenza

Grazie a loro si possono costruire costrutti dipendenti dall' 

implementazione hw.

Occorre ricordare che il C è un assembler portabile.




 tipizzati.



Certo, però non ricordo se il compilatore fa controlli su eventuali mescolamenti tra i vari tipi.


 implementazione hw.



Nell'attuale Pascal c'è anche quello. 

Per concludere, almeno dal tempo di TurboPascal ci sono: aritmetica puntatori, compilazione condizionale (define/ifdef, ecc.), assembler frammischiato al Pascal, e perfino, udisci udisci, dei simil header ($include)! Manca un precompilatore a livello di quello del C.

Finora l'unica cosa, che io sappia, che si può fare solo in C/C++ e non con Pascal/Delphi è scrivere certi drivers che girano in modalità molto speciali ("ring" del processore?).



Chiaramente si

Il compilatore  C almeno un warning lo emette

In C++ è un errore.










Non saprei, forse occorrerebbe essere piu specifici

Quello che so è un driver normalmente viene fatto in C/C++ (magari 

mischiato  anche con assembler) non in pascal o altro.




 mischiato  anche con assembler) non in pascal o altro.



Ho riguardato meglio. Con Delphi non puoi scrivere direttamente driver kernel mode Windows, solo (si fa per dire) quelli in user mode.


 è diventato il nuovo Pascal a livello didattico).



Mi sfugge il senso. Che vantaggio darebbe dal punto di vista della separazione interfacce/implementazione il fatto che le (ma non tutte) classi vengono definite in file separati? 

In altri linguaggi JVM non è così (penso soprattutto a Clojure) e non si è perso nulla da quel punto di vista.



Ma da chi? E quanto forte andava, chi li ha superati?






Sul fatto che sia meglio consultare la documentazione invece di 

spulciare i file header, penso che non si possa non essere d'accordo, 

soprattutto se la documentazione di una funzione ti dice anche quale 

header includere. Affermare pero' che gli header non facciano parte del 

processo di produzione del software mi sembra azzardato.




 parte pubblica/privata di un modulo e quindi con il concetto di header.

Proprio niente?

Direi che in una interface si possano descrivere solo membri public, 

quindi direi proprio che qualcosa a che vedere ce l'ha.

Anzi uno degli utilizzi preminenti delle interface e' proprio quello. 

Esempi eclatanti potrebbero essere sia il proxy che il service. Tutta 

l'architettura JMX, ad esempio, e' basata sulle interface.

Se mai avessi scritto un webservice axis ti saresti senz'altro accorto 

che il client opera proprio con l'interface.





L' interface di java è sostanzialemente una  classe da cui ereditare

La puoi vedere come un parte pubblica (come una specie di header) ma non 

è proprio cosi.

Implementare un interface è un fatto di design, non è che 

automaticamente si implementa una classe e la sua interface.

Al contrario in C/C++ è normale fare l'header ed il suo body.

Stessa cosa in Ada.

Ma sono dettagli

Ripeto che al  nostro amico piace sparare i dettagli piu reconditi pur 

di andarmi addosso.










Non ho mai implementato driver in windows,ho letto in passato qualcosa 

ma non molto di piu

Come mai in kernel mode non è possibile ?

Quale è la limitazione ?




 è proprio cosi.



Un po' di chiarezza.

Concettualmente, un'interface è un contratto che un oggetto di una 

classe è in grado di soddisfare, indipendentemente dalla gerarchia cui 

appartiene. Non è una classe, né descrive una classe: descrive solo in 

modo aggregato alcuni comportamenti di un oggetto di una classe.



Detto 'da osteria': se conosco come è fatta l'interface E so che un 

oggetto che ho per mano implementa l'interface, posso usarlo tranquillo 

senza conoscere altri dettagli (si usa molto nella costruzione di plugin).



-- 

Ciao!

Luca










Sono d'accordo,ma ribadisco che il concetto di interface è piu un fatto 

di design.

Mentre separare parte pubblica/privata è in pratica un obbligo in C/C++ 

e Ada in java l'implementazione di una interface è solo un fatto di design

Non è che per ogni classe si costruisce una sua interface.

Inoltre una interface puo fare da parte pubblica per piu classi, un 

header è la parte pubblica di un modulo ed uno solo.










 processo di produzione del software mi sembra azzardato.



Mai affermato questo.




 sei esperto, 



In che senso? Creare/usare una inner class non richiede esperienza particolare. E` uno strumento che il linguaggio mette a disposizione. Io ho visto unit lunghe migliaia e migliaia di righe perche` farcite di inner classes, anche quando non erano strettamente necessarie.


 Che è quello che ho spiegato,sopratutto valido per quei tempi (anni 70)



Non hai spiegato un cazzo. Hai scritto, come tuo solito, solo cretinate.




 d'insieme



Esaminare un intero file per cosa? L'header non da` ALCUN vantaggio ai fini della velocita` di compilazione. Anche perche`, semmai, un compilatore C tipico ti da` un warning, se non rispetti il prototipo di funzione, non ti blocca mica.


 di andarmi addosso.



Con gli argomenti che usi, tu ti stai dando addosso da solo, idiota. Se vuoi confrontarti con me, non ti nascondere dietro un killfile.


 header è la parte pubblica di un modulo ed uno solo.



Cazzata. Non c'e` alcun concetto di relazione 1 a 1 tra header e modulo. Tu puoi costruire un header che ha 6 prototipi di funzione, 3 li implementi in un .c che include l'header, altri 3 li implementi in un altro .c che include l'header, e il compilatore non ti ferma affatto.




 Ma almeno si risparmiano i tempi di compilazione



Ma cosa risparmi, idiota! Porta dei numeri!


 Wirth,puoi cercare li oltre che fare ricerche.



E hai scritto un mare di cazzate.




 Mi sfugge il senso. Che vantaggio darebbe dal punto di vista della separazione interfacce/implementazione il fatto che le (ma non tutte) classi vengono definite in file separati? 



Non e` un vantaggio, ma non vedo perche` si dovrebbe scegliere di mettere piu` classi/interfacce in un solo file, quando si puo` scegliere l'organizzazione MOLTO piu` pulita 1-class/interface per file. Piu` granulare rendi il codice, meno conflitti avrai, quando si lavora in team sugli stessi file. Sviluppare per interfacce rende molto piu` facile il testing e si puo` includere una interfaccia senza includere nessuna implementazione specifica.


 Hanno voluto offrire potenzialità che il C già aveva



La compilazione condizionale non e` qualcosa di indispensabile come caratteristisca di un linguaggio. Sono una caratteristica del C, perche` il C possiede un preprocessore. Se fosse fondamentale, la avrebbero implementata in altri linguaggi moderni. I quali, peraltro, deficitano dei tuoi amati header.

E poi dovresti citarmi quale implementazion C risalente a prima del Turbo Pascal implementava il built-in assembly.


 > Finora l'unica cosa, che io sappia, che si può fare solo in C/C++ e non con Pascal/Delphi è scrivere certi drivers che girano in modalità molto speciali ("ring" del processore?).



Se puoi linkare le librerie del sistema operativo, puoi scrivere driver in QUALUNQUE linguaggio compilato.




 Quale è la limitazione ?



Perchè nelle librerie standard di runtime (RTL), a quanto pare, Delphi fa riferimento a chiamate di sistema disponibili solamente in user mode. Pertanto il driver kernel mode va linkato con un RTL speciale, da riscrivere da zero.

Semplicemente nel device driver SDK per C/C++ Microsoft ti fornisce tali moduli speciali.






 Se puoi linkare le librerie del sistema operativo, puoi scrivere driver in QUALUNQUE linguaggio compilato.



Appunto, SE puoi linkare/richiamare le librerie adeguate. Che, nel caso dei driver kernel mode, non sono quelle standard user mode che Delphi automaticamente richiama. 








Capisco

Un C semplicemente compilato come modulo se non usa chiamate a funzioni 

esterne non ha problemi.

Per il kernel mode si dice al compilatore di non usare gli header std 

(questo sotto linux ma sarà cosi anche in win).

Si vede che un modulo scritto in pascal Delphi ha bisogno della RTL,sempre.






Non e' un bypass, nel senso che una classe inner non e' istanziabile 

separatamente dalla sua classe outer, di cui appunto conserva l'istanza.

Inoltre, se parliamo di file .class e non .java, anche le classi inner 

vengono compilate nel proprio file .class.


 automaticamente si implementa una classe e la sua interface.

[...]

Capisco che tu non abbia voluto dibattere esplicitamente sulle 

java-interface. Agli occhi di un purista pero', tutte le cose che 

affermi sono inesatte, perlomeno non sono espresse rigorosamente; ma 

capisco anche che non fosse il tuo intento.



Fatto sta che mi sento anche in obbligo di argomentare la mia critica, o 

meglio il mio punto di vista, per cui da qui in poi puoi anche non leggere.



Da una java-interface non si eredita proprio niente, se non le costanti 

intese come membri "public static final" che per definizione non 

costituiscono comunque un'eredita', ma semplicemente oggetti definiti 

altrove.



Le java-interface costituiscono proprio la parte pubblica di una classe, 

o almeno un pezzo; ovvio che non sei obbigato ad implementare una 

interface pur implementandone autonomamente i metodi, ma ovviamente non 

e' la stessa cosa, ma anzi un cast a runtime termina miseramente con un 

ClassCastException.



Implementare una java-interface non e' solo un fatto di design, nel 

senso che intorno alla tua applicazione, normalmente ci sono pletore di 

classi i cui metodi spessissimo pretendono argomenti di tipo interface, 

e allora implementare l'interface diventa un obbligo, non una scelta di 

design.



Estendendo una classe (e non implementando, come dici) automaticamente 

si implementano tutte le interface implementate dalla classe.



Alcuni sostengono che il meccanismo delle java-interface sia un 

imbarazzante tentativo di fornire al java l'ereditarieta' multipla, 

(assente in java per disegno), ma in realta' non e' assolutamente cosi', 

proprio perche' dalle interface non si eredita nulla; sebbene, in 

determinati casi, implementando diverse interface si possa realizzare in 

java un oggetto analogo ad uno che in C++ che estende diverse classi.

Se vuoi ti faccio degli esempi, o dei disegni se preferisci.

:-)


 ha scritto:


Quoto al 100% ;-)








 Cosi` come e` normale farcire i file header di codice non necessario, come

avviene puntualmente con molti sviluppi C e C++. E` una scelta di design anche

quello. Anzi, in Java/C#, NON PUOI inserire alcuna logica nella interfaccia; in

C/C++ sei liberissimo di inserire logica nei file header. Quindi, dal punto di

vista del design, Java/C# sono persino piu` puliti di C/C++.

CUT



Questo punto è molto importante, anche solo considerando la maggior

facilità di organizzazione offerta dai linguaggi con paradigma OOP nello

sviluppare programmi composti da più sorgenti.






 Sarebbe veramente meglio che tu stessi zitto.



Ma no, perché? Se è causa di discussioni che coinvolgono persone competenti ben vengano le sue cazzate.


 Non e' un bypass, 



Si` che lo e`. Le inner classes sono istanziabili dall'esterno se le dichiari public static. Il fatto che i .class vengano separati non c'entra niente. Il vantaggio 1 class per file e` a livello di scrittura del codice. Ho visto quintalate di codice con inner classes scritte e istanziate a quel modo, per cui posso ben dire che per molti sviluppatori e` un bypass alla regola. 




 Si vede che un modulo scritto in pascal Delphi ha bisogno della RTL,sempre.



No, non ha bisogno della RTL, sempre, idiota. 




 In taluni casi un precompilatore non è da buttare via.



Per esempio?




 Si` che lo e`. Le inner classes sono istanziabili dall'esterno se le dichiari public static.



Quelle che dici tu sono le classi statiche nidificate, non genericamente 

inner. Si tratta quindi di usare una terminologia comune.

Anche le classi locali e anonime sono inner, ma non puoi certo 

dichiararle ne' public ne' static.

Dal java tuporial 

(
https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
):

Terminology: Nested classes are divided into two categories: static and 

non-static. Nested classes that are declared static are called static 

nested classes. Non-static nested classes are called *inner classes*.



Il fatto che i .class vengano separati non c'entra niente.

E perche' mai?



Il vantaggio 1 class per file e` a livello di scrittura del codice.

Ho visto quintalate di codice con inner classes scritte e istanziate a 

quel modo,

per cui posso ben dire che per molti sviluppatori e` un bypass alla regola.

Per molti sviluppatori forse, ma da qui a dire che e' una regola ce ne 

passa.

In genere si usano le classi inner per perseguire uno scopo di 

incapsulamento o raggruppare classi che vengono utlizzate in un solo 

punto. Che poi si veda del codice come dici tu non ne dubito, se ne vede 

anche peggio se e' per questo. Fortunatamente se ne vede anche di meglio.



E' la filosofia del di C/C++

Il programmatore ha la libertà di fare praticamente quello che vuole

Se scrive cazzate o fa un pessimo design la responsabilità è sua

E preferisco cosi,non ho bisogno della mamma che mi dica come devo 

organizzare il codice.




 anche peggio se e' per questo. Fortunatamente se ne vede anche di meglio.



E, ma allora di che stai parlando?




 Il programmatore ha la libertà di fare praticamente quello che vuole



Bella liberta` del cazzo. In nessun contesto, la "liberta` di fare praticamente quello che vuoi" ha mai dato frutti positivi. La curva di apprendimento del C per imparare a fare semplici operazioni con le stringhe (tra sforamenti di memoria, mancate allocazioni, destreggiamenti di malloc() e calloc(), gestione dei '\0' a fine stringa, e tanto altro) e` ripida come la parete del K2.



Non c'è bisogno di fare esempi,conosco java e le interface

Ribadisco con te che è possibile vedere l'interface come una sorta di 

interfaccia pubblica ma ribadisco che comunque non è un obbligo.

Affermi che da una interface non si eredita niente a parte le costanti,ecc..

Ritornando all'esempio C++



class I {

	virtual void f()=0

};



class B : public I {

	virtual void f() {....}

};







B deve implementare per forza f() per poter essere istanziata.

Anche qui non vogliamo chiamarla ereditarietà solo perchè f() non è 

implementata in I ?








 implementata in I ?



Non vogliamo chiamarla "interfaccia". La tua I e` una classe, e il suo metodo virtuale puro puo` persino avere un'implementazione, imbecille.



#include <iostream>



class I {

public:

    virtual void someMethod() = 0;

};



void I::someMethod() {

   std::cout << "hello from a pure virtual method!" << std::endl;

}



class B: public I {

public:

    void someMethod() {

        std::cout << "hello from a concrete method!" << std::endl;

        I::someMethod();

    }

};



int main()

{

    B b;

    b.someMethod();

    return 0;

}


 E, ma allora di che stai parlando?

Sei te che hai tirato fuori l'argomento. A me che la miriade di 

programmatori, che tu stesso hai citato, inzeppino i file di classi 

inner per un solo scopo cosmetico, non me ne puo' fregar di meno. E se 

tu li porti ad esempio per dimostrare l'idea balzana che le classi inner 

sono fatte apposta per "bypassare" la struttura ordinata del codice 

proposta dalla Sun, ti faccio semplicemente notare che e' un'idea tua e 

della miriade di programmatori tuoi pari.






 della miriade di programmatori tuoi pari.



Guarda che si faceva solamente notare che la corrispondenza classe->file è piuttosto comoda quando si lavora in team perché permette di splittare il progetto in tante unità logiche e fisiche agevolando il lavoro e l'integrazione con software di versionamento, nonché facilitando la navigazione nel progetto.

Poi si è anche detto che questo non è sempre vero in quanto esistono classi dentro classi, un meccanismo di cui non si dovrebbe comunque abusare.



Il codice corrispondente java e':

public abstract class I {

   abstract void f();

}

public class B extends I{

    void f() {....}

}



se I fosse un'interface B sarebbe:



public class B implements I {

   *public* void f() {....}

}

Nel primo caso (B extends I) il modificatore implicito d f() e' il 

default, ovvero f() non fa parte dell'interfaccia pubblica.

La differenza e' il modificatore *public* che diventa obbligatorio 

proprio perche' I definisce l'interfaccia pubblica di B ed i suoi metodi 

sono implicitamente public. Inoltre in un interface non e' possibile 

dichiarare metodi statici, ovvero i metodi non-virtual del C++, proprio 

perche', facendo parte dell'interfaccia pubblica, devono essere metodi 

d'istanza.

Un esempio eclatante e' l'interfaccia java.io.Serializable che non ha 

ne' metodi ne nient'altro che possa essere ereditato, ma chi 

l'implementa diventa un oggetto serializzabile, non altrimenti; ovvero 

Serializable aggiunge appunto una "qualita'" all'intefaccia pubblica di 

chi l'implementa, senza aver ereditato alcunche'.

Sono d'accordo che la differenza dell'implementazione e' sottile, ma 

concettualmente non lo e'.

Non so se mi sono spiegato. Consideralo un pour parler, nessun intento 

polemico.








Anche qui, e' l'incapsulamento, proprieta' fondamentale dell'OO, che 

ispira le classi inner, non certo la pulizia del codice.


 Sembrava di no. 



Evita di dire coglionate. Oltreutto, che io e te condividiamo o meno lo stesso concetto di "adeguato" non me ne puo` fregare una ceppa. Non ho mai parlato di "scopo" ne` delle inner classes, ne` delle nested classes. Ho detto che spesso i programmatori bypassano la regola del 1 class per file (e lo ripeto almeno per la terza volta) inzeppando i loro file java di classi annidate quando non ce n'e` bisogno. Non ho mai detto che le "classi inner sono fatte apposta per bypassare la struttura ordinata del codice". Impara a leggere e capire quel che gli altri scrivono. Non e` la prima volta che spari frasi a cazzo. Spero, IO, di non incontrare programmatori TUOI pari.


 ispira le classi inner, non certo la pulizia del codice.



Non ha senso usare l'incapsulamento per scrivere codice di merda.




 dichiarare metodi statici



Falso.


 gestione dei '\0' a fine stringa, e tanto altro) e` ripida come la parete del K2.



Se sei un coglione, si.




 intendendolo come un bypass NEGATIVO, spesso usato da molti programmatori, alla regola del one class per file.

Sinceramente chiedo scusa, siamo dello stesso parere, ma avevo inteso di no.






Attenzione che ho parlato esplicitamente di *metodi* non variabili costanti.


 Per esempio?



Produzione di sorgenti personalizzati in base a qualche parametro. Tipico il caso delle due versioni di un programma per Windows e Linux. Ovviamente si può fare anche in altri modi. Ad esempio con un precompilatore esterno ... :-))

Oppure i precompilatori per i comandi SQL, anche se quelli sono più complessi del precompilatore C, avendo internamente nozione della sintassi dell'SQL.



Eh no è falso anche per i metodi. Java 8 è fra noi da marzo 2014 e ormai siamo nel 2016.


On 05/11/2015 15:33, 4ndre4 wrote:

 > [...]

 >

Miii ma che nervosa che sei, quanto ti durano le tue cose?

Ce le hai a vita? ROTFL!!!!





Immediatamente dopo averti risposto, me l'ero immaginato.

Il fatto e' che proprio un anno e mezzo fa avevo fatto qualche pallido 

tentativo col Java 8, ma c'erano troppe cose che non funzionavano. Stavo 

iniziando un progetto, che durera' per un altro anno, e sinceramente mi 

tirava il culo mettermi in un ambiente che consideravo instabile.

Quindi sono rimasto sul 7 in attesa di tempi migliori.



Adesso dovrebbe essere a posto

L' ho usato poco tempo fa per un progetto e non ho avuto problemi (un 

webservice in tomcat)





Probabilmente, sono andato orora sulla pagina dei bugfix della 8.40 e ce 

n'erano 640+, nella 8.20 660+, nella 8.60 e 8.65 (26.10.2015) sono 

pochi, segno che si sta effettivamente stabilizzando. Ci sono voluti una 

ventina di mesi, durante i quali immagino che mi sarei mangiato il fegato.





Chissà perchè poi non la rilasciano come beta od almeno avvisino.

Forse è perchè cosi non la userebbe nessuno in progetti reali

Il fegato se lo devono rodere,magari da un cliente,gli altri non loro.








 Il fegato se lo devono rodere,magari da un cliente,gli altri non loro.



Sara' una politica Oracle. Da questo punto di vista, nel passaggio da 

Sun a Oracle ho trovato dei sensibili peggioramenti, immagino sia anche 

dovuto al fatto che la dimensione del jre e' aumentata parecchio. Pero' 

una volta i bug erano "multipiattaforma", ora non piu': nel senso che 

c'e' qualcosa che va su linux ma non su osx o win, in qualsiasi 

combinazione, conseguentemente testando le applicazioni con si puo' piu' 

dare per scontato il precetto "run everywhere", e gli sforzi aumentano.


 Quindi sono rimasto sul 7 in attesa di tempi migliori.



io a dire il vero il primo runtime di produzione in java 8 lo installerò

il mese prossimo. il problema non sono i bug i quali credo di non averli

mai incontrati, ma il fatto che oltre alle novità di linguaggio hanno

introdotto numerosi elementi di incompatibilità nelle api, per cui all'inizio

rimanevi scottato dal fatto che i framework su cui ti appoggiavi facevano

botti che pareva il giorno del giudizio. tuttora ad esempio abbiamo un

progetto con una cinquantina di report jasper che con java 8 non compilano,

ma se li converti alla versione successiva non girano più con java 7... 

sono deadlock non piacevoli per un applicativo mediamente critico e già

in produzione.


 Chissà perchè poi non la rilasciano come beta od almeno avvisino.



Perché secondo te quando hanno rilasciato  java 8 sono passati dal pacchetto usato in sviluppo a General Availability?


 In nessun contesto, la "liberta` di fare praticamente quello che vuoi" ha mai dato frutti positivi. 



Però è uno dei principi fondamentali di Python, per converso il linguaggio con la curva di apprendimento più breve che abbia mai visto. Quindi, gestione della memoria a parte, più di tanto male non è.



-- 

Ciao!

Luca


 Guarda che si faceva solamente notare che la corrispondenza classe->file è piuttosto comoda quando si lavora in team perché permette di splittare il progetto in tante unità logiche e fisiche agevolando il lavoro e l'integrazione con software di versionamento, nonché facilitando la navigazione nel progetto.



Questa la quoto alla grande. Io uso questa direttiva anche in C#, dove l'obbligo non c'è.



In Python non sono così bravo, ma li è una questione di comodità di import...



-- 

Ciao!

Luca



Allora vieni dalla mia!

Tempo fa mi dicesti che bastava utilizzare le api per il loro verso e 

tutto avrebbe funzionato. Mentre invece a me non funzionava neanche la 

meta', e mi ero anche contrito perche' non ci riuscivo.

Io dei bug ne avevo incontrati, mi ricordo di una magagna con le classi 

security.krb5 che fu proprio quella che mi fece desistere definitivamente.

In ogni caso, col senno di poi, andando a vedere i bugfixed mi sono 

accorto che ce ne sono un sacco che riguardano proprio il compilatore, 

come dici tu.





Gli ho consigliato un buon psicologo (consiglio paterno).

Pur di andarmi contro spara cazzate su cazzate e si inventa pure fatti 

che mai ho scritto.

Ora sta nel killfile per cui è inutile che mi risponda.

Peccato, un buon elemento che purtroppo ha problemi con le relazioni tra 

individui.








 individui.



Visto che sei un NG e sei anonimo, non costa così tanto farsi insultare se tra un insulto e l'altro impari qualcosa di buono. 

Ti conviene toglierlo dal killfile.



No, mi spiace ma non sopporto le persone arroganti,presuntuose e che per 

di piu insultano

Dubito che abbia da insegnarmi qualcosa una persona cosi.

Se vuole sfogarsi (e vale per chiunque voglia farlo) su usenet esiste 

pure il ng giusto

it.politica

Basta scrivere su qualche argomento (che per di piu non è scienza quindi 

ognuno ha le sue opinioni e sono tutte giuste per quanto bizzarre 

possano sembrare) per innescare qualche flame

Una volta innescato giù con litigi ed insulti.

Lo consiglio vivamente per gli sfoghi.






 Dubito che abbia da insegnarmi qualcosa una persona cosi.



Certamente senza anonimato possono diventare insopportabili e non vale la pena (ma non è detto che 4ndre4 appartenga alla categoria), ma sul NG spero che tu non ti roda il fegato altrimenti ti consiglio un buon psichiatra. Oppure è meglio se lasci stare internet.



Se la persona è molto competente puoi rispondere per le rime (oppure non rispondere affatto) ma non ti conviene non leggerla. Ad esempio tu conosci il pimpl idiom? 4ndre4 l'ha citato, ed è roba per programmatori c++. Sia mai che impari qualcosa.








L' idioma pimpl è un modo per ridurre le dipendenze tra headers

La controindicazione è un codice che potrebbe essere leggermente piu lento.

Tra i professionisti C++ è conosciuto, un po meno tra i principianti del 

linguaggio.

Ma non metto in dubbio la sua professionalità, se non lo hai capito i 

suoi problemi sono altri e non perdo il mio tempo a tirare insulti 

perchè li tira lui.