Friend access modifier

[K1vs]

Hello,

When I design applications using DDD principles, I often encounter the following problem:

Let's imagine what I have an Order aggregate and an OrderItem entity inside it. E.g. this Order and this OrderItem.
Order has
public void AddOrderItem(int productId, string productName, decimal unitPrice, decimal discount, string pictureUrl, int units = 1) method,
and OrderItem has
public void AddUnits(int units) method.

According to DDD rules (see comment of AddOrderItem)
there is the only way to manipulate units count in OrderItem - througth the agregate root, i.e. using AddOrderItem in Order class.

And this is wery powerfull thing in tactical DDD, witch prevent a lot of error in my expirience.

But, AddUnits method in OrderItem is public. and can be accidentally called directly and this may cause loss of aggregate consistency.

We can define AddUnits as internal, but then we need create assembly per aggregate and this approach not prevent all unwanted calls.

It would be great to have a friend access modifier. Its behavior should resemble the internal modifier (including combinations with protected), but not for the entire assembly, but only for the specified list of classes.

It might look something like this:

public class OrderItem: Entity
    friends: Order
{
    friend void AddUnits(int units)
    {
        if (units < 0)
        {
            throw new OrderingDomainException("Invalid units");
        }

        _units += units;
    }
}

Then we can use AddUnits only in Order class, what we wanted to achieve.
A feature like this should not be difficult to implement, since it is similar to the internal modifier. And unlike similar functionality in C++, it does not violate encapsulation.

[HaloFour]

See: #2073

[DavidArno]

Namespaces in C# are strictly that, part of the name of the type, and they only exist for organization and to help prevent naming collisions. The runtime doesn't know or care anything about them. All it knows is that System.Collections.Generic.List happens to have some dots in the name.

@HaloFour, this statement by you that eg System.Console is the type name at runtime with namespaces being an artifact of C# that doesn't exist at runtime sits at odds with a statement made by @jnm2 almost two years ago:

Yes, class A.B.C { } would have to mean class C { } nested inside partial type B nested inside partial type A. I think @333fred or others were commenting in Discord a long while ago on how it would be unworkable for these to be namespaces.

I do have a use case for class Outer.Nested { } related to what happens to source control line history and lack of rename history if you refactor a nested class to a top-level one or vice versa. I'm planning on drafting a proposal.

[HaloFour]

@DavidArno

That's kind of a quirk of C#, which makes namespaces and nested classes appear to have the same name. That's not the case in the runtime, where / is the separator between nested classes, e.g. System.Console vs. Foo.Bar.Outer/Nested.

[DavidArno]

@HaloFour ,

Does that / separator apply to all members of a type, or just subtypes? Trying to understand why A.B.C works in C# when C could be a type, a subtype of B or eg a property of B, but the runtime needs different notation.

[CyrusNajmabadi]

Trying to understand why A.B.C works in C#

The language rules state what to do as each name is looked up. For better or worse, our language uses the same member operator (.) for all these cases.

[HaloFour]

IL uses the :: notation for members, so [AssemblyName]Namespace.OuterClass/InnerClass::Method. I don't believe the runtime itself has any concept of qualifying members, though. They only have a simple name and a declaring type.

It doesn't matter as far as C# is concerned, which has it's own name lookup rules. However, it could bleed into any decisions about carving out new namespace-based accessibility modifiers, assuming that they're not just hacked in through a combination of public/internal accessibility and a modreq.

[Richiban]

I'm not commenting on your proposal, but on the example you gave.

I don't think the AddUnits method should exist at all (on OrderItem). I would expect to be able to simply add products repeatedly to the order, and only when the UI comes along does the list get grouped by product with a unit count.

[K1vs]

IMO, you shouldn't be creating such backdoor coupling between specific types that is so dangerous that the language should enforce that it can't even be called from within the same module, and I don't think that the language should encourage it either.

And although I do not agree with this statement, it is similarly true for internal modifier.

[HaloFour]

And although I do not agree with this statement, it is similarly true for internal modifier.

I disagree, it is completely reasonable for an implementation to rely on components that are not a part of a public API.

[K1vs]

I understand what you mean. And here the main problem is the lack of a logical module smaller than the assembly and larger than the class.

[HaloFour]

At that point you're only trying to restrict access to the people working on that project, not to any consumers of an API or across module boundaries. IMO that is a questionable need, one that can be satisfied through numerous other methods that don't involve changing the language and runtime to support a bunch more ways to slice and dice accessibility.

[K1vs]

Yes, this functionality is intended for the team that works with the project. But that doesn't make it unimportant. According to your logic, a private modifier is also not needed, because there is an internal, and a private one can be emulated by a code analyzer.

[colejohnson66]

I would assume the new “unsafe accessors” feature in .NET 8 would be Good Enough(tm) for such a situation. It’s not perfect, but it would work.

[HaloFour]

This is not a consequence of C++ style design.

Then why does it rely on a feature that is exclusive to C++? No other language has this accessibility feature. It's been deemed unnecessary in any language that has proper modularization.

One is expected to adapt the design patterns to the idioms of the target language. Attempting to port one implementation directly from one language to another will only result in friction with the features, idioms and ecosystem of that language.

[K1vs]

Then why does it rely on a feature that is exclusive to C++?

Forget about C++, I mentioned it only as an implementation example. The task of allowing access to a class member only for another class comes from tactical DDD. And if in C++ it can be solved very beautifully with friends, in Java it can be solved well via packages, but in C# it can only be solved clumsily with assemblies. Because it is not always rational to make a separate assembly for the unit, as the assembly is not only a logical boundary. Or a custom code analyzer, which is also not the best option. Or simply not solve this problem, relying on code reviews and the conscientiousness of the team.

[HaloFour]

I mentioned it only as an implementation example.

I mentioned it because, so far, it's the only OOP language that I could find that has anything like friend accessibility. If there were other languages that had other implementations that would make the conversation more interesting.

Or a custom code analyzer, which is also not the best option.

Why not? That is the entire point of analyzers. It allows you to apply and enforce code policies for your projects. It's an option that you could utilize immediately.

[K1vs]

Why not? That is the entire point of analyzers. It allows you to apply and enforce code policies for your projects. It's an option that you could utilize immediately.

Because this is a custom solution, one team will have something of its own, another will have something else. And people coming to the project must learn this every time. However, I am currently working on such an analyzer, since access errors are periodically made by newcommers, and sometimes they even pass by the reviewer.

[HaloFour]

Because this is a custom solution, one team will have something of its own, another will have something else. And people coming to the project must learn this every time. However, I am currently working on such an analyzer, since access errors are periodically made by newcommers, and sometimes they even pass by the reviewer.

One team has one set of policies, another team has nothing. This is a virtue. The language can't (and won't) scale to the infinite different ways that different groups of people want to slice the onion.

In a marketplace of ideas, an implementation that finds a traction across a wider audience could be deployed to NuGet and shared amongst the ecosystem.

[HaloFour]

Relevant:

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-10-09.md#add-private-and-namespace-accessibility-modifiers-for-top-level-types

If namespace accessibility (or private for top-level types) are added that would effectively get you Java-like package accessibility.