Le compilateur a effectivement accès au bytecode des autres classes... Mais je comprend pas trop comment il peut se permettre de faire des inlines comme ça... la classe qu'il référencie est toujours dans un autre assembly (.dll), et imagine que tu changes l'assembly, par exemple pour réparer un bug, ben toutes tes fonctions inlinées ne vont pas en profiter... Et c'est une situation classique en .NET d'avoir des classes dans des assemblies différentes...
Et puis les scénarios de chargement dynamique au runtime sont de plus en plus courant, ne serais-ce que pour faire une architecture de plugin, on parcourt un assembly au runtime et on créé des instances à la volée... Enfin tout ca pour dire que les cas où le compilateur peut faire son boulot trankilou il est rare...
Je me trompes peut-être complètement :)
[^] # Re: C'est un troll.
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Et puis les scénarios de chargement dynamique au runtime sont de plus en plus courant, ne serais-ce que pour faire une architecture de plugin, on parcourt un assembly au runtime et on créé des instances à la volée... Enfin tout ca pour dire que les cas où le compilateur peut faire son boulot trankilou il est rare...
Je me trompes peut-être complètement :)