To dot the i's and cross the t's: * In IL Assembler, type (class, value type, interface) declaration might be split into unlimited number of segments. * Each segment follows the type declaration syntax as defined in the ECMA spec. ECMA spec defines the syntax of type declaration, but says nothing whether the type has to be declared lexically contiguously, in one place, or not. * All these segments taken together represent a full type declaration. * The segments can be spread over one or more source files, as long as these files are compilands of the same module. * The summary definition of the type depends on the lexical order of the type declaration segments; swapping the segments might result in different type layout. * The type flags, "extends" clause and "implements" clause are ignored for all type declaration segments except the lexically first one.
Thanks, Serge -----Original Message----- From: James Michael DuPont [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 12:41 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] Augmented classes and ILASM Serge, Thanks again for your example, yes I have read about the one in your book, a clever example that you gave with the compiled code + manual il . This is one of my interests in ilasm in general, because I would like to try some of that. Then if I may summarize : Augmentation is not part of the ECMA standard, but can be used as a non-standard extension to it. The standard does not cover the amount of times a class may occur in a file, just the syntax of a class once found? Please excuse my ignorance. mike --- Serge Lidin <[EMAIL PROTECTED]> wrote: > I'm sorry I wasn't clear enough -- no, the class augmentation > capability isn't going anywhere, it's a very useful feature and it > will stay. What will go away, is the need for forward class > declaration in IL Assembler. The backward compatibility will not be > affected: the source with forward class declaration will compile just > fine, as well as without the forward class declaration. > > I don't know about any specific scenario of compilation to IL > Assembler that would require class augmentation. However, there are > so many different languages and even more ways to implement a > compiler, so I wouldn't be surprised if such scenarios existed. > > A typical example of class augmentation: Suppose, you need your > assembly to do some things you can only describe in IL Assembler, but > you have neither time nor ambition to write the whole assembly in > ILAsm. So you write most of your assembly in, say, C#, except the > pieces that you can't express in C#. These pieces you write in ILAsm, > in a separate file. Then you compile C# source, disassemble the > "incomplete" DLL into an ILAsm file, and re-assemble both ILAsm files > into new, "complete" DLL. > > As to your other question: no, class augmentation doesn't work across > assemblies. You can't take a class from another assembly and augment > it in your assembly. Instead, if you want to extend an "alien" class, > you'll have to derive your own class from it. More than that, the > class augmentation doesn't even work across modules within the same > assembly. Class augmentation is a purely linguistical feature of the > IL Assembler, it's not a metadata feature (such as class extension or > interface implementation). > > I don't think class augmentation across the module boundaries can be > implemented in principle: if you have half of class Foo declared in > module A.dll and another half -- in B.dll, then what will be the > resolution scope of Foo type reference? And what will the Loader do > while loading A.dll? Lay out one half of Foo and be done with it? > > Thanks, > Serge > > > -----Original Message----- > From: James Michael DuPont [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 13, 2003 10:22 AM > To: Serge Lidin; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Augmented classes and ILASM > > > 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 ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
