Newsgroup: it.comp.lang.visual-basic
Titolo: Anonymous Types

Secondo voi quanto sono vicini (o lontani) concettualmente e praticamente 
gli anonymous types di NET e le vecchie Variant di VB6?
eSQueL 

 gli anonymous types di NET e le vecchie Variant di VB6?
Io non ho mai usato VB6, quindi non so esattamente cos'è il tipo 
Variant, perché immagino che sia una cosa analoga (anche se più 
limitata) del tipo Object in .NET.
Object è il tipo più generico, e tutti gli altri tipo ereditano 
direttamente o indirettamente da Object. Quindi Object puà contenere 
tutti gli altri tipi. Es:
         Dim a As Object
         a = 1234
         a = "Ciao mondo"
         a = New DateTime(2008, 12, 3)
Sono tutte assegnazioni ammesse.
Invece i tipi anonimi sono un'altra cosa. Coi tipi anonimi è possibile 
creare una istanza di un oggetto al volo, senza prima definire una 
classe. Es:
      Dim persona = New With {.Nome = "Giuseppe", .Cognome = "Verdi"}
      MessageBox.Show(persona.Nome & " " & persona.Cognome)
I tipi anonimi sono stati introdotti principalmente per essere impiegati 
in LINQ.
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Scarica "OpenOffice.org 3.0 Soluzioni a raccolta", molto più di semplici 
FAQ! 
http://it.openoffice.org/doc/manuali/

Per la fretta mi è uscito un messaggio "leggermente" sgrammaticato, ma 
spero che si capisca ugualmente :-)



Era chiarissmo. 

      MessageBox.Show(persona.Nome & " " & persona.Cognome)
E' qui che mi perdo: io non riesco a leggerlo, non è Basic per me.
Io vedo una Collection dichiarata male e che non potrebbe mai funzionare, le 
parentesi graffe proprie del C ma non del Basic, una With senza End With. 
Quindi, per analogia, potrebbe essere lecito anche If senza End If, For 
senza Next...
-- 
Greg 

 E' qui che mi perdo: io non riesco a leggerlo, non è Basic per me.
E' una nuova sintassi di VB9, che sfrutta le caratteristiche di .NET 
3.5. C# 3.0 ha una funzionalità perfettamente sovrapponibile, solo che 
con sintassi diversa (neppure troppo...).


 Mentre l'Obiect in VB Classic è proprio quello che dice il nome: un oggetto. 
Per chiarire meglio: in .NET un form E' un oggetto, come tutto. Quindi 
anche un form eredita dal tipo base Object.
Quanto alle parentesi graffe si usano in diverse situazioni in 
VB.NET
. 
Il caso più tipico è forse l'assegnazione dei valori a un array al 
momento della sua definizione. Es:
         Dim a() As String = {"aaa", "bbb", "ccc"}


 senza Next...
Che ci vuoi fare?
VB non è stato concepito per essere utilizzato in determinati contesti.
Ecco che allora, per adattarlo a detti contesti, lo devono 
"stiracchiare" adottando soluzioni che, francamente, a me sembrano oscene.
Non è un caso che C# abbia relativamente poche parole chiave, mentre 
vb.net
 ne ha più del doppio (mi pare di averne contate, con la versione 
2 del framework, 66 contro circa 160).
Un esempio è il With usato in quel contesto, ma ce ne sono altri.
-- 
S.

"Stevie" <jstevie__@__gmail__.com> ha scritto nel messaggio 
news:91EZk.3324$J84....@tornado.fastwebnet.it...

E' un mesetto che sto spippolando VB .net (oddio, detta così sembra un 
tantino scabrosa) ma devo dire, infine, la curva d'apprendimento me l'ero 
pensata più ardua. Sarà anche perché, scoprendo expression blend, mi sono 
gasato un bel po' e questo, bene o male, aiuta.
eSQueL 

 E come tale accetteà un oggetto e mai un boolean.
zac
Innanzituto si cerca di avere sempre una tipizzazione stretta per non
andare incontro a casini e blocchi del programma!
Quindi SAREBBE cosa buona e giusta avere lo strict ON....sarebbe
perchè spesso anche io lo disattivo!
E di conseguenza sarebbe preferibile NON USARE il tipo Object!
Come in vb6 era meglio usare POCO i Variant!
Detto questo....
arreggiti forte alla sedia greg....in dotNet....anche un boolean
Eredita da System.Object!!!
in dot net anche i tipi sono oggetti.....tutto è un oggetto!
Apri il libro di Balena (non credere a me)...
vb.net
 Nozioni di base
