Suggestion - specify which assemblies should be able to access a field.

[igorvasiak]

So, I often find myself defining some variables or methods that should be private, or protected, or even internal, and needing at some point to get them from a different assembly. But, as they use other security levels other than public, I can't access them.

Normally I would go and make them public, which is... you know, not great. I mean, imagine trying to find a method which you don't know the name (but you know what it does) between tons of vars such as speed, graphicalStyle, etc...

public var myInt;

Plus, it is a security convention violation, ain't it?

So, it would be nice to be able to just specify that the variable should be private, but accessible to that other assembly that's hanging over there. Something like this:

[public to Assembly_CSharpEditor]private int _myInt;

Or just to a specific class of it.

[internal to Assembly_CSharpEditor.MyEditorChecker]private int _myInt;

Where public could be any modifier level. I mean, with better syntax and everything, but it would be usefull to have this feature. (At least for someone who uses multiple Assemblies in a project, like me).

[HaloFour]

The only alternative that the CLR supports is through the use of InternalsVisibleToAttribute which specifies that an external assembly may access the internal members within this assembly. Without CLR support beyond that the C# compiler can't create new forms of accessibility, at least not that can be enforced.

I'd also highly question any design that necessitates the selective exposure of any members like that.

[igorvasiak]

Hey, @HaloFour, thanks for the quick response!

I wasn't aware of InternalVisibleToAttribute, definatelly gonna check that, but...

I'd also highly question any design that necessitates the selecting exposure of any members like that

Short explanation...

I'm a Unity user. On Unity you have different assemblies (so that it doesn't need to recompile the entire project everytime someone changes something specific to a certain context), such as the CSharp Assembly or the Editor Assembly. The former is the "main" one, the game's core. The other one is made for one who wants to make their editor's interface less "cluttered", let's say.

---

Somewhat detailed, boring version...

Unity works in a basis of components, and every component has a display on the editor. That display is made automatically, without any type of reoganization. Imagine yourself trying to find a variable inside a component display filled with non organized, non rellevant stuff. 😧

That's where the editor assembly comes into action. It allows for easy organization, but at the same time, it is other assembly, so to access the values I want to display I need to make them public.

---

Now, you should question their approach, not mine. 😀 I just suggested a feature that would, for guys like me, serve as a workaround to such a situation. Also, there must be some cases that need to use multiple Assemblies in the same way. 😄

[HaloFour]

@MultipleGameStyles

It's not uncommon for a project to have many assemblies. Last WebAPI project I worked on had I think 56 different projects each compiled into their own assemblies, on top of the myriad of dependencies. In that case I can't think of any situations where I needed to expose otherwise hidden implementation details.

I am not familiar with Unity so I can't really comment on it's design, but I'm not hearing anything here that sounds terribly different than the designer situation with WinForms/WPF, or with the debugger display in Visual Studio. I'd assume that they would have an idiomatic approach to exposing this data without having to expose implementation details. I assume other people would have this same problem otherwise.

[theunrepentantgeek]

The way I've solved this problem in the past is to use an interface with explicit implementation. Normal consumers of the class don't see the "distraction" of the extras, but other consumers can opt into them via the interface.

To illustrate:

public class Movie
{
    public void Play() { ... }
}

public interface IRewindable
{
    void Rewind();
}

public class DvdMovie : Movie { ... }

public class VhsMovie : Movie, IRewindable
{
    public void IRewindable.Rewind() { ... }
}

Every movie supports Play(). VHS movies can be rewound - but the method is explicitly hidden; consumers have to opt-in by casting to IRewindable first.

A real-world example of where I've used this: having certain classes implement an IDiagnostics interface that allowed the internal state of an instance to be extracted for logging purposes. Only the diagnostics framework needed to be able to see those members of each class; for everyone else, they were hidden.

[bbarry]

Does Unity utilize EditorBrowsableAttribute?

https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.editorbrowsableattribute?view=netcore-2.1

it looks like there is an open issue in roslyn: dotnet/roslyn#4434

[igorvasiak]

@theunrepentantgeek, interesting solution. Smart and simple. I might use it in some cases. 😄

@bbarry, no, not that I'm aware of. Never used it, nor considered it as well. Maybe in an internal API level, on Unity's code they use something similar to that, but I think it's very unlikely...

@HaloFour

It's not uncommon for a project to have many assemblies.

Yeah I'm aware of that. I've updated the text on the comment to reflect better what I meant.

I can't think of any situations where I needed to expose otherwise hidden implementation details

Hmmm... 🤔

I assume other people would have this same problem otherwise

Just watch some Unity Custom Editor tutorials. You'll see that everyone uses the same approach. "To expose details."

It would be useful to have a feature that enabled making private variables (or any, really) visible to other specific Assemblies's classes anyway. It would allow for more flexibility.

[CyrusNajmabadi]

it feels like this could be pretty trivially solvable with an attribute and an analyzer. Just put an attribte on your field like [VisibleTo("assembly-name")]. Then have an analyzer that makes sure that no one is accessing this inappropriately.

This is generally the appropriate thing to do when you're effectively allowing C# but wanting to restrict things. i.e. you're not trying to make things more capable. You're just trying to disallow certain things.

[igorvasiak]

@CyrusNajmabadi yeah, I didn't think of doing that. I'll try that once I have enough time. Also, nice perspective of this suggestion. Looking at this problem that way makes it easier to understand and visualize it.

You're not trying to make things more capable. You're just trying to disallow certain things.