[VB.NET] Concatenazione stringhe e data odierna

[oregon]

L'effetto e' il medesimo ma non e' la stessa cosa.

[Genius7115]

In che senso non è la stessa cosa?

mi interessa saperne di più.

[oregon]

Significa che la versione con la CStr non e' OOP ed e' possibile usarla (come con VB6) proprio perche' esiste il namespace Microsoft.VisualBasic (di default).

La sintassi OOP utilizzata con il framework .NET e' l'altra, che tratta tutto come "oggetto" ...

[Genius7115]

Beh programmo in OOP da un pò e fino a che non è uscito fuori .net questo tipo di sintassi non è che erano molto utilizzate.

La oop è una peculiarità di molti linguaggi (c++, Java, Delphi etc).

la OOP è una tecnica e non delle sintassi predefinite.

Se sbaglio correggetemi.

[ans]

il discorso è imparare a conoscere il framework, e lasciare quello che rigurada le versioni precedenti di visual basic. Tornerà utile in seguito.

Poi Today.Month.tostring() è ad esempio tra le altre cose in grado di gestire se necessario le diverse impostazioni internazionali, e chi si è trovato in difficoltà per via di differenti settaggi su server/pc differenti sa di cosa parlo.

Cstr(Month(date)) necessata di conversione, nella forma .net, trasparente ma viene fatta.

[oregon]

Originariamente inviato da Genius7115
Beh programmo in OOP da un pò e fino a che non è uscito fuori .net questo tipo di sintassi non è che erano molto utilizzate.

Ok ... ma CStr() e' una funzione e non ha proprio nulla di OO.

Il problema e' che la programmazione VB6 non era OO (al contrario di C++).

Tutto qui.

[Genius7115]

In delphi, che è molto OOP, per esempio esistono delle FUNZIONI che castano i dati in un tipo diverso. Giusto un esempio diverso da VB.

Mi permetto di dire che la OOP non si differenzia se utilizzo una funzione o meno. Anche perchè .tostring() è certamente un richiamo ad una funzione del compilatore che viene inheritata implicitamente, invece che richiamarla esplicitamente. Le caratteristiche dell'OOP secondo me sono l'ereditarietà e il polimorfismo e l'incapsulamento del codice e non se si utilizza una funzione esplicitamente o meno.

In un certo senso hai ragione, accedere in quel modo e come se usassi un forte incapsulamento, ma se cosi fosse quando istanzi una classe in un'altra classe questo farebbe saltare il tutto, o anche dichiarare una semplice variabile.

[oregon]

ToString e' un metodo di un oggetto (di object da cui ereditano tutti gli oggetti in .NET). Quindi non e' una funzione (nel senso originale di questo elemento di programmazione), tantomeno ha a che fare con il compilatore.

Per capirci, non puoi scrivere

ToString(...)

come per una qualsiasi funzione di libreria di un linguaggio di tipo procedurale (cosa che invece fai con CStr perche' CStr non e' un metodo di una determinata classe ...).

Sulle caratteristiche elencate dell'OOP sono d'accordo. Sul resto no.

CStr(), ti ripeto, non ha nulla di OOP ...

[alka]

Originariamente inviato da oregon
Il fatto che il namespace Microsoft.VisualBasic venga attivato di default fa in modo che anche nei nuovi progetti ci sia la "tendenza" ad usare la vecchia sintassi e la OOP va a farsi benedire ...

Serve solamente a fare in modo che gli utenti abituati a VB6 si inseriscano più facilmente nel framework e a dare la possibilità, senza troppi effetti collaterali, di utilizzare una sintassi un po' più tendente al procedurale.

Originariamente inviato da oregon
Ovviamente si puo' disabilitare ma nessuno la fa in pratica.

Non ci vedo poi nulla di "illegale".

Originariamente inviato da oregon
Qualcuno si "accorge" della cosa solamente quando inizia a programmare in C# e "nota" che la stessa sintassi la puo' usare anche in VB ... E' uno dei meriti del C# (non me ne voglia alka ...)

Nessun problema, ma è una "fissa".

E' il .NET Framework ad essere completamente orientato agli oggetti, pertanto i compilatori dei vari linguaggi sono tenuti semplicemente a generare codice conforme a tale impostazione, così come avviene con C#, VB.NET e Delphi.NET.

Detto questo, se VB.NET o Delphi.NET, per prenderne due, consentono anche di impostare le cose in modo più procedurale o magari di utilizzare una tecnica mista purchè questa venga venga regolarmente tradotta ed eseguita così come viene intesa dal programmatore a livello logico, non ci vedo nulla di sacrilego, come la si vuol far apparire, anzi trovo che sia una caratteristica di tutto rispetto del linguaggio.