(ed. tascabile) pag 215
oppure apri msdn fai F1 su Double o su Single e guarda....avrai metodi
e interfacce...guarda quante interfacce supporta un numero!
Boolean poi è particolare.....lo hanno mantenuto più che altro per
compatibilità...butta via un sacco di spazio per nulla!
Tra le altre cose se ti vuoi fare un tuo valore tipo "Numero
Klingon"...puoi derivare da System.Object e farti il tuo tipo
particolare
Ci sono pregi e difetti ad essere tutto "oggetto"
Sempre nel libro di balena ( che è pure vecchiotto ma spiega bene
acuni concetti base)
c'è un problema
che puoi visualizzare così (pag 236)
        Dim s As String
        s = "AAA"
        s.Insert(3, "BBBBBBB")
        MessageBox.Show(s, "Test Stringa")
        s = s.Insert(3, "CCCCCCCC")
        MessageBox.Show(s, "Test Stringa")
che spiega perchè esiste string e stringbuilder
le stringhe sono oggetti immutabili per 
vb.net
 ( e credo anche per c#
essendo una caratteristica del framework)
per modificare una stringa in memoria.....crea un nuovo oggetto e lo
assegna alla variabile quindi
con
 s = s.Insert(3, "CCCCCCCC")
hai la creazione di due oggetti di cui uno sostituisce l'altro...e che
il GC quanto prima se non tenuto in vita da altre variabili pulirà!
In dotnet ripeto...viviamo in un mondo di oggetti...
ed è per questo che sarebbe meglio tipizzarli il più possibile per
evitare casini!!!

 in dot net anche i tipi sono oggetti.....tutto è un oggetto!
Si tutto è un oggetto!
Tutto è UN oggetto!
Tutto è UN SOLO oggetto!
E' qusto il guaio; che ci azzecca il bool con system? E' chiaro che il tipo 
di dato non serva piu, tanto è un oggetto figlio di system pure lui; ma 
allora toglietelo.
Pure Visual Basic ha gli oggetti, ma non uno solo, ne ha tanti, e tutti 
diversi tra loro, e con un nome che dice tutto, e ognuno con i suoi metodi e 
proprieta. Screen, Printer,Form......
Ma io poi non avrei nulla contro VbNet,  ha il suo mondo, i suoi pregi, il 
suo target, cosi come non ho nulla contro Java e altri linguaggi. Ma mi ha 
dato un pochettino fastidio che abbiano cercato  di spacciarlo com Visual 
Basic 7
-- 
Greg 

 allora toglietelo.
Io credo che i tuoi dubbi derivino da una cattiva comprensione dei 
concetti base dell'OOP, cosa di per se non stigmatizzabile :-)
Per semplificare possiamo dire che per "oggetto" si intende una istanza 
di una classe. Le classi sono quindi degli "stampini" che servono per 
creare oggetti tutti dello stesso tipo.
Io posso creare una classe (derivata) che eredita da una classe definita 
precedentemente (base), in modo, volendo, da importare nella mia nuova 
classe tutti i metodi, le proprietà e gli eventi della classe base. Poi 
la classe derivata la posso personalizzare aggiungendo metodi, proprietà 
eccetera, oppure modificando quelli che ho ereditato dalla classe base 
(overriding).
A sua volta la mia nuova classe può essere ereditata da un'altra classe 
ancora, e così all'infinito. Si ha quindi un albero di classi, che ha 
come radice una classe "archetipica" si potrebbe dire. E la classe 
archetipica più importante di .NET è proprio System.Object, dalla quale 
derivano per ereditarietà tutti i tipi di .NET.
Quindi in .NET non è che esiste un solo potenziale oggetto, ne esistono 
migliaia, ma tutti derivano da Object, quindi possono essere sempre 
assegnati a una variabile Object, che li può sempre contenere essendo la 
classe madre.
Ora, il fatto che si possa fare non comporta normalmente che sia un bene 
farlo. A meno di esigenze particolari è sempre meglio "mettere un 
oggetto nel suo giusto contenitore", se mi si passa la metafora :-)



La differenza fondamentale è che col variant (o object in .net) il tipo 
della variabile viene risolto a runtime (late-binding), mentre per i tipi 
anonimi esso è ricavato direttamente dal compilatore, a partire 
dall'assegnamento in fase di dichiarazione della variabile (type inference).
http://msdn.microsoft.com/en-us/magazine/cc163345.aspx
Bye
Raf 

"Rafunk" <rafun...@NOTHANKSlibero.it> ha scritto nel messaggio 
news:gh87fj$kn5$1...@alix.livenet.it...

Proprio questo cercavo.
Grazie.
eSQueL 

 servono per creare oggetti tutti dello stesso tipo.
