Il linguaggio di programmazione Delphi
 

OOP su programma da zero
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

Raffaele Filomena 8 Feb 2017 16:35
Salve a tutti e complimenti innanzi tutto per le discussioni. Voglio premettere
a tutti che sono solo un appassionato autodidatta, riesco a programmare in
Delphi, accesso a database form stampe e tutto il resto.
Voglio realizzare un programma partendo da zero ma implementando appieno i
concetti di OOP, ma non riesco a capire alcuni passaggi.
Faccio un esempio che poi posso estendere alla mia problematica. Se ad esempio
ho un classico programma di fatturazione ripartito sulle classiche tabelle del
database: Clienti, fattura , dettagli fattura ecc.
ragionando prettamente OOP devo partire dal realizzare una classe per ogni
tabella, e quindi gestire ad esempio tutte le query di accesso all'interno di
queste classi? Ho difficoltà in questo senso
grazie a tutti, credo di essermi spiegato
4ndre4 8 Feb 2017 17:21
On Wednesday, 8 February 2017 15:35:56 UTC, Raffaele Filomena wrote:

[...]
> Se ad esempio ho un classico programma di fatturazione ripartito sulle
classiche tabelle del database[...]

Usa i componenti per l'accesso ai db e la gestione dei dati gia` presenti in
Delphi e avrai gia` ragionato in maniera "prettamente OOP". Purtroppo, Delphi e`
una tecnologia di nicchia per cui anche investire del tempo imparando un ORM e`
- a mio parere - tempo sprecato.
ca75 8 Feb 2017 22:14
Raffaele Filomena ha scritto:
> Salve a tutti e complimenti innanzi tutto per le discussioni. Voglio
premettere a tutti che sono solo un appassionato autodidatta, riesco a
programmare in Delphi, accesso a database form stampe e tutto il resto.
> Voglio realizzare un programma partendo da zero ma implementando appieno i
concetti di OOP, ma non riesco a capire alcuni passaggi.
> Faccio un esempio che poi posso estendere alla mia problematica. Se ad esempio
ho un classico programma di fatturazione ripartito sulle classiche tabelle del
database: Clienti, fattura , dettagli fattura ecc.
> ragionando prettamente OOP devo partire dal realizzare una classe per ogni
tabella, e quindi gestire ad esempio tutte le query di accesso all'interno di
queste classi? Ho difficoltà in questo senso
> grazie a tutti, credo di essermi spiegato

Ho provato a pensare qualcosa,
Prima creerei una classe base con i dati anagrafici

Classe Anagrafica
Intestazione
Partita Iva
Indirizzo

Poi da questa creerei le classi divise per clienti/fornitori/altro.

Classe Cliente Derivata da anagrafica
Dati Clienti
Codice Gestione

Classe Fornitori Derivata da anagrafica
Dati Fornitore
Codice Gestione

Partendo dalla classe del cliente partirei per la classe di
fatturazione, collegando cliente a fattura.

Classe fatture Derivata da Classe cliente
Dati fatturazione
Codice Fatturazione

Cosi, buttata giu' in pochi minuti.

Comunque bella domanda.

ciao.

--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"

---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Enrico Bianchi 8 Feb 2017 22:15
On 2017-02-08, Raffaele Filomena <carbiniabike@gmail.com> wrote:



> ragionando prettamente OOP devo partire dal realizzare una classe per ogni
> tabella, e quindi gestire ad esempio tutte le query di accesso all'interno
> di queste classi? Ho difficoltà in questo senso

Quello di cui parli è un ORM, che ti permette di mappare una tabella in un
oggetto e di effettuare le varie operazioni (DDL e DML) tramite una semantica
ad oggetti. Ci sono varie scuole di pensiero a tal proposito, ovvero c'è chi
preferisce usarli e chi no (io personalmente sono tra quelli che preferisce
non usarli). Per Delphi ne trovi un paio, personalmente non so dirti quale
sia migliore, per questo lascio la palla agli altri

Enrico
4ndre4 8 Feb 2017 22:28
On Wednesday, 8 February 2017 21:14:10 UTC, ca75 wrote:

> Classe Cliente Derivata da anagrafica
> Classe Fornitori Derivata da anagrafica
> Classe fatture Derivata da Classe cliente

Orrore:

1) una classe non dovrebbe avere un nome al plurale (a meno di essere una di
quelle classi helper contenenti metodi di classe), ma mappare un concetto
singolo;

2) derivare Cliente e Fornitore da una classe Anagrafica e` sbagliato. Non mappa
una relazione is-a. Bisogna comporre, non derivare;

