Struct method call

Topics: Metadata Model
Jan 8, 2011 at 10:53 PM


Is there any code model that embeds the peculiarities of the call to struct methods?

Currently I'm handling them in my factory methods but since their effect still tend to "spread around" a little too much I was creating a new implementation of IMethodCall. I wondered if there is a place in CCI where they are handled.


Jan 9, 2011 at 12:28 AM
Edited Jan 9, 2011 at 1:17 AM

I suspect this is handled in your AST layer, for example in methods like Ast.MethodCall::GetThisArgument(). Is this correct?

For some reason (that honestly I cannot recall, I should walk again the same path - or maybe I should start writing notes about what I do) I decided in past to not use your AST layer. This is not an irrevocable choice, I already rethinked my "compiler" several times as I improved my understanding of language programming, CCI and what I'm doing.

Can I ask you why do you handle that kind of detail at the level of AST? Do you think it's the "natural" place or it just happened that it was ok with the people using/developing CCI to handle them in that layer?

Don't you think that there is something missing in the code model? Like an expression IThisArgument? It should have a similar role of expressions such as ITargetExpression or IBoundExpression and should not be confused with IThisReference which is a possible value for IThisArgument (just like an IParameterDefinition is a possible value for an IBoundExpression).

This doesn't seem totally improper to me since, unlike the metadata model that mirrors very strictly the raw metadata items, the code model is already a level of abstraction higher than the plain IL code. 


Data:	"Raw" Metadata Items			Metadata Model	(nothing)	\
				CCI world ->					 \
									 	  > Ast Model
				<-- .NET world					 /
Code:	"Raw" IL Operations			IL Operations	Code Model	/

Using CCI as client you manipulate metadata objects but probably most of the times you don't manipulate code as IL operations, even when you don't use the Ast layer and that's because you have an additional abstraction layer. I care about IL operations only in diagnostics displays, for example.

I'm using CCI for both metaprogramming and language programming and while I had to think if I needed the AST layer while doing language programming I never felt the need to use Metadata-AST for metaprogramming before today.  

I hope I managed to explain myself.


Jan 9, 2011 at 4:05 AM

For some reason I always considered metadata model + code model apart from the AST model, while you package the code model with the AST model in "CCI Code".


Jan 9, 2011 at 4:21 AM

I guess this mean that you mixed two sets of features in your AST layer that are naturally mixed for you but are not naturally mixed for me.

Probably the better solution is to add a layer on top of the metadata and the code models that is different from your AST layer even if partially duplicates some feature.


Jan 9, 2011 at 9:38 PM

It may well be that an additional layer will be useful in some contexts, but I have no immediate plans to go that way.

Just a quick note on the design of the CodeModel: The idea is to preserve the semantics of IL as closely as possible, while providing a tree-like structure vs. a linear list of opcodes manipulating an explicit operand stack. Consequently a method call presents itself as a structured object, but does NOT abstract over any details that need to be present in IL. So, if in IL you need to put a managed pointer onto the operand stack as the this argument of a virtual method of a value type, then the CodeModel likewise requires you to provide the IMethodCall object with a this argument that results in a managed pointer.

The AST layer on the other hand, has the explicit goal of making itself constructable from a parser that has ONLY syntactic knowledge. All of the semantic knowlege that is necessary to turn "" into an IMethodCall expression is built into the AST node created by the parser. The parser need not figure out that "ob" binds to a memory locaiton whose type is a value type and that "foo" is a method defined by the value type. This is necessarily language specific, although much of it can be expressed in general base classes that allow subclasses to override and parameterize their behavior.

Jan 11, 2011 at 2:07 AM
Edited Jan 11, 2011 at 2:09 AM

Thanks for the explanation. It was very helpful.

I wasn't proposing that you add another layer in CCI . I understand that it would have a major impact on lots of client code. But I'm going to work with an additional layer (on top of what you call "code model" and alternative to your AST layer) that - at least for me - will work equally well for metaprogramming and for my "compiler". 

Thanks again.