CLR, CLS, CLI e il mondo reale

Un post di Pierre (e la relativa conversazione via Messenger con lui) mi riportano ad una riflessione iniziata molto tempo addietro quando mi chiesi, per esempio, perchè VB .NET (a differenza dei suoi predecessori) non permetta di specificare differenti access modifier per i metodi getter e setter della stessa proprietà. Oppure, perchè i tipi interi a 16, 32 e 64bit unsigned non siano inclusi nelle Common Language Specifications, mentre per il byte vale esattamente l'opposto. C'è una logica (mi chiesi) che lega queste caratteristiche? Prima che pensiate che io sia impazzito, specifico che mi posi queste domande in fase di preparazione della sessione ".NET Base Class Library" che tenni l'anno scorso presso WPC.
Eric Gunnerson, in una intervista (aprite il link e cercate "getter"), ammise che il Dev Team sta pensando di introdurre una delle caratteristiche citate (access modifier differenti per getter e setter).
Un altro esempio: vi siete mai chiesti perchè il CLR permette overloading di funzioni membro che sono distinte dal tipo del valore di ritorno, e non solo dalla signature in senso stretto? Un'affermazione interessante in tal senso fu effettuata da Jim Hogg (PM del CLR) che, in un post sul newsgroup privato degli alpha tester di Whidbey (sorry, per ovvie ragioni non posso fornire un link diretto :-D), ha detto:

On the opening question of overloading on return type, the CLR actually
does support this.  However, none of the common languages (VB, C#, C++,
etc) allow you to make use of it -- automatic casting of return types makes
the result ambiguous.  So that route is closed.  (the only language on the
planet, I know of, that does support overload on return type is, of course,
ILasm!)

Quindi? "Quindi" è evidente che il CLR supporta molte caratteristiche non ancora sfruttate da (tutti) i linguaggi, e non esiste ancora il linguaggio perfetto. Il motivo di tutto ciò? AFAIK alcune feature sono state escluse dalle CLS (ma non dalle specifiche CLI) per poter rendere più semplice il compito di supportare il CLR mediante linguaggi già esistenti, che quindi hanno già sintassi e semantica definite e consolidate.
Il tutto, rigorosamente, IMHO :-)

posted @ venerdì 17 ottobre 2003 14:43

Print

Comments on this entry:

No comments posted yet.

Your comment:



 (will not be displayed)


 
 
Please add 6 and 1 and type the answer here:
 

Live Comment Preview:

 
«dicembre»
domlunmarmergiovensab
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234