3) Tu pensi veramente che una classe Fattura (non Fatture) si possa derivare da
un Cliente? Cioe` per te una fattura e` un cliente?

L'OOP va studiata, capita ed applicata, NON "buttata giu`" in 5 minuti,
altrimenti si fanno pastrocchi pericolosi.
ca75 8 Feb 2017 22:34
> 2) derivare Cliente e Fornitore da una classe Anagrafica e` sbagliato. Non
mappa una relazione is-a. Bisogna comporre, non derivare;

Magari ho capito male, ma una volta dicevano che le classi vanne
derivate da quelle primitive ( detto anche eredità della classi )


> 3) Tu pensi veramente che una classe Fattura (non Fatture) si possa derivare
da un Cliente? Cioe` per te una fattura e` un cliente?

Collego la fattura al cliente, si potrebbe anche fare altre soluzioni,
creaare la classe fattura ed incapsularla dentro alla classe cliente.

> L'OOP va studiata, capita ed applicata, NON "buttata giu`" in 5 minuti,
altrimenti si fanno pastrocchi pericolosi.

Appunto ma chi ha scritto questo non sono io "Usa i componenti per
l'accesso ai db e la gestione dei dati gia` presenti in Delphi e avrai
gia` ragionato in maniera "prettamente OOP"."




--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"

---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
4ndre4 9 Feb 2017 02:22
On Wednesday, 8 February 2017 21:34:17 UTC, ca75 wrote:

[...]
> Magari ho capito male, ma una volta dicevano che le classi vanne
> derivate da quelle primitive ( detto anche eredità della classi )

Devi ereditare quando ha senso ereditare. Come detto nel messaggio precedente,
ereditare Cliente/Fornitore da Anagrafica non ha senso. Un cliente o un
fornitore non SONO (is-a) un'anagrafica. Semmai *contengono* dati anagrafici.
Come detto prima: composizione invece che ereditarieta`.

> Collego la fattura al cliente, si potrebbe anche fare altre soluzioni,
> creaare la classe fattura ed incapsularla dentro alla classe cliente.

Non hai risposto alla domanda: una fattura e` un cliente? Se la risposta e` no,
non puoi/devi ereditare. Creare la classe fattura e incapsularla dentro la
classe cliente? Tu non hai idea di come si progetta un sistema object-oriented.

