In the
comments to my last post, Bruce Williams (from the Indigo team) asks:
Would it be accurate to say that you are (reasonably) satisfied with the _features_ of Indigo, but you don't want to use C# (as it exists today), but would prefer some mix of a language ("M#"?) that has SOA constructs as first-class language elements, and perhaps equivalent GUI tools like the Biztalk 'Mapper' you described in another post?
Emphatically NO! I'm reasonably satisfied with the features of Indigo, but I want them exposed effectively in the languages I use today (VB.Net and C#). The absolute last thing we need is a new language. Take a look at what the VB team did with the Module statement. Whether or not you think the VB Module is good idea (lots of people hate it, but I think it has its occasional uses), it shows pretty clearly that what I suggested is feasible without any changes to the CLR or the CTS. From the docs:
Modules are a reference type similar to classes, but with some important distinctions. The members of a module are implicitly Shared [static for the rest of the world] and scoped to the declaration space of the standard module's containing namespace, rather than just to the module itself. Unlike classes, modules can never be instantiated, do not support inheritance, and cannot implement interfaces. A module can only be declared in a namespace and cannot be nested in another type.
You can have multiple modules in a project, but members with the same name defined in two or more modules must be qualified with their module name when accessed outside of their module.
[Comment in brackets added]
If the VB.Net team can do that, I don't see what the problem is with implementing the concept of a Message as a restricted reference type. Even if that is out of scope for the Indigo team, there are any number of ways that they could surface the inherent functionality of Indigo without the relegating it to a lame set of attributes (but that's my next post).
Posted
May 10 2005, 10:43 PM
by
john-cavnar-johnson