Granular and precise access/heritability modifiers

[dsaf]

It goes against the functional trend and requires CLR changes, but how about more granular OOP hierarchy control and potential syntax for this?

Languages such as TypeScript already provide a more granular control over namespace/module imports using syntax like:

export * from "./StringValidator";
import { ZipCodeValidator } from "./ZipCodeValidator";

Could both idea and syntax be propagated to other code re-use concerns in C#?

Two potential areas of application are:

Visibility control. A way of specifying exact namespaces/types that are granted access:

public protected { MyNamespace } MyMethod ()
{
}

(equivalent to

private * public protected { MyNamespace } MyMethod ()
{
}

)

Heritability control. A way of specifying who exactly is allowed to extend a type (could be combined with visibility control):

public { MyNamespace } unsealed { MyNamespace } MyClass
{
}

(equivalent to

public { MyNamespace } sealed * unsealed { MyNamespace } MyClass
{
}

)

[CyrusNajmabadi]

You're saying what you want, but you haven't given compelling reasons why this would be wanted.

[brabebhin]

The granularity of imports is a constant annoyance in java/typescript/whatever. We don't need that here or anything derived from it.

[Austin-bryan]

It goes against the functional trend and requires CLR changes

Then the answer is pretty much already no, unless it is completely amazing and needed, which it's very much not. It's confusing and seems like it's a pain.

You also completely missed the very important why. Can you give one example for when this would be useful?

[MgSam]

Agree with @mcosmin222. TypeScript/JavaScript's imports are by far the worst import system I've used in any language. I wish someone in that ecosystem would take a step back and make it more like C#'s vastly superior system.

[CyrusNajmabadi]

TypeScript/JavaScript's imports are by far the worst import system I've used in any language.

Could you provide some explaining behind that? I personally find it much more sensible because a JS import is just normal code that runs, executes a module, and then gives you back whatever that module exported. In typical JS fashion, everything is a value, and it's not some sort of 'special' out-of-band system. Importantly, because modules are just values, you can treat them as you would any other value. Contrast that this to imports/usings. When you bring in stuff from an import/using, you are getting a side-band channel of these things that are not actually things. It breaks down immediately in an OO setting like C#. For example, how do i take a namespace and pass that namespace to someone else as a value? How can i pass an actual type around (as opposed to a typeof)? etc. etc.

[dsaf]

@CyrusNajmabadi

You're saying what you want, but you haven't given compelling reasons why this would be wanted.

To be more precise in expressing intent.

[theunrepentantgeek]

To be more precise in expressing intent.

Really? I don't find the current syntax at all imprecise.

I'd like to see an actual example that demonstrates why the current constructs aren't up to the task, and why this new syntax is actually beneficial.

It would also be helpful if you explained the proposed syntax - I've come back and re-read the original post a dozen times (quite literally) and I can't make head nor tail of what it's supposed to do.