> Appunto ma chi ha scritto questo non sono io "Usa i componenti per
> l'accesso ai db e la gestione dei dati gia` presenti in Delphi e avrai
> gia` ragionato in maniera "prettamente OOP"."

Eh, appunto, dove sarebbe l'errore?
Raffaele Filomena 9 Feb 2017 07:49
Il giorno mercoledì 8 febbraio 2017 16:35:56 UTC+1, Raffaele Filomena ha
scritto:
> Salve a tutti e complimenti innanzi tutto per le discussioni. Voglio
premettere a tutti che sono solo un appassionato autodidatta, riesco a
programmare in Delphi, accesso a database form stampe e tutto il resto.
> Voglio realizzare un programma partendo da zero ma implementando appieno i
concetti di OOP, ma non riesco a capire alcuni passaggi.
> Faccio un esempio che poi posso estendere alla mia problematica. Se ad esempio
ho un classico programma di fatturazione ripartito sulle classiche tabelle del
database: Clienti, fattura , dettagli fattura ecc.
> ragionando prettamente OOP devo partire dal realizzare una classe per ogni
tabella, e quindi gestire ad esempio tutte le query di accesso all'interno di
queste classi? Ho difficoltà in questo senso
> grazie a tutti, credo di essermi spiegato

Quindi secondo voi starei sprecando il mio tempo, perché magari secondo me lo
spreco all'inizio e poi lo risparmio dopo. Perché comunque già gestire le
relazioni fra queste tre tabelle( Cliente/fattura/dettagli-fattura) è
complicato. Nella visualizzazione nessun problema, ma nell'aggiornamento dei
dati io trovo parecchie difficoltà. Per questo avevo pensato che gestendo
tramite classi magari avrei sprecato un po' di tempo per progettarle ma poi
sarebbe venuto tutto più facile.
Alberto Salvati 9 Feb 2017 08:55
Se sviluppi client/server, scarica la versione community di visual stu***** e
molla delphi. Se poi punti al web, jee (Netbeans).
Ancora, se punti al mobile, DIMENTICA DELPHI e valuta android stu*****, xamarin,
swift.

Investire tempo OGGI su delphi è tempo sprecato, buttato etc.

> ragionando prettamente OOP devo partire dal realizzare una classe per ogni
> tabella, e quindi gestire ad esempio tutte le query di accesso all'interno di
> queste classi? Ho difficoltà in questo senso

Parli di un ORM.
In ambito .net, uno dei più utilizzati è Entity Framework.
In ambito java c'è una scelta maggiore: IBatis, Hibernate o la più semplice
implementazione JPA disponibile su netbeans.

Questi prodotti fanno in modo automatico quello che ti serve, ma hanno degli
aspetti da tenere bene a mente per un loro utilizzo CONSAPEVOLE.
Cioè, prima di partire all'assalto, occorre DOCUMENTARSI, STUDIARE, CAPIRE E
PROVARE.

In pratica, usando questi strumenti ottieni delle classe tipo "Fattura",
"Cliente", "Articolo" etc.
Poi, per eseguire le classiche operazioni CRUD non vai via SQL ma usi metodi di
queste classi o di classi ad esse collegate.

A.
Alberto Salvati 9 Feb 2017 08:58
> Ho provato a pensare qualcosa,
> Prima creerei una classe base con i dati anagrafici
>
> Classe Anagrafica
> Intestazione
> Partita Iva
> Indirizzo
>
> Poi da questa creerei le classi divise per clienti/fornitori/altro.
>
> Classe Cliente Derivata da anagrafica

ERRORE.

> Classe Fornitori Derivata da anagrafica

ERRORE.

> Classe fatture Derivata da Classe cliente

FOLLIA.

> Cosi, buttata giu' in pochi minuti.

Si, buttata giù, decidi se dalla finestra, nel bidone dell'indifferenziato o
nel "water"...

A.
Alberto Salvati 9 Feb 2017 09:02
> Magari ho capito male, ma una volta dicevano che le classi vanne
> derivate da quelle primitive ( detto anche eredità della classi )

Il fatto che "puoi" ereditare non vuol dire che "devi per forza" ereditare.
Inoltre, mi fai un esempio di classe "primitiva"?


> creaare la classe fattura ed incapsularla dentro alla classe cliente.

Spiega meglio.


A.
Alberto Salvati 9 Feb 2017 09:13
> Quindi secondo voi starei sprecando il mio tempo,

Ogni minuto speso su Delphi attualmente è tempo perso.

> perché magari secondo me lo spreco all'inizio e poi lo risparmio dopo.
Perché
> comunque già gestire le relazioni fra queste tre tabelle( Cliente/fattura
> /dettagli-fattura) è complicato.

Pardon: non hai ancora visto NULLA... :-D

> ma nell'aggiornamento dei dati io trovo parecchie difficoltà.

Spiega.

A.
Raffaele Filomena 9 Feb 2017 09:43
Il giorno giovedì 9 febbraio 2017 09:13:06 UTC+1, Alberto Salvati ha scritto:
>> Quindi secondo voi starei sprecando il mio tempo,
>
> Ogni minuto speso su Delphi attualmente è tempo perso.
>
>> perché magari secondo me lo spreco all'inizio e poi lo risparmio dopo.
Perché
>> comunque già gestire le relazioni fra queste tre tabelle( Cliente/fattura
>> /dettagli-fattura) è complicato.
>
> Pardon: non hai ancora visto NULLA... :-D
>
>> ma nell'aggiornamento dei dati io trovo parecchie difficoltà.
>
> Spiega.
>
> A.

ma non mi va di riprendere tutto con un'altro linguaggio, mi piace Delphi.
Comunque non si tratta di sviluppo Web ma di applicazione locale che accede a DB
Firebird e mysql, c'e' qualche ORM che non si paga?
Alberto Salvati 9 Feb 2017 09:53
> ma non mi va di riprendere tutto con un'altro linguaggio, mi piace Delphi.

Se:

1) non hai vincoli

2) non te ne frega niente di usare uno strumento con una maggiore diffusione con
conseguente maggiore rivendibilità a livello di know how;

3) non te ne frega niente di usare uno strumento che ha un futuro meno
traballante rispetto a delphi;

allora dico: contento tu.



> Comunque non si tratta di sviluppo Web

ok.

> c'e' qualche ORM che non si paga?

Google?

A.
4ndre4 9 Feb 2017 11:08
On Thursday, 9 February 2017 06:49:05 UTC, Raffaele Filomena wrote:

[...]
> Quindi secondo voi starei sprecando il mio tempo, perché magari secondo me lo
spreco all'inizio e poi lo risparmio dopo. Perché comunque già gestire le
relazioni fra queste tre tabelle( Cliente/fattura/dettagli-fattura) è
complicato.

Complicato? Che cosa trovi di cosi` complicato? Quali problemi hai in
aggiornamento, e cosa ti fa pensare che usando una gerarchia di classi
risolveresti il problema?
4ndre4 9 Feb 2017 11:10
On Thursday, 9 February 2017 07:55:47 UTC, Alberto Salvati wrote:

