Package proposal for C#

[leeo3264]

Having programmed exclusively in Modula-3 a generation ago, I often acutely feel the current C# accessibility system restrictive. To facilitate the discussion I illustrate this with this CoPilot AI collaboration and hope it adds spice to the issue. See
Including packages in csharp, a CoPilot collaboration..odt

For purposes of justifying packages in C#, I define "package" as the total availability of resources from a namespace across an assembly boundary. With this, every namespace presents a single package, which includes the members thereof declared "public", and the members of classes therein declared "public". This is to support encapsulation, one of the tenants of the object-oriented paradigm. Encapsulation presents a restricted view of the resource, which facilitates opportunities for reuse. The art of package design is a delicate balance: expose too much and the result is unnecessarily fragile, bloated, and dependent on obscure details limiting reuse. Expose too little and needed features are not available.

While this balance is ever-present, the issue with C# and, indeed, most every other programming language claiming to be "object-oriented" is that exactly one package is presented for each module body (namespace in the case of C#). This burdens the designer, in that one package must facilitate every conceivable (and some not even conceived yet) employment. This forces the designer to over-declare the elements in the package with limits the benefits of object-oriented design encapsulation.

This proposal is to support more than one package released from a namespace. The language feature designer should tread carefully: identify a need and propose a solution that must have these features. (1) absolutely be backward compatible. (2) minimally impact the language specification. (3) stay in the spirit and feel and expressive power of the language.

Syntax

The proposed syntax modifies the existing namespace declaration to optionally include package identifiers. The identifiers after the contextual keyword "showing" may be thought of as initially empty packages that may be populated with resources.

namespace DatabaseSystem showing Common, Maintenance + Common, Development, Testing {
  // code here
}

In the namespace header, one possible usage scenario for Common would include usual database features, (i.e. Add, MarkforDeletion, etc.) -- for Maintenance would include advanced features to fix issues in a corrupted database to reestablish referential integrity. The addendum " + Common " indicates clients employing the DatabaseSystem.Maintenance automatically has access to all of the items of the Common package. Development and Testing are separate packages employed to relay a readiness status.

Populating Packages

Resources within the namespace and within classes in the namespace can be included in the specified packages using an addendum "in PackageName" at their declaration. More than one addendum is supported; any member may declare itself as a member in any number of declared packages.

  class ManyPartiallyAccessedMembers in Testing  // this entire class is visible in the Testing package
  {
    int serial in Testing = Serial.obtainNumber;

    void MaintenanceOperation() in Maintenance in Development // in both Maintenance and Development
    {
        // code
    }

   void CommonOperation() in Common
    {
        // code
    }
  }

Client View

Here's how a client using DatabaseSystem.Maintenance will see the class ManyPartiallyAccessedMembers

namespace ClientApp
{
    using DatabaseSystem.Maintenance

    class Program{
      static void Main()
      {
        ManyPartiallyAccessedMembers instance = new ManyPartiallyAccessedMembers;
       instance.MaintenanceOperation(); // Accessible
       instance.CommonOperation; // Accessible because Maintenance implicitly includes all of Common.
       // int s = instance.serial ; // not accessible
      }
}

Any member declaring itself a member of any package is implicitly of public accessibility -- though marking it "internal" is an option.

[CyrusNajmabadi]

@leeo3264 Please include any needed information in this issue. We don't put specs/discussions in other formats (like odt), or external locations. Thanks.

[leeo3264]

granted -- I just thought that showing the process might be of interest. Since the specification is still in development, it is not yet ready for inclusion here, I feel. It represents a significant change, much like the introduction of generics -- thus should be written up carefully with justifications as was the generics proposal generations ago. Inlining all of the discussion referenced I felt would be too off topic to include here. If you wish, I'll quietly withdraw the request for discussion until it is a bit more fleshed out. I do appreciate your input.

[CyrusNajmabadi]

Yes. Please withdraw for now, and create a new discussion when ready to present and discuss. Thanks! :-)

[CyrusNajmabadi]

Closing out. Feel free to resubmit when this is ready for discussion.