Serge, Thank you for your prompt answer and good description of the situation.
Unfortunatly if I have understood you properly, that means that writing Augmented code will also be non-portable in the end. :( Surly Augmentation can be shown to be a valid technique for the separation of aspects of a program into different files, but I guess that not many people are going to be writing large IL programs by hand. Will the augmentation be feature that is only a effect of the nature of handwritten ILASM, or is it possible to write a compiled IL assembly that would dictate the need for the separation of a class? I wonder if it possible to augment a class across two different DLLS? That would allow for the seperation of the aspects of a class into multiple modules, each that would be linked into one whole. It looks to me to be an implementation detail in the ildasm/ilasm. I will have to re-read the spec. looking for a statement on the layout and location of the class metadata. I wonder if all the data about a type/classes has to be in one section. (surly this is a silly question that stems from my lack of understanding) One can then safely remove the "forwards" section of the il that is created by the rotor ilsdasm for testing interoperability with other implementations of ilasm. I had not noticed that IL is a superset of the ECMA features yet, thanks for pointing them out. I still have alot to learn about IL, but the more that I learn about, the more I am excited. You have really described the IL language in your book in a very entertaining way. It is truly a good read. The real redeeming factor about IL in my option is the amount of type information that is stored in the IL, this greatly aids in the understandibily of a give set of code. Compared to the Parrot assembler language, IL is incredibly verbose! Best regards, mike --- Serge Lidin <[EMAIL PROTECTED]> wrote: > Hi James, > > Thanks for good words about my book. > > To answer your question: The class augmentation is not mentioned in > ECMA spec, because in this spec IL Assembler is used mostly as a mean > to describe the metadata and IL. The class augmentation doesn't > change anything in this regard, so it was considered irrelevant to > the spec. > > You might also notice that actual implementation of IL Assembler is a > superset of the spec'ed features. Some features, such as TLS > constants and unmanaged exports, were deemed > "implementation-specific" and not subject to standardization. > > The necessity of forward class declaration (first declare the classes > including the nested ones, then declare them with the members) is > based on the class augmentation principle. The forward class > declaration is strongly recommended for IL Assembler v.1.0 and > v.1.1., because of some internal IL Assembler problems. In further > versions of IL Assembler, the internal handling of the class > declarations is different, so there will be no need for the forward > class declaration. > > Thanks, > Serge > > > -----Original Message----- > From: James Michael DuPont [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 3:29 AM > To: Serge Lidin; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Augmented classes and ILASM > > > Hi Serge, > > I am resending this, so that it will go to the whole list > First of all, I would like to thank you for writing such a good book, > Inside IL assembler. I have a question about the "Augmented" classes > feature : > > I cannot seem to find the area in the ECMA spec that covers the > ability > to augment classes, and reopen them. You cover it in your book, and > rotor supports it, but still, i would like to resolve exactly where > this is covered in the spec, can you advise? > > In in IL produced by Rotors ILDASM, there a number for "Forwards" > that > are declared for clases, with the pattern : > > I have opened a bug report for the dotgnu ilasm based on the il > created > by rotor : > https://savannah.gnu.org/bugs/?func=detailbug&bug_id=2196&group_id=353 > > .class private auto ansi beforefieldinit DotGNU > extends [mscorlib]System.Object > { > } // end of class DotGNU > > > // =============== CLASS MEMBERS DECLARATION =================== > // note that class flags, 'extends' and 'implements' clauses > // are provided here for information only > > .class private auto ansi beforefieldinit DotGNU > extends [mscorlib]System.Object > { > .field static assembly literal string Title = "DotGNU.Testing.dll" > > } // end of class DotGNU > > > mike > > > > ===== > James Michael DuPont > http://introspector.sourceforge.net/ > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
