[Proposal] Add native Tangl support

[mnbeer]

A tangl is a formal relationship between two otherwise unconnected things (classes, members, etc.). It fills gaps not handled by interfaces and inheritance, ensuring that - for example - common properties in related models have the same implementation. Tangls help manage model pollution (https://github.com/mnbeer/Tangl/wiki/Model-Pollution#what-is-model-pollution) and prevent runtime type mismatch errors (https://github.com/mnbeer/Tangl/wiki/Preventing-Errors#how-does-a-tangl-prevent-errors).

Code might look something like this:

    class PersonViewModel
    {     
        public int PersonId { get; set; } : Person.PersonId 
        // other properties here
    }

Tangls can be implemented with attributes using my library here: https://github.com/mnbeer/Tangl (https://www.nuget.org/packages/TanglAnalyzer/). But this can get pretty wordy.

Tangl definition and examples here: https://github.com/mnbeer/Tangl#what-is-a-tangl

[CyrusNajmabadi]

I read your site and i don't undrestand your usecase. You mention, for example:

And after that, mysterious errors start popping up at various points in the chain because longer numbers cannot be forced into smaller ones.

I don't see why that would be. If these properties are incompatible (because they have different sized values), then your code should not compile. So i don't see why you need an additional connector here.

[CyrusNajmabadi]

Please provide more information on:

1. what the full proposal is.
2. why this would be valuable for the language.
3. why existing approaches in the language are not sufficient.

Thank you :)

[theunrepentantgeek]

If this is something that can be implemented by a library, then is almost certainly should be implemented by a library, especially for such niche concerns as this.

Not to mention that there are non library ways to achieve the same level of type safety.

[mnbeer]

Goals/Benefits:

• Condense and simplify property definitions (taking automatic properties one step further)
• Make property type and attribute definitions DRY - defined only once
• Provide semantic meaning and relationships to properties
• Prevent runtime errors when reflection is used to map value in one object to another
• Provide a level of discoverability missing for apps that use mapping tools that result in reference counts of zero
• Prevent attribute mismatch [ex: MaxLength(100) vs MaxLength(50)]

Proposed syntax:

    class CustomerSummaryModel
    {
        CustomerId : Customer.Id;
        Address.StreetAddress;
        Address.City;
        Address.State;
        Address.Zip;
        LastOrderAmount : Order.Total;
        LastOrderDate: Order.OrderDate;
    }

Syntax with attribute instructions:

    class CustomerSummaryModel
    {
        CustomerId : Customer.Id;
        Address.StreetAddress;
        Address.City;
        Address.State(includeAttributes: false, except: "MaxLength);
        Address.Zip;
        LastOrderAmount : Order.Total(includeAttributes: true, except: "Required");
        LastOrderDate: Order.OrderDate;
    }

[svick]

@mnbeer I think example usage is not enough, you should explain how would the proposed feature actually work.

[AlgorithmsAreCool]

@mnbeer I've read your repo notes and I think I understand the problem you are trying to solve.

Please correct me if I am wrong:

• You want to be able to provide a single "primary" definition for a property that can be
  referenced from another type. This property reference will "inherit" the type and attributes
  of the "primary" definition. If the primary is updated/modified, all of the references update
  implicitly.

I had a project were I have a surface API, some business logic and a backend DB. I might then have
3 separate models that need to be mapped together. Each of the models will typically have significant
overlap in between definitions. Complex models will have dozens or hundreds of types in each model
that are 80-90% similar. This overlap puts pressure on the developer to combine and consolidate the
models to reduce the amount of code to write. This is however in tension with maintaining a
hygienic separation between layers of the application.

Further more, mapping layers becomes an exercise in repetition leading to hundreds or thousands of
lines of code copying properties from one object to another. It is rote, prone to copy-paste errors
and review blindness.

To combat this monotony, developers look to use mappers and more specifically convention based mappers
that help automate mapping properties. However reliance on convention can silently introduce mapping
errors that are even harder to catch.

This proposal seems to target a specific class of these errors where models fall our of sync with each
other. A dev changes the DB model and the UI model continues to "work" because the mapper is wallpapering
over the issue.

This proposal provides a way to link the definition of a property in one type, to a property in another type.

//C# today

public class Person
{
    public int PersonId { get; set; }
    public List<Address> Addresses { get; set; }        
    // other properties here
}

public class Address
{
    public int AddressId { get; set; }
    public int PersonId { get; set; }
    public string AddressType { get; set; }
    // other properties here
}

...

public class PersonViewModel
{     
    public int PersonId { get; set; } //conceptually the same as Person.PersonId
    public Address HomeAddress { get; set; }
    // other properties here
}

Now if a dev changes Person.PersonId to a long but forgets to update PersonViewModel.PersonId
a mapper might either force a risky cast, or just abandon the mapping because of the type incompatibility.
This is a "silent" bug that can creep into code over time.

Obviously, if the codebase uses hand written mappings, you will get a type error. But the idea is that
forcing developers to write lots of manual mapping code just to provide this type of safety is a high
cost. If there was a uniform way to inform mappers (and the compiler) about this conceptual linkage without
a high syntax cost, people could have the safety improvements while also eliding lots of monotonous
mapping code.

This appears to be the Tangl concept @mnbeer is talking about. They further suggest that Attributes
would be optionally "linked" as well as the property type, this way annotated constraints can flow
across model layers.

It sounds like this can be accomplished with attributes and analyzers, and apparently is with the
Tangl project. The proposal would simply provide native support in the language syntax for this
concept which would reduce friction of adoption.

[mnbeer]

@AlgorithmsAreCool - Your general descriptions of the issues introduced by overlapping class definitions and the benefits of the tangl concept are spot on. Thanks, and if you don't mind, I may incorporate some of your language in my documentation.

I don't know that tangls snugly align with terms like "inherit" and "reference" so I avoid the terms to avoid confusion (thus the new term).

As you say, "native support in the language syntax for this concept ... would reduce friction of adoption." In addition - and I think this is very important - native support can be marvelously concise, readable, and self-explanatory compared to the attribute option of my project (and compared to the existing state of disconnected classes that litter projects now).

[mnbeer]

The idea here is follow the precedent of automatic properties where "the compiler creates a private, anonymous backing field..." (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties).

In the following sample (minus attributes to make the sample cleaner), the developer codes these classes ...

    class Customer
    {
        public int Id {get; set;}
        public Address Address {get; set;}
        // other properties here
    }
	
    class Address
    {
        public int Id {get; set;}
        public string StreetAddress {get; set;}
        public string City {get; set;}
        public string State {get; set;}
        public string Zip {get; set;}
	// other properties here
    }

    class OrderId
    {
	public int Id {get; set;}
        public decimal Total {get; set;}
        public DateTime OrderDate {get; set;}
	// other properties here
    }
	
    class CustomerSummaryModel
    {
        CustomerId : Customer.Id;
        Address.StreetAddress;
        Address.City;
        Address.State;
        Address.Zip;
        LastOrderAmount : Order.Total;
        LastOrderDate: Order.OrderDate;
    }

... and the compiler transforms CustomerSummaryModel into

    class CustomerSummaryModel
    {
        public int CustomerId  {get; set;}
        public string StreetAddress {get; set;}
        public string City {get; set;}
        public string State {get; set;}
        public string Zip {get; set;}
        public decimal LastOrderAmount {get; set;}
        public DateTime LastOrderDate {get; set;}
    }

[333fred]

As this is not a full syntactic and semantic proposal, I'm converting it to a discussion.