Nulla contro C# ma...il suo merito sarebbe quello di far aprire gli occhi a chi programma in VB.NET e scoprire che può potenzialmente creare delle classi?
Mi sembra un legame alquanto forzato e pretestuoso, che tira in ballo C# in questo contesto in cui, ahimé, non ha molto a che vedere.
Per sapere che si fanno classi con VB.NET (e come si fanno) basta leggere la documentazione. E se uno non vuole farle, non è mica obbligato e se non abusa delle funzionalità delle classi a sua disposizione impostando comunque il proprio programma secondo una logica maggiormente procedurale, questo senz'altro non lo manda in malora.

Originariamente inviato da oregon
Significa che la versione con la CStr non e' OOP ed e' possibile usarla (come con VB6) proprio perche' esiste il namespace Microsoft.VisualBasic (di default).
La sintassi OOP utilizzata con il framework .NET e' l'altra, che tratta tutto come "oggetto" ...

La programmazione orientata agli oggetti è un paradigma, non una sintassi; può esistere una sintassi che supporta il paradigma OOP, questo sì, ma non esclude che per beneficiare dei vantaggi della OOP non si debba necessariamente escludere qualsiasi utilizzo di una procedura o di una funzione.

Da anni uso Delphi e sviluppo progetti usando questo paradigma, ma nulla rende la mia applicazione meno OOP se, in un determinato punto, invoco una banale funzione per la conversione di un valore intero a stringa o viceversa.

Supportare la programmazione orientata agli oggetti non significa nemmeno escludere qualsiasi sintassi che propriamente non lo sia, tant'è che Delphi.NET e VB.NET sono entrambi pienamente OOP ma consentono la definizione di procedure e funzioni all'interno di moduli che possono tornare utili in più frangenti; poi, che il compilatore traduca tutto alla chiamata di un metodo statico di una classe avente un nome generato automaticamente, poco importa, ma a volte questo automatismo consente di avere comunque un codice leggibile e di fornire una serie di vantaggi che si sentono in fase di scrittura del codice e che ottengono lo stesso effetto e, spesso, le stesse istruzioni in codice intermedio nel file generato.

Non è il caso delle funzioni di conversione di Microsoft.VisualBasic, per intenderci, ma...

Originariamente inviato da ans
il discorso è imparare a conoscere il framework, e lasciare quello che rigurada le versioni precedenti di visual basic. Tornerà utile in seguito.

...ma l'importante è sapere cosa comporta l'uso delle funzioni di conversione al posto della chiamata a determinati metodi: il caricamento di un assembly aggiuntivo, la generazione di una chiamata ad un metodo in più di una classe contenuta in quest'assembly che, a sua volta, richiama il metodo convenzionale di conversione, senza parametri che indichino il formato.

Concordo che, da un certo punto di vista, richiamare una classe che alla fine esegue il codice che avremmo dovuto scrivere noi può essere considerato lavoro sprecato, tuttavia......se qualcuno vuole usare una sintassi procedurale per semplificarsi la vita, NON ROMPETEGLI LE SCATOLE con 3 pagine di discussione.

[oregon]

Inutile dire che non sono d'accordo su alcuni punti delle tue affermazioni e che la mia non e' una fissa ... ma padrone di non crederci ...

La visione "positiva" del namespace VisualBasic e' una tua personale opinione, che tanti altri hanno. Come tanti altri, la vedo diversamente e la giudico "negativa" non tanto perche' esistente ma perche' attivata di default. Il fatto di poter scegliere se avvalersi di tale strumento dovrebbe essere una scelta "ponderata" del programmatore che si avvicina a VB.NET.
In realta' questa e' una scelta di MS dettata piu' da scelte legate alla convenienza economica di un passaggio quanto piu' veloce possibile al nuovo strumento piuttosto che ad un rispetto dell'utente programmatore.

Sul fatto che non disabilitarla non sia "illegale", ovviamente la prendo come battuta. Il concetto e' che e' "subdolamente" attiva.

Sul fatto che OOP non voglia dire utilizzare una certa sintassi e che si possa mischiare codice con sintassi OO e non OO, non ci piove.
Ma dillo a chi programma in Java (e anche in C#) ...

Sul fatto di ROMPERE LE SCATOLE penso che ogni tanto una discussione di carattere un po' piu' teorico, non faccia male a nessuno ...