New access modifier: channeled<T>

[juanclopgar97]

OOP (Object Oriented Programming) tries to model data into objects..

C# enables to specify:

• Properties(Adjectives): Describe the object qualities
• Methods(Verbs): Actions, what the object is capable to do
• Events(Notifications): Usually verbs on past tense indicating something relevant happens to execute external logic.

and every single one of this members can define its accesibility (Who can use that specific class member) with next access modifiers:

• public

• private

• protected

• internal

• protected internal

• private protected

However there are an special cases that are not being cover in any of the previous access modifiers, to ilustrate these cases I will provide an example:

Let's imagine a person, this person have a Name and everybody is able to ask for the name, however, change its name (set the name) should not be public or open to everybody, only a local courthouse should be able to do so, another example is the capacity of a person to tell its problems, but it is only going to do it with a psychologist.

On previous example there are valid properties and methods applicable to a person but they are only accesible to a PRIVILEGE GROUP.

channeled<T> access modifier would help to solve this issue:

Class member example

public class Person
{
	//Property example
	public string Name // Everybody can access the persons name
	{
		get{ return name; }
		channeled<LocalCourthouse> set{  name = value; } // only a local courthouse can set the name
	}

	//Method example
	channeled<Psychologist> void TellProblems() // only being able to talk about its problems with a psychologist
	{
		Console.WriteLine("These are my problems…");
	}

	//Event example
	channeled<TaxOffice> event ExpenseEventHandler PurchaseMade; //only letting the tax office know about its expenses
}

public class LocalCourthouse
{
	public void ChangeName(Person person, string newName) 
	{
		person.Name = newName; // Is able to access Name property because  Person class allows  LocalCourthouse access to this member
	}
}

public class Psychologist
{
	public void AnalyzePatient(Person person)
	{
		person.TellProblems(); // Is able to access TellProblems method because Person class allows  Psychologist access to this member
	}
}

public class TaxOffice
{
	public void RegisterTaxPayer(Person person)
	{
		person.PurchaseMade +=  person_PurchaseMade; // Is able to access PurchaseMade method because Person class allows TaxOffice access to this member
	}

	private void person_PurchaseMade(object sender, ExpenseEventArgs e)
	{
		Console.WriteLine("Collecting taxes from " + (sender as Person).Name );
	}
}

public class School
{
	public void ChangeName(Person person, string newName) 
	{
		person.Name = newName; // NOT VISIBLE!!!
	}
}

In the code block above is shown how channeled access modifier would work.

channeled<T> access modifier could declare multiple "T" types to enable multiple access authorizations:

channeled<Psychologist,Partner> void TellProblems(){ ... } // It allows access to Psychologist and Partner

And last but not less important as protected internal and private protected access modifiers are a "mix" of previous modifiers to enable an especial access case, channeled<T> could be combined with "private" or "protected" as follows:

private channeled<Psychologist> void TellProblems(){ ... } // It allows access this member  only  to Psychologist class and ONLY to this class 
protected channeled<Psychologist> void TellProblems(){ ... } // It allows access this member to Psychologist class and all classes that inherit from it for example a "Neuropsychologist" class that inherits from Psychologist

Class (Type) example

Lets imagine a class with the *channeled<T> * modifier

channeled<Originator> class Message
{
	private string content;

	public Message(string content)
	{
		this.content = content;
	}

	public string Content
	{
		get{ return content; }
	}
}

public class Originator
{
	public void SendMessage(string content)
	{
		Message msg = new Message(content); // Only Originator being able to use Message type
	}
}

This is not "atractive" or "new" behavior because can be accomplish with a nested private class, However now lets imagine a Recipient class

channeled<Originator,Recipient> class Message
{
	private string content;

	public Message(string content)
	{
		this.content = content;
	}

	public string Content
	{
		get{ return content; }
	}
}

public class Originator
{
	public void SendMessage(string content)
	{
		Message msg = new Message(content); // Originator being able to use Message type
		//Extra logic to send a message
	}
}

public class Recipient
{
	public void ReceiveMessage(Message msg) // Recipient being able to use Message type
	{
		//logic to receive the messsage
	}
}

Now two classes are allowed to use Message type creating a way to communicate between them with a type they only can use, and this behavior is not possible with a nested private class

SUMMARY

channeled<T> access modifier will allow have more control and access over "who" can access specific Types/class members, increasing security in a way no other access modifier currently do.

[timcassell]