> Se sviluppi client/server, scarica la versione community di visual stu***** e
molla delphi. Se poi punti al web, jee (Netbeans).

Occhio che JEE non significa necessariamente web.
Enrico Bianchi 9 Feb 2017 11:20
On 2017-02-09, Raffaele Filomena <carbiniabike@gmail.com> wrote:

> ma non mi va di riprendere tutto con un'altro linguaggio, mi piace Delphi.

Son d'accordo. Ma sono d'accordo anche con Alberto. Delphi in questo momento
storico è una tecnologia incerta[1] e non so se punterei ad usarlo per nuovi
progetti e per imparare ad usare nuove tecnologie. Di contro, tecnologie come
Java, Python e .NET (C# in primis) sono decisamente affermate, e tecnologie
emergenti (come Go e Swift) si stanno affermando molto bene. Personalmente,
fossi in te punterei a queste alternative, anche solo per imparare qualcosa
di nuovo (personalmente uso Java, Python e Go, in base al progetto che sto
facendo, e sto pensando di dare un'occhiata a C# proprio perché mi permette
ancora più flessibilità)

[1] Secondo le *****isi Tiobe[2] Delphi e Object Pascal (Free Pascal e Lazarus)
sono tra i venti linguaggi più utilizzati, ed in un anno ha guadagnato una
posizione in classifica scavalcando Ruby. In teoria la cosa fa ben sperare, in
pratica è una zona grigia che non mette sicurezza (per fare un paragone, Go,
che in quella classifica è due posizioni sotto a Delphi, nell'ultimo anno ha
guadagnato 54 posizioni, cosa che lo pone in una posizione di rilievo tra le
tecnologie su cui investire tempo)
[2] http://www.tiobe.com/tiobe-index/
Alberto Salvati 9 Feb 2017 12:00
> (personalmente uso Java, Python e Go, in base al progetto che sto
> facendo, e sto pensando di dare un'occhiata a C# proprio perché mi permette
> ancora più flessibilità)

python è carino.
Se solo avessero messo un kaz di delimitatore per chiudere i blocchi IF..
Il delimitatore per l'inizio ci sta: i 2 punti... va bhe.. poco male.

Su quanto hai scritto riguardo delphi:

1) non è piu' come qualche anno fa.
Mo si vedono dei *****i inimmaginabili ai vecchi tempi.
Vedi su xe5 che ogni tanto quando compilavi usciva errore "il ******* exe è in
suo", su berlin ogni tanto si in*****a all'avvio della applicazione se passi da
32 a 64 bit e viceversa.
Stendiamo poi un velo pietoso sulla documentazione peina di cose non spiegate, e
poi ti senti pure preso per il "deratano" quando leggi frasi del tipo
"contribuisci alla dumentazione"..
Su un prodotto A PAGAMENTO e certamente non REGALATO??

