Hey, On 8/22/07, Roei Erez <[EMAIL PROTECTED]> wrote: > When writing an assembly a user needs to build the full object model, so > I don't think there is a lot of room for improvement at this area.
Well, it's difficult, but if it's possible to read the object model from the raw bytes, it should also be possible to write it back. > I agree that cecil should expose an interface to load an assembly as > 'Read Only', where the optimizations should be activated, and by that > save the worrying of the changes to the assembly writing part. > I really like the idea that the object model will access the raw tables > directly and in lazy way. > This idea will work only if the access to the raw table will be fast, > and in order to do so, the code needs to build more relations between > these tables. > We can take the CustomAttributes table for example, each raw at this > table has the 'RID' of the owner element, and the TokenType of the > owner, and in order for a 'Field', for example, to load its > CustomAttibutes lazily, it needs that opposite relation, from its 'RID' > to its CustomAttributes, will exist. > > I basically want to suggest the following: > The methods of the ReflectionReader will be changed, and instead of > building an object model, they will only build the desired relations > between elements (Methods->Types, Fields->Constants, > Fields->InitialValues ...) And how do you plan to represent those relations? > The higher object model classes (TypeDefinition, MethodDefinition, > FieldDefinition ...), will have their properties access lazily those > built relations in order to fetch the data on first access. > My favorite solution is to write a 'ReadOnlyReflectionReader' that will > contain the above changes, and leave the current implementation as is > for writing purposes. > I think we should also consider removing the 'sealed' modifier from the > higher level object model classes (like TypeDefinition, MethodDefinition > ...), by that give the used ReflectionReader full control over the > object model implementation, building its own read-only one. Another concern I have is Cecil's size. It's already ~360k, and I'd like to avoid bloating it. > Now is a good time for us to start such a process, and I would really > want to push things forward. I'll create a branch for Cecil so we can experiment. > What do you think about the suggestion? > If you think about major issues that the above solution will encounter, > I would be happy to hear about them. I need to think more about the implications, but be sure there will be dragons :) -- Jb Evain <[EMAIL PROTECTED]> _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
