Standards

  • Thread starter Thread starter Umpa Lumpa
  • Start date Start date
U

Umpa Lumpa

Hi,

What is the status on the "standardization" (outside MS) of the BCLs?

Is everything under the System namespace going to be "standard" and
everything under the Microsoft namespace custom per MS specific and in
general Vendor.* namespaces for vendor specific classes.

Is WinForms etc planned to be part of this "standard" or will it be not
very portable and therefore should belong under the Microsoft.* namespace?

Thanks
 
You can look at ISO and ECMA in the specs what is standardized.
http://msdn.microsoft.com/net/ecma/

Mainly the CLR and the System namespace I believe.
Well, Mono is trying to get an exact behaviour in porting almost any
namespace, wo that shouldn't be a problem.

Greetz,
-- Rob.
 
My concern is WinForms etc because on MONO that is taking 2 paths, P/Invoke
to win32 (and therefore WINE dependant) and GTK# (but less compatible).
That to me indicates NON STANDARD.
 
Hi,

Umpa said:
My concern is WinForms etc because on MONO that is taking 2 paths,
P/Invoke to win32 (and therefore WINE dependant) and GTK# (but less
compatible). That to me indicates NON STANDARD.
Click to expand...

Standards are not the problem (not the only problem, anyway). There is quite
a lot of Windows Forms functionality that requires P/Invoke or WndProc
overrides to get to. These cannot be compatible with linux (they use builtin
windows dll's or procedures). This is why wine is the best way to go atm for
compatibility.

Pete
 
Wild guess -

Because the hierarchy of namespaces was put together before the decision to
submit the BCL and CLR to ECMA was finalized. I suppose they could have
chosen the typical Java solution - duplicate everything into another
namespace and deprecate it in the System namespace, while retaining it
forever for backwards compatibility.

-cd
 
So why the heck are they in teh System.* namespace and NOT the Microsoft.*
(ie., VendorSpecific.* ) namespaces?

Recipe for disaster
 
Umpa Lumpa wrote:
|| So why the heck are they in teh System.* namespace and NOT the
|| Microsoft.* (ie., VendorSpecific.* ) namespaces?
||
|| Recipe for disaster
||

Please take some time and read the standard documents. The standard defines profiles and libraries,namespace names are not part of
the standard.

Willy.
 
I suggest they change it or make it portable.



Umpa Lumpa said:
So why the heck are they in teh System.* namespace and NOT the Microsoft.*
(ie., VendorSpecific.* ) namespaces?

Recipe for disaster
Click to expand...
 
Then again what is to stop somebody implementing a method by method feature
by feature replacemetn that IS portable as System.WinForms.blah .dll?
 
Umpa said:
Then why the heck are they under the System.* namespace and not
Microsoft.*?
Click to expand...

It shouldn't matter what namespace is chosen. When using types in a program,
the type not only includes the namespace but also the name of the assembly.
This is a huge improvement over previous standards choices. Reserving a
namespace for the purpose of a standard is an easy way to create a mess.

Because the namespace of a type includes the assembly name, several
assemblies (even in the same program) can use the same namespace name with
completely different types. It does not hinder the progress of other library
vendors.

If you are concerned about ensuring your program is portable using only the
features of the ECMA and ISO standards, you can build and run the program
with the Shared Source CLI implementation.

Of course, I don't work on the frameworks, so I can't say with any authority
as to why they chose the namespaces they did. All I can say is that it
shouldn't have any impact on developers, they should just be usable.

Cheerio!
 
Back
Top