2) un mio cliente è passato a berlin.
Certo, sto pc che uso qua non è proprio il top, ma *****arola se berlin si
siede...

3) sarebbe carino vedere un "drilldown" di quelle percentuali per distinguere la
quota parte lazarus da quella delphi

4) magari non tutti sul ng sono utenti linkedin.
Sappiate che David I non è piu sul pezzo: ha cambiato azienda.

5) fatevi un giro su torry e vedete quanti componenti per delphi sono stati
pubblicati negli ultimi 5 anni

6) fatevi una ricerca su monster o infojobs e fate un conteggio delle richieste
delphi urbi et orbi

A.
ca75 9 Feb 2017 13:01
Alberto Salvati ha scritto:
>> Magari ho capito male, ma una volta dicevano che le classi vanne
>> derivate da quelle primitive ( detto anche eredità della classi )
>
> Il fatto che "puoi" ereditare non vuol dire che "devi per forza" ereditare.
> Inoltre, mi fai un esempio di classe "primitiva"?

sicuramente questo è vero.

Un esempio rapido.
Sicuramente sia clienti che fornitori sono delle persone ( fisiche o
civiche ), per cui farei una classe base con dentro la gestione di
questo, sicuramente tutti e due avranno dei dati in comune, metterei la
gestione di questo in una classe base, poi tutto quello che varie lo
metterei in una classe derivata.
Sicuramente tutti avranno un paese, un cap, una provincia, un telefono,
benissimo la gestione di queste cose potrebbe essere in una classe base.

Per dare una risposta completa poi bisognerebbe sapere i requisiti
completi di Raffaele, magari lui ha 100 progetti dove viene usato
l'archivio dei comuni. In tal caso potrebbe essere comodo una classe
solo per quel tipo che userà in tutti i progetti.

Non dico che deve essere la risposta perfetta, dico che lo avrei pensato
in questo modo.


>
>> creaare la classe fattura ed incapsularla dentro alla classe cliente.
>
> Spiega meglio.

Si potrebbe o creare una struttura ereditata mi creo una classe cliente
e una classe fattura che ha la gestione del cliente in eredità oppure mi
crea una classe fattura e la inserisco dentro la classe cliente.

Altre soluzione mi creo della classi: dati anagrafici, fatturazione,
banca, ....., poi mi creo una classe cliente con dentro inseriti questi
tre classi.

Poi si può discutere su altre soluzione, magari la mia è la peggiore.



--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"

