{RE: [Mono-list] Recent Windows.Forms commit

[Piers Haken]

Surely private namespaces should start with "Mono." to avoid future
collisions. In most cases I don't think they're necessary.

I think it's okay to use internal nested types, eg:

namespace System.Text.RegulareExpressions
{
	class RegexCollectionBase
	{
		private class Enumerator
		{
		}
	}
}

Also, (almost) all items that are not exposed by MS should be either
'private' or 'internal'. The class-status pages show these items with a
green cross. Notable exceptions to this rule are things like
'System.PlatformID.unix'.

When Miguel next updates the class-status pages, you'll be able to
SHIFT-click on the 'extra' checkbox in the legend to show only those
items. Doing this currently will unfortunately hide non-leaf items that
are 'extra', due to a bug I just fixed.

I've already gone through the corlib and System assemblies fixing most
of the cases where items defined by both MS & Mono have the wrong
accessibility or modifiers (sealed, virtual, abstract, etc...)

BTW: There's currently a bug in corcompare where nested types appear on
the same level as regular classes and are shown as 'extra', so please
ignore these.

If you want to build the class-status pages on your machine to check
your code before committing, all you need to do is run make in
'mcs/tools' (to build corcompare.exe) and then in 'mono/doc/web' (to
update the status), the pages are placed in 'mono/doc/web/deploy'.

Piers.

-----Original Message-----
From: John Barnette [mailto:jbarn@httcb.net] 
Sent: Wednesday, April 03, 2002 12:44 PM
To: Dan Lewis
Cc: mono-list@ximian.com
Subject: Re: [Mono-list] Recent Windows.Forms commit


At 01:18 PM 4/3/2002, Dan Lewis wrote:
>  --- John Barnette <jbarn@httcb.net> wrote: >
> > 1. The standard operating procedure for directory structure is
> >     "class/[assembly]/[namespace]", so source files should actually
live in
> >     "class/System.Windows.Forms/System.Windows.Forms".  I know it 
> > looks
> odd,
> >     but consistency is a Good Thing (TM).
> >
> > 2. Please break out each enum in enums.cs into a separate source
file.
> >     while the enums are quite small, having public types in separate
> >     files is another standard operating procedure.  So, the 
> > following
> should
> >     be created in 
> > mcs/class/System.Windows.Forms/System.Windows.Forms:
>
>Hmm, I need to break up the RegularExpressions namespace too. But on 
>top
>of the
>public classes I've also got about 40 internal classes, and a private 
>namespace
>RegularExpressions.Syntax (some of the syntax tree names clashed with
the
>public names). Any idea what to do with these? Can I just leave them in
their
>own files?

Yo Rx,

If I were you, I'd move each type into a separate file, regardless of 
visibility.  I'd also create directories under the assembly for any
private 
namespaces.

When it comes to private implementation details like this, it really
seems 
like a matter of author opinion, so I fully expect you ignore my 
suggestions. ;-)


~ j.


_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list