Grazie Vitriol, ma pure Visual Basic fa queste cose. Magari con piu 
difficoltà ma le fa.
Io non ho mai avuto necessità di usare oggetti diversi da quelli standard ma 
ricordo di aver spippolato, su un progettino di Balena, una super mega 
TextBox. Per capirne lalogica l'ho cambiato modificato, migliorato. E' 
vneuto fuori un bell'oggettino con una sua interfaccia grafica per le 
impostazione da dove si impostava tutto.
Ma l'oggetto padre era sempre il textbox e il linguaggio sempre il Visual 
Basic che si usava dalla versione 3.
Quindi l'oggetto non è una novità introdotta dal Net. C'era anche prima, 
forse era una presenza piu discreta...
-- 
Greg 

 forse era una presenza piu discreta...
Però considera che VB non è un linguaggio orientato agli oggetti, ne 
possiede alcune caratteristiche ma è ben lontano dall'esserlo.
in vb non esiste l'ereditarietà se non per delega,
non esite il polimorfismo e non esistono tante altre cose.
poi se vogliamo fare un po' di filosofia possimo dire che OOP non è la 
panacea, i puristi affermeranno che vb e c# non non linguaggi ad oggetti 
"puri" perché, ad esempio, non hanno il supporto all'ereditarietà 
multipla etc etc, ma qui siamo -come ho già detto- sulla filosofia :-)
ciao
stefano

 VITRIOL ha scritto:
zac
Calma e gesso
i VB6 ereditavi solo le interfacce...era un OOP all'acqua di rose!
In VB6 facevi "oggetti" che erano OCX con tutte le madone del caso che
si tiravano quano le versione 1.2.3424256 andava in conflitto con la
versione 1.2.3424257!
Avevi tante cose che erano il pardigma di un modo di sviluppare logico
e consequenziale...faccio questo POI questo POI quest'altro....facevi
programmi performanti...anche IPER performanti...per QUELLA realtà! Se
il "mondo" cambiava anche di poco....crollava tutto e dovevi rimettere
mano al codice anche pesantemente!
Il fatto di avere TUTTI più o meno sviluppate le nostre proprie
DLL,OCX,Moduli standard per non reinventare la ruota era una parziale
ammiisiio implicita che non sempre si veniva pagati per tutte le volte
reinventare la ruota!
E che si spacciava le nostre proprie routines generali ma meno
performanti in nome del dio "quattrino": legittimo e sensato in un
mondo di gente che lavora per campare!
Io stamani c'ho sbattuto il capo i un problema del genere mal posto
in 
asp.net
 devo fare una zona riservata di un sito web:
ci sono 2 zone ...una per i gestori..ed una per gli utenti....i
gestori mettono a disposizione degli utenti file e commento del file
Ho voluto usare le membership api + access dato che il sito web è su
aruba...ed è poco sfruttato (ha poche hit giusto quelle dei
dipendenti)
Ho avuto il prolema di espandere le info raccolte e di volerlo fare
non appesantendo con gli strument previst alle membership...ma ho
voluto modificare la struttura delle tabelle
In pratica un membershipUser ha in più nome cognome indirizzo cell
email etc etc
mi sono fatto una classe che raccoglie i meodi di utilzzo comune :
cerca utente, cerca files utente, recupera dati etc etc
MA LE BRUTTE ABITUDINI SON DURE A MORIRE...da buon vb6-ista...mi son
fatto ritornare i dati....
c'ho pensato dopo....
se mi facevo ritornare una collection di oggetti UTENTE_ESTESO campavo
meglio!
Adesso tutto funziona
ma se vendo questa app ad un altro cliente che ha ALTRI DATI...e caso
mai distribuiti su 2  o più tabelle....??? DOH!
quanto sarebbe stato bello avere una classe base Utente_Esteso_STD
(con tutti i suoi metodi proprietà eventi)....e derivare da quella le
personalizzazioni di ogni cliente a cui vendo sto coso!!!
Morale della favola
..stanotte si fa bianca per modificare il codice!
La colpa è dlla nostra "forma mentis"..ecco percè io consiglierei di
NON FOSSILIZZARSI MAI su u solo linguaggio....il cervello deve
rimanere elastico se vuole adattarsi ai problemi!
SEMPRE E SOLTANTO IMHO!!!!!

GRRRRRRRRRR!!!!!
IO ODIO QUESTA TASTIERA!!!!

rimanere elastico se vuole adattarsi ai problemi!
E ti devo quotare, ti devo :) Ma, dico, se i cervelloni di M$ ci avessero 
pensato prima a strutturare VB6 diversamente ci avrebbero risparmiato dei 
bei mal di pancia (sì, se mio nonno avesse avuto le ruote sarebbe stato una 
carriola ... ok :P)
Ciauz
eSQueL