Looks like friend #2073

[juanclopgar97]

Hi I saw that entry as well but I do not think are the same concept due next reasons:

• channeled<T> is more granular and precise, as access is restricted to specific members within the host class. For example, only certain methods or properties will be accessible to the specified class.

• channeled allows multiple types to be specified in a single declaration, facilitating controlled access to groups of classes without repeating lines.

• channeled allows for interesting combinations, such as private channeled or protected channeled , adding an additional level of control that defines not only who has access, but in what context

• friend can make the design less secure if used excessively, as it can break encapsulation by allowing indiscriminate access to private data. However, channeled allows for stronger encapsulation by limiting access to only the necessary cases specified in the class design.

Under these arguments I think is not exactly the same, it is just a different aproach to solve a similar issue

[colejohnson66]

Arguably, sure. channeled<T> is more scoped than friend T. But the vast majority of the time, it doesn't really matter. If you really have a situation where you want a "friend" to only access certain parts, just make the parts you don't want exposed private. You can also give out an Action<string> to places where you don't want to expose the setter — the action would call the private setter. This seems like an attempt at precision work that isn't that useful.

[huoyaoyuan]

Any model to restrict accessibility should likely be implemented by custom analyzer. It will provide much more flexibility than the language itself.

[juanclopgar97]

I haven't used an analyzer myself, but as far as I know, there are some points to consider (please correct me if I'm wrong):

• Analyzers should be used to ensure security rules in the project before compiling, NOT to provide security itself. Security enforcement must happen at the runtime level to guarantee consistent behavior, while analyzers only serve as development-time helpers.

• The language should ensure its own security and should not delegate that responsibility to external software that can be bypassed easily. Native language features, like access modifiers, provide universal, compiler-enforced rules, ensuring consistency across all environments. In contrast, analyzers rely on external implementation, which can lead to inconsistencies and fragmentation.

• If an analyzer were to take over these features, there would be no point for the language to include access modifiers at all. For example, you could make everything public and rely on an analyzer for enforcement, which would break fundamental principles of encapsulation and object-oriented design. This would render modifiers like protected or protected internal pointless, which I believe is a horrible idea.

[HaloFour]

Analyzer should be use to ensure security rules in the project before compiling, NOT to provide security itself. Security enforcement at runtime ensures consistent and reliable protection.

You can already use reflection to bypass accessibility.

Language should ensure its own security and do not leverage that responsability to external software

It's not the responsibility of the language to enforce arbitrary policy decisions as a subset of the language for your project. It's fine to suggest this as a feature for the language, but given how far other similar proposals I don't think it's likely to ever be considered. The fact that an analyzer can trivially solve for this particular use case would make it even less likely to be considered as language feature, as analyzers were added specifically to allow for such situations to be solved without changing the language.

[juanclopgar97]

I see, so basically it could be a cool feature to have but you don't think is going to be consider due history and that already there are other ways to satisfy that necessity and the ammount of work that would cause as well. From my POV would be great have a built in access modifier satisfyng the necessity and as the name says modify the accesibility of a member in the language.

As well I think that is the point of propossals, right? maybe right now could be not viable but it could be a great feature to have at somepoint, or maybe it is going to make it.

But you have really good points thanks for the feedback.

[huoyaoyuan]

A built-in feature should be stable, composable, widely-agreeable, and future-proof as possible. The bar for making a language feature is very high, "cool" is far below the requirement.

That's why we always suggest to use customizable ways to explorer ideas agreed by fewer parties. It allows practicing in your environment and collect successful real-world use cases. You don't need to wait for agreement from everyone, just yourself.

[juanclopgar97]

yeah I mean by "cool" I was not refering to "That is the only reason I will propose it", actually that idea came to me several years ago and never have the actual case or oportunity to share it with the community, I agree with you, the bar is high, and actually I face my self in a couple of projects with that situation in which I need a really specific access modifier. I didn't know about analyzer before your answer, it seems like a good way to approach the problem althought sometimes it feels more like a patch than an actual feature, (again I do not know about analyzer or how/when they were introduced) and finally I land the idea a couple days ago of how channeled could be implemented on the language to approach that issue.

Again it is a proposal to add something I felt was valuable for the language with the best intentions, I hope the community can offer even more feedback. and again I appriaciate your feedback as well

[juanclopgar97]

I just edit my entry to add an Event example (to have Property,Method and Event example) and how can be channeled<T> be used with a type (in that example is a class)