---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
ca75 9 Feb 2017 13:04
Alberto Salvati ha scritto:
> Se sviluppi client/server, scarica la versione community di visual stu***** e
molla delphi. Se poi punti al web, jee (Netbeans).
> Ancora, se punti al mobile, DIMENTICA DELPHI e valuta android stu*****,
xamarin, swift.
>
> Investire tempo OGGI su delphi è tempo sprecato, buttato etc.

In un certo senso è varo, cosa consigli rimanendo solo su windows pesavo
a visual stu***** ( in particolare c# ).


Comunque la storia che delphi è morto la sento dai tempi del turbo pascal :)

--
-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"

---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Alberto Salvati 9 Feb 2017 13:08
> Sicuramente sia clienti che fornitori sono delle persone ( fisiche o
> civiche ), per cui farei una classe base con dentro la gestione di
> questo, sicuramente tutti e due avranno dei dati in comune, metterei la
> gestione di questo in una classe base, poi tutto quello che varie lo
> metterei in una classe derivata.
> Sicuramente tutti avranno un paese, un cap, una provincia, un telefono,
> benissimo la gestione di queste cose potrebbe essere in una classe base.

Questa cosa TOZZA PESANTEMENTE con la logica degli ORM.

>>> creaare la classe fattura ed incapsularla dentro alla classe cliente.
>>
>> Spiega meglio.
>
> Si potrebbe o creare una struttura ereditata mi creo una classe cliente
> e una classe fattura che ha la gestione del cliente in eredità oppure mi
> crea una classe fattura e la inserisco dentro la classe cliente.

Quindi un cliente ha una sola fattura?

A.




>
> Altre soluzione mi creo della classi: dati anagrafici, fatturazione,
> banca, ....., poi mi creo una classe cliente con dentro inseriti questi
> tre classi.
>
> Poi si può discutere su altre soluzione, magari la mia è la peggiore.
>
>
>
> --
> -------------------------------
> per scrivere in privato
> togliere "1975nosp"
>
> to reply remove "1975nosp"
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast antivirus.
> https://www.avast.com/antivirus
ca75 9 Feb 2017 13:12
>
> Quindi secondo voi starei sprecando il mio tempo, perché magari
> secondo me lo spreco all'inizio e poi lo risparmio dopo. Perché
> comunque già gestire le relazioni fra queste tre tabelle(
> liente/fattura/dettagli-fattura) è complicato. Nella visualizzazione
> nessun problema, ma nell'aggiornamento dei dati io trovo parecchie
> ifficoltà. Per questo avevo pensato che gestendo tramite classi magari
> avrei sprecato un po' di tempo per progettarle ma poi sarebbe venuto
> utto più facile.--

Secondo me dipende dal tempo che hai a disposizione, dalla voglia e
del'esperienza.

( per mia scarsissima esperienza, uso delphi solo per hobbie ).
Se sono 20 anni che programmi non ad oggetti, l'inizio sarà dura.
Continuerai a dirti: "non ad oggetti facevo cosi, per programmare ad
oggetti devo seguire certe regole più 'lunghe'

In realtà sembra che sia solo questione di abitudine.

Non ad oggetti lo scrivi, ad oggetti devi pensare bene alle classi, poi
scopri che forse potevi gestire in modo diverso le classi basi, una
proprietà che hai dichiarato privata sarebbe tanto comodo se fosse in un
caso resa pubblica.....

Per quanto riguarda la storia dei problemi della gestione dei dati
dovresti spiegare meglio i problemi che hai. ( pero' non chiedermi di
database e simili non li uso da almeno 20 anni o forse di più ).

-------------------------------
per scrivere in privato
togliere "1975nosp"

to reply remove "1975nosp"

---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
4ndre4 9 Feb 2017 13:26
On Thursday, 9 February 2017 12:01:22 UTC, ca75 wrote:

[...]
>sicuramente tutti e due avranno dei dati in comune, metterei la
> gestione di questo in una classe base

