[Mono-list] C# changes

[Jonathan Pryor]

Inline...

On Mon, 2002-11-11 at 10:30, Zaphod wrote:
> On Mon, Nov 11, 2002 at 10:03:50AM -0500, Jonathan Pryor wrote:
> > would be identical to the "normal" class definition:
> 
> In IL  ? .... Would it form the same syntax for IL ? ... (that would
> be just a new way for organizing type gathering code , right ?) ...
> Is that such a revolutionary change ? ... IMHO NO.

Well, I haven't used the new compiler, I've just read the presentation
slides.  I would imagine that it would generate the same IL.

Is it a revolutionary change?  No.  Does it need to be?  No.  I find it
to be an evolutionary change, and with some of the code I've seen and
tasks I can imagine doing (such as automated class generation for parts
of a class), it's a highly desirable evolutionary change.  I wish Java
had this 4 years ago.

> > The one thing I dislike about this approach is that they added a new
> > keyword.  Why didn't they use an Attribute?  Attributes are already used
> > for both custom attributes (e.g. System.Diagnostics.DebuggableAttribute)
> > and CIL attributes (e.g. Serializable, MethodImplOptions, ...).  Why not
> > have a compiler-intrinsic [Partial] attribute?  Still reasonably
> > consistent, and doesn't need a new keyword.
> 
> Because Attributes are analyzed only *after* the type gathering occurs ...
> Also attributes would make some .NET implementation complicated ... 
> For example IndexerName is an ugly context sensitive hack for names ....
> Thank God the new designers are not Attribute Crazy ...

I was thinking it would be a "pseudo-attribute", not a real attribute. 
Something that the compiler understands and would recognize during
syntax and semantic analysis, NOT something that would actually appear
in IL.
 
> AFAIK, the new keyword approach is much cleaner for compiler implementation.

Not having written a compiler yet, I can't comment.  (Though writing a
compiler should happen next semester, if that Compiler class is actually
offered...)

 - Jon