Carillon .NET http://blogs.ugidotnet.org/adrian/category/Carillon .NET.aspx Carillon .NET it-IT Adrian Florea Subtext Version 2.6.0.0 Vita da service pack http://blogs.ugidotnet.org/adrian/archive/2009/03/26/vita-da-service-pack.aspx <p>Ho scoperto una cosa a mio parere strana: un metodo (<a href="http://msdn.microsoft.com/en-us/library/cc491445.aspx">System.Web.UI.WebControls.ParameterCollection.Add(String, DbType, String)</a>) che esiste solo nelle versioni service pack del framework .NET (2.0 SP2, 3.0 SP2, 3.5 SP1) ma non nelle versioni "normali". Mi chiedo come mai se il metodo e' stato introdotto in .NET 2.0 SP2, l'abbiano tolto dalle .NET 3.0 e .NET 3.0 SP1 per reintrodurlo nella .NET 3.0 SP2 per poi toglierlo di nuovo dalla .NET 3.5 e finalmente reintrodurlo nella .NET 3.5 SP1???...</p> <p>[OT] Per i tanti amici milanesi: sono a Milano dall'8 di marzo e torno in Romania settimana prossima, probabilmente mercoledi' - se vi fa piacere magari si organizza un pranzo o una cena!</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/95802.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2009/03/26/vita-da-service-pack.aspx Thu, 26 Mar 2009 14:40:42 GMT http://blogs.ugidotnet.org/adrian/archive/2009/03/26/vita-da-service-pack.aspx#feedback 377 http://blogs.ugidotnet.org/adrian/comments/commentRss/95802.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/95802.aspx Sul cast del foreach http://blogs.ugidotnet.org/adrian/archive/2009/01/14/sul-cast-del-foreach.aspx <p>Nel suo post di ieri, "<a href="http://blogs.ugidotnet.org/luKa/archive/2009/01/13/foreach-linsidioso.aspx">foreach l'insidioso</a>", Luca si e' chiesto come mai il seguente snippet:</p> <p><strong>using</strong> System.Collections.Generic;<br /> <br /> <strong>interface</strong> IPersistent { }<br /> <strong>class</strong> Invoice : IPersistent { }<br /> <strong>class</strong> Order : IPersistent { }<br /> <br /> <strong>class</strong> Program {<br />     <strong>static void</strong> Main() {<br />         List&lt;IPersistent&gt; changedDocuments = <strong>new</strong> List&lt;IPersistent&gt;();<br />         changedDocuments.Add(<strong>new</strong> Invoice());<br />         changedDocuments.Add(<strong>new</strong> Order());<br />         <strong>foreach</strong> (Invoice changedInvoice <strong>in</strong> changedDocuments) { }<br />     }<br /> }</p> <p>compili. Secondo me, il comportamento del compilatore e' giusto, voluto e documentato. Le specifiche del linguaggio (<strong>15.8.4</strong>, <a href="http://www.ecma-international.org/publications/standards/Ecma-334.htm">ECMA-334</a>), dicono:</p> <p>"A foreach statement of the form</p> <p><strong>foreach</strong>(V v <strong>in</strong> x) <em>embedded-statement</em></p> <p>is then expanded to:</p> <p>{<br />     E e = ((C)(x)).GetEnumerator();<br />     <strong>try</strong> {<br />         V v;<br />         <strong>while</strong> (e.MoveNext()) {<br />             v = (V)(T)e.Current;<br />             <em>embedded-statement</em><br />         }<br />     }<br />     <strong>finally</strong> {<br />         … // Dispose e<br />     }<br /> }</p> <p>The variable e is not visible to or accessible to the expression x or the embedded statement or any other source code of the program. The variable v is read-only in the embedded statement. <font color="#ff0000"><strong>If there is not an explicit conversion from T (the element type) to V (the type in the foreach statement), an error is produced and no further steps are taken</strong>.</font>"</p> <p>Quindi e' la responsabilita' del programmatore quella di assicurarsi che il cast sia valido. Potremmo volere per esempio fare un <em>foreach</em> su tutte le <em>Label</em> nella <em>ControlCollection</em> dei <em>Controls</em> di una <em>Form</em> - sara' il nostro compito quello di "filtrare" gli elementi di tipo <em>Label</em> e fare il <em>foreach</em> soltanto su questi, oppure assicurarsi che nella <em>Controls</em> ci sono solo <em>Label</em>. Perche' il compilatore non ci aiuta? Probabilmente perche' la lista potrebbe essere costruita anche altrove!</p> <p>In ogni caso, se cerchiamo un aiuto da parte dell'intellisense e del compilatore, possiamo sostituire il <em>foreach</em> nello snippet di Luca, con:</p> <p>changedDocuments.ForEach(<strong>delegate</strong>(IPersistent persistent) { });</p> <p>Sorprendemente, otteniamo anche un codice IL piu' piccolo rispetto alla variante con <em>foreach</em>. Il type parameter dell'argomento action del metodo <em>ForEach</em>, e' vincolato ora ad essere identico al type parameter della nostra <em>List</em>, cioe' <em>IPersistent</em>.</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/95195.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2009/01/14/sul-cast-del-foreach.aspx Wed, 14 Jan 2009 11:11:13 GMT http://blogs.ugidotnet.org/adrian/archive/2009/01/14/sul-cast-del-foreach.aspx#feedback 96 http://blogs.ugidotnet.org/adrian/comments/commentRss/95195.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/95195.aspx Quando C# e' piuttosto l'eccezione che la regola http://blogs.ugidotnet.org/adrian/archive/2008/11/10/quando-c-e-piuttosto-leccezione-che-la-regola.aspx <p>Il comportamento del compilatore C#, presentato prima <a href="http://blogs.ugidotnet.org/WamBlog/archive/2008/11/01/c-uno-strano-comportamento-con-loverride.aspx">qui</a> da Diego e poi nel mio <a href="http://blogs.ugidotnet.org/adrian/archive/2008/11/09/quiz-sharp-71-overrideoverload.aspx">post precedente</a>, sembra singolare tra gli altri compilatori piu' conosciuti .NET. Il seguente snippet C# entra in stack overflow:</p> <p><strong>using</strong> System;<br /> <br /> <strong>class</strong> Foo {<br />     <strong>public virtual void</strong> Write(<strong>string</strong> s) {<br />         Console.WriteLine("Foo virtual " + s);<br />     }<br /> }<br /> <br /> <strong>class</strong> Bar : Foo {<br />     <strong>public override void</strong> Write(<strong>string</strong> s) {<br />         Console.WriteLine("Bar override " + s);<br />     }<br /> <br />     <strong>public void</strong> Write(<strong>string</strong> s, <strong>params string</strong>[] args) {<br />         Write("Bar overload " + s);<br />     }<br /> }<br /> <br /> <strong>class</strong> Program {<br />     <strong>static void</strong> Main() {<br />         Bar bar = <strong>new</strong> Bar();<br />         bar.Write("Ciao!"); // <font color="#ff0000">Process is terminated due to StackOverflowException</font><br />     }<br /> }</p> <p>mentre per gli altri linguaggi, stampa <em>Bar override Ciao!</em> Di seguito il codice equivalente in Visual Basic .NET, C++/CLI e Visual J#</p> <p><strong>Imports</strong> System<br /> <br /> <strong>Class</strong> Foo<br />     <strong>Public Overridable Sub</strong> Write(<strong>ByVal</strong> s <strong>As String</strong>)<br />         Console.WriteLine("Foo virtual " + s)<br />     <strong>End Sub<br /> End Class<br /> <br /> Class</strong> Bar : <strong>Inherits</strong> Foo<br />     <strong>Public Overrides Sub</strong> Write(<strong>ByVal</strong> s <strong>As String</strong>)<br />         Console.WriteLine("Bar override " + s)<br />     <strong>End Sub<br /> <br />     Public Overloads Sub</strong> Write(<strong>ByVal</strong> s <strong>As String</strong>, <strong>ParamArray</strong> args <strong>As String</strong>())<br />         Write("Bar overload " + s)<br />     <strong>End Sub<br /> End Class<br /> <br /> Module</strong> Program<br />     <strong>Sub</strong> Main<br />         <strong>Dim</strong> bar <strong>As</strong> Bar = <strong>New</strong> Bar<br />         bar.Write("Ciao") ' stampa <font color="#ff0000">Bar override Ciao!</font><br />     <strong>End Sub<br /> End Module</strong></p> <p><strong>using namespace</strong> System;<br /> <br /> <strong>ref class</strong> Foo {<br />     <strong>public</strong>:<br />     <strong>virtual void</strong> Write(String^ s) {<br />         Console::WriteLine("Foo virtual " + s);<br />     }<br /> };<br /> <br /> <strong>ref class</strong> Bar : Foo {<br />     <strong>public</strong>:<br />     <strong>virtual void</strong> Write(String^ s) <strong>override</strong> {<br />         Console::WriteLine("Bar override " + s);<br />     }<br /> <br />     <strong>void</strong> Write(String^ s, ... <strong>array</strong>&lt;String^&gt;^ args) {<br />         Write("Bar overload " + s);<br />     }<br /> };<br /> <br /> <strong>int</strong> main() {<br />     Bar^ bar = <strong>gcnew</strong> Bar;<br />     bar-&gt;Write("Ciao!"); // stampa <font color="#ff0000">Bar override Ciao!</font><br /> };</p> <p><strong>import</strong> System.*;<br /> <br /> <strong>class</strong> Foo {<br />     <strong>public void</strong> Write(String s) {<br />         Console.WriteLine("Foo virtual " + s);<br />     }<br /> }<br /> <br /> <strong>class</strong> Bar <strong>extends</strong> Foo {<br />     <strong>public void</strong> Write(String s) {<br />         Console.WriteLine("Bar override " + s);<br />     }<br />     <strong>public void</strong> Write(String s, /** @attribute ParamArray() */ String[] args) {<br />         Write("Bar overload " + s);<br />     }<br /> }<br /> <br /> <strong>class</strong> Program {<br />     <strong>public static void</strong> main(String[] args) {<br />         Bar bar = <strong>new</strong> Bar();<br />         bar.Write("Ciao"); // stampa <font color="#ff0000">Bar override Ciao!</font><br />     }<br /> }</p> <p>Ho sempre considerato C# come linguaggio "centrale" di .NET, una chiave per capire meglio lo spirito della piattaforma - percio' mi meraviglio quando trovo comportamenti in C# che sono piuttosto l'eccezione anziche' la regola rispetto agli altri linguaggi .NET. A voi quale comportamento sembra piu' corretto/intuitivo?</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/94595.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/11/10/quando-c-e-piuttosto-leccezione-che-la-regola.aspx Mon, 10 Nov 2008 23:46:00 GMT http://blogs.ugidotnet.org/adrian/archive/2008/11/10/quando-c-e-piuttosto-leccezione-che-la-regola.aspx#feedback 225 http://blogs.ugidotnet.org/adrian/comments/commentRss/94595.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/94595.aspx Quiz Sharp #71 [override/overload] http://blogs.ugidotnet.org/adrian/archive/2008/11/09/quiz-sharp-71-overrideoverload.aspx <p><a href="http://blogs.ugidotnet.org/WamBlog/archive/2008/11/01/c-uno-strano-comportamento-con-loverride.aspx">Questo post</a> di Diego Martelli, fattomi notare da un amico, riesce secondo me a sorprendere un comportamento interessante di C#, ovvero il seguente snippet di codice entra in <em>stack overflow</em>:</p> <p><strong>using</strong> System;<br /> <br /> <strong>class</strong> Foo {<br />     <strong>public virtual void</strong> Write(<strong>string</strong> s) {<br />         Console.WriteLine("Foo virtual " + s);<br />     }<br /> }<br /> <br /> <strong>class</strong> Bar : Foo {<br />     <strong>public override void</strong> Write(<strong>string</strong> s) {<br />         Console.WriteLine("Bar override " + s);<br />     }<br /> <br />     <strong>public void</strong> Write(<strong>string</strong> s, <strong>params string</strong>[] args) {<br />         Write("Bar overload " + s);<br />     }<br /> }<br /> <br /> <strong>class</strong> Program {<br />     <strong>static void</strong> Main() {<br />         Bar bar = <strong>new</strong> Bar();<br />         bar.Write("Ciao!");<br />     }<br /> } </p> <p>Probabilmente molti si aspetterebbero che venisse stampato "<strong>Bar override Ciao!</strong>" a console e invece il metodo chiamato e' il <em>Write</em> con l'elenco variabile di parametri e non il metodo in override. Questo comportamento e' dovuto, secondo me, al fatto che abbiamo istanziato <em>bar</em> come:</p> <p>Bar bar = <strong>new</strong> Bar();</p> <p>e non come:</p> <p>Foo bar = <strong>new</strong> Bar();</p> <p>Il metodo <em>Write</em> in override nella classe <em>Bar</em> non fa altro che <em>specializzare</em> il metodo virtuale della classe base <em>Foo</em>, percio' perde nella gara dei metodi in overload della classe <em>Bar</em> perche' <em>Write</em> nella sua <em>forma espansa</em> (ECMA-334, 14.4.2.1) ha un parametro di tipo string e zero elementi nell'array di parametri.</p> <p>Detto questo, ecco il mio quiz: Cosa stampa questo snippet a console?</p> <p><strong>using</strong> System;<br /> <br /> <strong>class</strong> Foo {<br />     <strong>public override string</strong> ToString() {<br />         <strong>return</strong> "override ";<br />     }<br />     <strong>public string</strong> ToString(<strong>params string</strong>[] args) {<br />         <strong>return</strong> "overload ";<br />     }<br /> }<br /> <br /> <strong>class</strong> Program {<br />     <strong>static void</strong> Main() {<br />         Foo foo = <strong>new</strong> Foo();<br />         Console.Write(foo);<br />         Console.WriteLine(foo.ToString());<br />     }<br /> }</p> <p> </p> <ul> <li><strong>A</strong>: override override </li> <li><strong>B</strong>: override overload </li> <li><strong>C</strong>: overload overload </li> </ul> <p> </p> <p>:-)</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/94564.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/11/09/quiz-sharp-71-overrideoverload.aspx Sun, 09 Nov 2008 11:14:21 GMT http://blogs.ugidotnet.org/adrian/archive/2008/11/09/quiz-sharp-71-overrideoverload.aspx#feedback 311 http://blogs.ugidotnet.org/adrian/comments/commentRss/94564.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/94564.aspx IDisposable e le partial class http://blogs.ugidotnet.org/adrian/archive/2008/10/02/idisposable-e-le-partial-class.aspx <p>Oggi, parlando con il mio collega <a href="http://danielseverin.blogspot.com/">Daniel</a>, e' uscita fuori una situazione interessante. Supponiamo che avete un tool che vi genera una classe partial che implementa IDisposable:</p> <pre>using System; <strong>partial class</strong> Foo : IDisposable { <strong>public void</strong> Dispose() { Console.WriteLine("implicit"); } }</pre> <p>Se volete cambiare il comportamento del Dispose senza toccare il codice generato sopra, basta implementare esplicitamente l'interfaccia IDisposable:</p> <pre><strong>using</strong> System; <strong>partial class</strong> Foo { <strong>void</strong> IDisposable.Dispose() { Console.WriteLine("explicit"); } }</pre> <p>A questo punto uno using(Foo foo = new Foo()){} stampera' <strong>explicit</strong> a console, anziche' <strong>implicit</strong>.</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/94230.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/10/02/idisposable-e-le-partial-class.aspx Thu, 02 Oct 2008 03:23:15 GMT http://blogs.ugidotnet.org/adrian/archive/2008/10/02/idisposable-e-le-partial-class.aspx#feedback 116 http://blogs.ugidotnet.org/adrian/comments/commentRss/94230.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/94230.aspx End tag required for HTML SCRIPT element http://blogs.ugidotnet.org/adrian/archive/2008/07/14/end-tag-required-for-html-script-element.aspx <p>Magari lo sanno tutti ma io ci ho perso mezz'ora per capire dove sta l'errore:</p> <p>&lt;script type="text/javascript" src="foo.js"<strong><font color="#ff0000">&gt;&lt;/script&gt;</font></strong></p> <p>e</p> <p>&lt;script type="text/javascript" src="foo.js" <strong><font color="#ff0000">/&gt;</font></strong></p> <p>non sono uguali! <em>Su IE il tag esplicito di chiusura</em> (la prima variante) <em>e' obbligatorio</em>, mentre Firefox accetta tutte e due le varianti...</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/93398.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/07/14/end-tag-required-for-html-script-element.aspx Mon, 14 Jul 2008 03:23:53 GMT http://blogs.ugidotnet.org/adrian/archive/2008/07/14/end-tag-required-for-html-script-element.aspx#feedback 49 http://blogs.ugidotnet.org/adrian/comments/commentRss/93398.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/93398.aspx Best practice Path.Combine http://blogs.ugidotnet.org/adrian/archive/2008/05/04/best-practice-path.combine.aspx <p>Se vogliamo che il nostro codice giri anche su Mono, dobbiamo utilizzare:</p> <p>Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "aaa.bbb")</p> <p>al posto di:</p> <p>AppDomain.CurrentDomain.BaseDirectory + "aaa.bbb"</p> <p>perche' su Mono, <em>BaseDirectory</em> ritorna una stringa che non finisce in <em>Path.DirectorySeparatorChar</em>, mentre su CLR si'. E questo va anche in generale, quando costruiamo il path da piu' pezzi, non solo nel caso della <em>BaseDirectory</em>. Per esempio, chi utilizza <a href="http://www.fyireporting.com/">fyiReporting RDL Project</a> su Mono, dovrebbe modificare la riga 81 nel file Runtime/RdlEngineConfig.cs nei sorgenti del progetto e ricompilare, da:</p> <p>file = dir + "RdlEngineConfig.xml";</p> <p>a:</p> <p>file = Path.Combine(dir, "RdlEngineConfig.xml");</p> <p>perche' la stringa <em>dir</em>, per come e' stata costruita, su CLR finisce in <em>Path.DirectorySeparatorChar</em>, mentre su Mono no. In <a href="http://www.amazon.com/Framework-Standard-Library-Annotated-Reference/dp/0321154894/">SLAR 1</a> alla pagina 360, <a href="http://joelmarcey.com/">Joel Marcey</a> aggiunge questa nota sulla storia del metodo <em>Combine</em>:</p> <blockquote><em>The</em> Combine <em>method had an interesting ride in the standardization process. It was originally part of the </em>Path <em>class, then removed because it was thought to be too platform-specific, then added back because it was decided it was not any more platform-specific than any of the other methods in this class.</em></blockquote><img src="http://blogs.ugidotnet.org/adrian/aggbug/92512.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/05/04/best-practice-path.combine.aspx Sun, 04 May 2008 22:44:32 GMT http://blogs.ugidotnet.org/adrian/archive/2008/05/04/best-practice-path.combine.aspx#feedback 95 http://blogs.ugidotnet.org/adrian/comments/commentRss/92512.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/92512.aspx Un'API generico a provider per i metadata dei vari ORM http://blogs.ugidotnet.org/adrian/archive/2008/05/03/unapi-generico-a-provider-per-i-metadata-dei-vari-orm.aspx <p>Via <a href="http://weblogs.asp.net/fbouma/archive/2008/05/01/dynamic-data-and-3rd-party-o-r-mappers-is-a-fact.aspx">questo post</a> di <a href="http://weblogs.asp.net/fbouma/">Frans Bouma</a> ho scoperto sotto il namespace <strong>System.Web.DynamicData.ModelProviders</strong> dell'assembly <strong>System.Web.DynamicData.dll</strong> che arriva con l'ultima release della preview di <a href="http://code.msdn.microsoft.com/dynamicdata">ASP.NET Dynamic Data</a>, un'API generico composto da 4 provider per i metadata dei vari ORM (non solo Microsoft): <strong>DataModelProvider</strong>, <strong>TableProvider</strong>, <strong>ColumnProvider</strong> ed <strong>AssociationProvider</strong>. Questo unifica in buona misura le varie API che espongono i metadata degli ORM, per esempio <strong>MetaTable</strong>, <strong>MetaDataMember</strong>, <strong>MetaAssociation</strong> nel caso di LINQ to SQL, oppure quella piu' complessa dell'Entity Framework: <strong>EntitySet</strong>, <strong>EdmMember</strong>, <strong>NavigationProperty</strong>, etc. Frans ha gia' scritto un <em>model provider</em> per il suo <a href="http://www.llblgen.com/">LLBLGen Pro</a>, sarebbe bellissimo averne uno anche per <a href="http://www.nhibernate.org/">NHibernate</a>. E poi mi piacerebbe in futuro vedere questa API staccata dal ASP.NET Dynamics Data con cui non dovrebbe avere tanto in comune.</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/92497.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/05/03/unapi-generico-a-provider-per-i-metadata-dei-vari-orm.aspx Sat, 03 May 2008 02:53:11 GMT http://blogs.ugidotnet.org/adrian/archive/2008/05/03/unapi-generico-a-provider-per-i-metadata-dei-vari-orm.aspx#feedback 104 http://blogs.ugidotnet.org/adrian/comments/commentRss/92497.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/92497.aspx Brian Grunkemeyer sulla storia del TypeCode e dell'interfaccia IConvertible http://blogs.ugidotnet.org/adrian/archive/2008/03/17/91755.aspx <p>Visto l'interesse che ha suscitato <a href="http://blogs.ugidotnet.org/adrian/archive/2008/03/12/91669.aspx">l'ultimo post</a>, ho scritto a <a href="http://blogs.msdn.com/brada">Brad Abrams</a> chiedendo conferma per la mia supposizione e dettagli sulla storia dell'interfaccia IValue, lui mi risponde subito indirizzandomi a <a href="http://blogs.msdn.com/bclteam/">Brian Grunkemeyer</a> e stamattina trovo nella mia casella email, scritto da Brian, questo splendido pezzo della storia di .NET:</p> <blockquote> <p>This is a good question. I was digging through the history of this file to see if I could figure out what happened, and it’s not clear. We’ve had this “hole” in the TypeCode enum since October of 2000, and I can’t find an older set of bits. But, I’m sure that comment in IConvertible is right – this used to be TimeSpan. For TimeSpan, it’s possible we thought it would be interesting for a while, then we realized that frankly not that many people need to convert a Decimal to a TimeSpan, then removed it.</p> <p>You might ask why we didn’t “fix” the enum when we removed whichever of these values we had originally added. It turns out that whenever we have a breaking change internally, we need to recompile all the code that might possibly depend on the removed or changed public surface area. For us, that would mean rebuilding everything that might have referred to TypeCode.String, whose value would have changed from 18 to 17. While we do go through that process internally in DevDiv, it is costly &amp; painful for us. Back then with some underdeveloped internal processes, it usually took 2 weeks, then even longer if your change requires a rebuilt compiler to be checked in as a new “safe” build of a compiler. Back in 2000, we were racing to ship as soon as possible (even though we didn’t ship for another year or two), so we wanted to limit churn like this. It’s sometimes easier to not deal with that level of churn in the product.</p> <p>For your other question about IValue, that was the original name for IConvertible. We exposed a Variant type to match OLE Automation’s VARIANT type on the native side, for COM Interop reasons. The VB team actually was thinking that Variant should be conceptually the root of their object hierarchy (at least in terms of how types were exposed in VB 7), but that seemed a little silly. Fortunately, Anders Hejlsberg convinced them to use Object instead and we’d expose IConvertible on the base data types to allow VB users to easily change from one data type to another. So we marked Variant internal &amp; we only use it in a handful of places internally for COM-related functionality.</p> </blockquote><p>Grazie ragazzi!</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/91755.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/03/17/91755.aspx Mon, 17 Mar 2008 19:24:33 GMT http://blogs.ugidotnet.org/adrian/archive/2008/03/17/91755.aspx#feedback 165 http://blogs.ugidotnet.org/adrian/comments/commentRss/91755.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/91755.aspx Sull'enum TypeCode e sull'interfaccia fantoma IValue http://blogs.ugidotnet.org/adrian/archive/2008/03/12/91669.aspx <p>Oggi <a href="http://blogs.ugidotnet.org/raffaele/">Raf</a> sul messenger mi chiede se conosco un modo piu' diretto per capire se un tipo sia <a href="http://msdn2.microsoft.com/en-us/library/system.type.isprimitive.aspx">primitivo</a> oppure <strong>String</strong> o <strong>DateTime</strong> (questo per evitare degli <em>if</em>...). Pensandoci un po', arrivo a questa soluzione:</p> <p><strong>(int)Type.GetTypeCode(type) &gt; 2</strong></p> <p>dove <em>type</em> e' il tipo in causa. Lui prova e mi dice che va benissimo mentre io gia' sto pensando di bloggare questa riga di codice :-) L'enum <a href="http://msdn2.microsoft.com/en-us/library/system.typecode.aspx">TypeCode</a> infatti, contiene nella sua lista di valori maggiori a 2 tutti i 12 tipi <strong>primitivi</strong> piu' il <strong>DateTime</strong> e lo <strong>String</strong>, proprio quello che voleva Raf. A questo punto gli chiedo come denominare questa categoria di tipi? Primitivi non sono, <em>built-in</em> (<a href="http://www.ecma-international.org/publications/standards/Ecma-335.htm">ECMA-335</a>, <strong>Partition I</strong>, <strong>8.2.2</strong>) nemmeno, boh... <em>fondamentali</em>? Qui Raf si ricorda che "<em>in una alpha erano refclass adesso non piu'</em>". E poi fa questa osservazione giusta:</p> <p><strong>Raffaele MVP says (4:45 PM):</strong><br /> io comunque metterei &gt;2 e &lt;18<br /> non si sa mai che aggiungano altre enum in futuro<br /> <strong>&lt;drian says (4:46 PM):</strong><br /> hai visto che manca 17?<br /> <strong>Raffaele MVP says (4:46 PM):</strong><br /> non ci ho fatto caso<br /> <strong>&lt;drian says (4:47 PM):</strong><br /> in questo caso, dovrei fare anche != 17, perche' il 17 per adesso manca<br /> e diventa un po' una schifezza<br /> <strong>Raffaele MVP says (4:48 PM):</strong><br /> a questo punto puoi legarlo ad una versione specifica di quell'assembly ma poi non funziona più automaticamente<br /> <strong>Raffaele MVP says (4:49 PM):</strong><br /> o ancora metterlo typesafe<br /> &gt;=boolean &lt;=string<br /> ma c'è sempre il 17 a rompere </p> <p>Spulciando poi i sorgenti di <a href="http://msdn.microsoft.com/net/sscli/">Rotor</a>, trovo questo commento nel file dell'interfaccia <strong>System.IConvertible</strong></p> <p><font color="#339966">// The IValue interface represents an object that contains a value. This<br /> // interface is implemented by the following types in the System namespace:<br /> // <strong>Boolean</strong>, <strong>Char</strong>, <strong>SByte</strong>, <strong>Byte</strong>, <strong>Int16</strong>, <strong>UInt16</strong>, <strong>Int32</strong>, <strong>UInt32</strong>, <strong>Int64</strong>, <strong>UInt64</strong>,<br /> // <strong>Single</strong>, <strong>Double</strong>, <strong>Decimal</strong>, <strong>DateTime</strong>, <font color="#ff0000"><strong>TimeSpan</strong></font>, and <strong>String</strong>. The interface may<br /> // be implemented by other types that are to be considered values.</font> </p> <p>Cosa notate? Esattamente l'elenco di tipi che interessava Raf, nell'ordine di <strong>TypeCode</strong> e... in piu' il <strong><font color="#ff0000">TimeSpan</font></strong> tra il <strong>DateTime</strong> = 16 e lo <strong>String</strong> = 18, cioe' corrispondente proprio al <strong><font color="#ff0000">17</font></strong> che mancava! Questa interfaccia, <strong>IValue</strong>, non esiste piu' nel framework ma alcuni commenti su varie implementazioni del metodo <strong>GetTypeCode()</strong> sono rimasti come:</p> <p><font color="#339966">// IValue implementation</font></p> <p>perche', probabilmente, conteneva questo metodo <strong>GetTypeCode</strong>. Questa ormai e' "<em>archeologia</em>" di .NET! :-) E non e' tutto. Guardate nei commenti dell'enum <strong>System.TypeCode</strong>:</p> <p><font color="#339966">// Note that when an object has a given TypeCode, there is no guarantee that<br /> // the object is an instance of the corresponding System.XXX value class. For<br /> // example, <strong>an object with the type code TypeCode.Int32 might actually be an</strong><br /> // <strong>instance of a nullable 32-bit integer type</strong></font> </p> <p>Questo comportamento non e' piu' vero, perche' il valore di <strong>Type.GetTypeCode(typeof(<font color="#ff0000">int?</font>))</strong> e' <strong>TypeCode.<font color="#ff0000">Object</font></strong>, mentre il valore di <strong>Type.GetTypeCode(typeof(int))</strong> e' <strong>TypeCode.Int32</strong>!</p> <p>Dopo una discussione tecnica con Raf, direi che sia impossibile non cliccare "<strong>New Post</strong>"! :-)</p><img src="http://blogs.ugidotnet.org/adrian/aggbug/91669.aspx" width="1" height="1" /> Adrian Florea http://blogs.ugidotnet.org/adrian/archive/2008/03/12/91669.aspx Wed, 12 Mar 2008 06:49:00 GMT http://blogs.ugidotnet.org/adrian/archive/2008/03/12/91669.aspx#feedback 113 http://blogs.ugidotnet.org/adrian/comments/commentRss/91669.aspx http://blogs.ugidotnet.org/adrian/services/trackbacks/91669.aspx