Il problema e` che tu vedi le classi base come qualcosa in cui metere "dati in
comune". Un cliente e un fornitore non necessariamente appartengono alla stessa
gerarchia di classi, nonostante possano avere dati in comune.

> Sicuramente tutti avranno un paese, un cap, una provincia, un telefono,
> benissimo la gestione di queste cose potrebbe essere in una classe base.

No, la "gestione" di queste "cose" sta in una classe Recapito, semmai. Non e`
che, poi, siccome clienti e fornitori hanno recapiti, allora serva una classe
base con i recapiti. O almeno, non necessariamente.

> Non dico che deve essere la risposta perfetta, dico che lo avrei pensato
> in questo modo.

La tua risposta e` errata fin nelle ossa, altro che perfetta.

> Si potrebbe o creare una struttura ereditata mi creo una classe cliente
> e una classe fattura che ha la gestione del cliente in eredità oppure mi
> crea una classe fattura e la inserisco dentro la classe cliente.

Purtroppo, lo ripeto, non hai capito cos'e` la OOP e come si usa.
4ndre4 9 Feb 2017 13:29
On Thursday, 9 February 2017 12:12:16 UTC, ca75 wrote:

> scopri che forse potevi gestire in modo diverso le classi basi, una
> proprietà che hai dichiarato privata sarebbe tanto comodo se fosse in un
> caso resa pubblica.....

Certo, e questo e` il tipico esempio di "design smell".
Alberto Salvati 9 Feb 2017 14:05
> In un certo senso è varo, cosa consigli rimanendo solo su windows pesavo
> a visual stu***** ( in particolare c# ).

Infatti...

Dall'ovvio (ma non per tutti) sito è possibile scaricare la community edition
agratis.
Ergo, la vera domanda diventa: quale è il valore aggiunto nello spendere circa
4000 euro per delphi a fronte di un vs2015 agratis, che include qualcosa anche
per il mobile multipiattaforma?
Certo, si deve VEDERE BENE SE XAMARIN FUNZIONA, COME FUNZIONA, SE SPUTA FUORI
QUALCOSA DI NATIVO PER ANDROID/IOS, SE AD USARLO NON TI VIENE L'ULCERA...etc.


> Comunque la storia che delphi è morto la sento dai tempi del turbo pascal :)

Io la sento da quanto ho iniziato a usare delphi (1997).
Chiunque, in questo NG, SA bene come ho sempre sparato e quando capita tutt' ora
sparo a zero su vb5/vb6.
..azz..ricordo ancors quando usì .net....tutti a parlar bene di asp.net...
E io che sottolineavo che lo sforzo per produrre qualcosa peggio del vesshio ASP
sarebbe stato immane, anche per microsoft....

Idem dicasi per i RIDICOLI CONFRONTI tra vb5/vb6 e le versioni di delphi delle
stesso periodo: basta cercare nei vecchi post.

Ma adesso, imho, a poco senso.
Fosse stabile come era ai vecchi tempi, ok, ma non lo è più.
I rilasci troppo frequenti non fanno bene a nessun prodotto software.
Che dire dello scivolone con la prima versione di FM?
Quanti, oggi, usano FM?

E poi, scusate se penso male, ma sarei proprio curioso di sapere come mai David
I se ne è andato.. Magari conta poco, sta cosa, ma magari conta...?!

A.
Enrico Bianchi 9 Feb 2017 14:46
On 2017-02-09, Alberto Salvati <zzzato@gmail.com> wrote:

> python è carino.
> Se solo avessero messo un kaz di delimitatore per chiudere i blocchi IF..
> Il delimitatore per l'inizio ci sta: i 2 punti... va bhe.. poco male.

Il delimitatore c'è: gli spazi ;)
Python, così come altri linguaggi meno utilizzati, usa l'identazione per
definire blocchi di codice, pertanto un blocco del genere è perfettamente
funzionale:

def hello():
if 1 == 1:
try:
print(1 + 1)
except:
print(1)

Il motivo principale per questa sintassi è data dalle sue origini: Python è
il successore di ABC (sempre di Van Rossum), che era pensato per scrivere
prototipi e per insegnamento. Con Python, Van Rossum ha semplicemente preso
gli elementi che gli interessava mantenere da ABC e li ha riportati sul nuovo
linguaggio. Personalmente a me piace come sintassi, anche perché identare è
comunque una pratica che adotto sempre. Più che altro, in contesti di team,
conviene adottare uno stile di identazione comune che, in Python, è quasi
sempre allineato alla specifica di linguaggio chiamata PEP8

Enrico
Alberto Salvati 9 Feb 2017 14:57
> Il delimitatore c'è: gli spazi ;)

Lol!


> Python, così come altri linguaggi meno utilizzati, usa l'identazione per
> definire blocchi di codice, pertanto un blocco del genere è perfettamente

Conosco Python, anche se poco.
L'ho usato per aggiungere ad un programma delphi bello tosto un meta-linguaggio
per implementare delle regole tramite una interfaccia "UTONTO".
Devo dire che ha funzionato egregiamente allo scopo e che sono rimasto
abbastanza sorpreso (positivamente) dalle performance.


A.
4ndre4 9 Feb 2017 15:09
On Thursday, 9 February 2017 13:57:31 UTC, Alberto Salvati wrote:

>> Il delimitatore c'è: gli spazi ;)
>
> Lol!

Huh?! Perche` ridi? Perche`, in Delphi hai necessariamente bisogno di un
begin/end per delimitare il codice che scrivi? E` solo verbosita` inutile. La
cosa piu` importante e` indentare.
4ndre4 9 Feb 2017 15:36
On Thursday, 9 February 2017 13:05:21 UTC, Alberto Salvati wrote:

[...]
> Certo, si deve VEDERE BENE SE XAMARIN FUNZIONA, COME FUNZIONA, SE SPUTA FUORI
QUALCOSA DI NATIVO PER ANDROID/IOS, SE AD USARLO NON TI VIENE L'ULCERA...etc.

Perche` il maiuscolo?
Guarda che non sei il primo che usa Xamarin, e` una piattaforma abbastanza
consolidata nel mondo mobile, quindi dubitare se funzioni e` stupido.
Enrico Bianchi 9 Feb 2017 17:40
On 2017-02-09, Alberto Salvati <zzzato@gmail.com> wrote:

> Ergo, la vera domanda diventa: quale è il valore aggiunto nello spendere
> circa 4000 euro per delphi a fronte di un vs2015 agratis, che include
> qualcosa anche per il mobile multipiattaforma?

Perché nelle versioni a pagamento ti viene offerta più roba. E in Visual
Stu*****
non è che ti offrano molto nella versione gratuita:

https://www.visualstu*****.com/vs/compare/

Devo però darti atto che in effetti Microsoft ti offre di più rispetto ad
Embarcadero:

https://www.embarcadero.com/products/delphi/product-editions

Che dire, spero che ci arrivino prima della definitiva morte, Go è sempre più
un'alternativa accettabile per le applicazioni native, e per il resto .NET e
Java sono più interessanti

Enrico
4ndre4 9 Feb 2017 17:49
On Thursday, 9 February 2017 16:40:48 UTC, Enrico Bianchi wrote:

[...]
> Che dire, spero che ci arrivino prima della definitiva morte

Speranza vana, a mio parere. Delphi, in confronto a quel che si puo` fare con
Java e .NET, e` poco piu` che un giocattolo. Anche il linguaggio su cui e`
basato, in termini di limiti e verbosita`, non aiuta affatto.

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio di programmazione Delphi | Tutti i gruppi | it.comp.lang.delphi | Notizie e discussioni delphi | Delphi Mobile | Servizio di consultazione news.