C# Next - Feature Request: Multi Casting

[deadmann]

I wish if it is possible to reduce duplicate code, and and generating less bug that happens naturally in big project due you edit something but you forget to do the same for another part, C# provide a way of multi-casting and force-casting:

I provide my propose with sample code from my own project:

Consider these 3 classes:

    public abstract class Owner
    {
        public string Nickname { get; set; }
        public string Introduction { get; set; }
    }

    public class Agency : Owner
    {
        public string AgencyName { get; set; }
        public string AgencyWebsite { get; set; }
        public string ContactEmail { get; set; }
        public string ContactTel1 { get; set; }
        public string ContactTel2 { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public PersonTitle? OwnerTitle { get; set; }
        public string RegistrationNumber { get; set; }
    }

    public class Person : Owner
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public PersonTitle? OwnerTitle { get; set; }
        public string ContactEmail { get; set; }
        public string ContactTel1 { get; set; }
        public string ContactTel2 { get; set; }
        public string NationalCode { get; set; }
    }

    public class Robot: Owner {
        public string Provider { get; set; }
    }

in here, if i want to write codes to check data within the Person and Agency, i have to write many duplicated validations, or I'm forced to introduce another level of inheritance:

My propose is to provide two new features:

1. Multi Casting - using ( , ) operator:

var valiateContact = (Agency, Person) owner;
if( !emailRegex.IsMatch(validate.ContactEmail)) {
    return false;
}

In above example, accessing to shared properties or Function with exactly same signature should be allowed, and un-shared properties should get filtered out:
So:
accessing validateContact.FirstName, LastName, ContactTel1, ContactTel2, ContactEmail, OwnerTitle are allowed.
But accessing valiateContact.AgencyName, AgencyWebsite, RegistrationNumber, NationalCode, are denied.
Also all properties from Owner and object, which are shared, are allowed too.

This should tell compiler to behind the scene rewrite these code separately for each object, reducing the duplicate code in user interface.

2. And by force-casting, although the name may be un-fitting:
   I propose as base of multi-casting, and on the same structure as that, another way of casting to be provided... Using ({ }) operator.

Think of same classes as above, in a less or more complex structure, with no inheritance and such, you want to first write the structure, you do now know what the user may provide, but you want to force them to use specific structure if they are going to do these operation...

I think this may be fitting, if we say we want to do some operation only on ContactTel and ContactEmail, and we need some methods in which we know the signature of, we don't care about other stuff, yet we are not aware of the outer system, we force user to provide those fields...:
We can do this:

public delegate string MakeName(string[] parts); // a simple delegate
var validateObj = ({string ContactTel, string ContactEmail, MakeName nameGenerator) obj;
var tel = validateObj.ContactTel;

Also we could provide extra operator for this matter, same as nameof() operator...
if it be: signatureof() the following will be the result:

var validateObj = ({ signatureOf(Person.ContactTel), signatureof(ContactEmail), signatureof(MakeName)}) obj;

The end.

[YairHalberstadt]

This sounds quite similar to #399

[Tom01098]

I think to implement this functionality, the compiler would need to either introduce the extra level of inheritance or generate different code for each case.

Also, what type is validateContact in your example?

I think the syntax kinda conflicts with tuples - is (Agency, Person) a tuple or a multicast?

[yaakov-h]

This does sound like #399, but the underlying issue seems like it could also be addressed with #164.

[deadmann]

inheritance or generate different code for each case.

that's what i said...
The validateContact can be a dynamic/anonymous like dictionary (as we know dynamic is a dictionary), which also hold a reference to the object actual object internally, but the compiler should lookup all Type signatures and only provide those who are shared...

it allow user to calculate a matter only once. then, behind the scene compiler remove those hassles (as reflection matters are costly) and provide a hard coded version of that calculation per each type and place it inline... or maybe you as the one who write compiler it self, have access to lower lever functionality that make it easier without doing all those heavy functionality of reflection, and provide it in better ways.

[orthoxerox]

as we know dynamic is a dictionary

dynamic is not a dictionary, ExpandoObject is.

[deadmann]

as we know dynamic is a dictionary

dynamic is not a dictionary, ExpandoObject is.

Well i'm not aware of substructures, if i had two ability: knew how to write test, easily read and copy other people codes, i would get more active in GitHub as it could be strong resume for me...

But i say that because i had an issue long ago, and i had to do some dynamic property reading...
and this question due to this answer:
https://stackoverflow.com/questions/8631546/get-property-value-from-c-sharp-dynamic-object-by-string-reflection/14011692

either :

1. dynamic is a ExpandoObject with it is in base dictionary (implementing IDictionary,
   or
2. dynamic is: implicit cast-able to dictionary

Did you see ExpandoObject class?

Directly from MSDN description: "Represents an object whose members can be dynamically added and removed at run time."

With it you can write code like this:

dynamic employee = new ExpandoObject();
employee.Name = "John Smith";
((IDictionary<String, Object>)employee).Remove("Name");

and yes, dynamic is nothing but a keyword, that uses those structural capacities

[theunrepentantgeek]

No. dynamic is a keyword that defers a lot of stuff that the compiler checks does until runtime.

The ExpandoObject class is one way to leverage dynamic, but it's more of a sideshow than the core functionality.

[canton7]

To add a little more detail....

The dynamic keyword itself allows late binding. Normally when the compiler sees a type, it makes various decisions at compile-time based on that type. For example, whether a particular property can be accessed, or which overload of a method group to call. If the type is dynamic, then those decisions are deferred until runtime when the actual runtime type is known.

For example:

public void PrintLength(dynamic obj) => Console.WriteLine(obj.Length);

PrintLength("Hello, World");
PrintLength(new int[] { 1, 2, 3 });

The PrintLength method can take any type at compile-time, whether or not it has a .Length property. You could compile the code PrintLength(3) if you wanted. At runtime, when the type of object passed to PrintLength is actually known (be it a string, or an int[], etc), then the compiler gets involved again and figures out if there is a property called Length, and calls it if there is.

Now, most of the time the type which is referred to by dynamic (that is, string or int[] or int in my example above) doesn't know that it's being used in a dynamic context. However types which implement the interface IDynamicMetaObjectProvider do, and they get to participate in the late binding process.

If I pass an object which implements IDynamicMetaObjectProvider to the PrintLength method above, then when .Length is called at runtime (or any other property is accessed, method is called, etc), the object is told this, and it gets to run whatever code it wants.

This is mainly meant for interoperability with scripting languages, which tend to be inherently late bound. You can create an object which implements IDynamicMetaObjectProvider, refer to it using dynamic, and then calls methods on it, and it can proxy all calls through to the scripting language engine and return the results.

The BCL does ship with two classes which implements IDynamicMetaObjectProvider: DynamicObject and ExpandoObject. DynamicObject makes it a bit easier to write implementations of IDynamicMetaObjectProvider which run custom code when properties, methods, etc are invoked. ExpandoObject is the one that implements IDictionary<string, object> (and translates property accesses into dictionary lookups), and is little more than a demonstration of the technology (having very little real-world application).

[canton7]

Also, have you thought about using interfaces? Common practice is to define an interface which holds the properties which are common between your objects, and have both objects implement that interface. Then you have a strong compile-time contract which says that both Agency and Person must implement FirstName, LastName, etc, and you'll get a compile-time error if you break this contract for some reason.

For example:

public interface IContactable
{
        string FirstName { get; set; }
        string LastName { get; set; }
        PersonTitle? OwnerTitle { get; set; }
        string ContactEmail { get; set; }
        string ContactTel1 { get; set; }
        string ContactTel2 { get; set; }
}

Then your validation method can take an IContactable.

[rakshith-ravi]

Can't this be solved with a switch expression?

[deadmann]

Can't this be solved with a switch expression?

this is the opposite of switch expression... you naturally filter out, and find data types, and pass them to switch, to write codes which are differences from one another,
Here, we want to access the shared part of objects, (like when you are passing child to their parents and you know they have same parents), but somehow for some reason here they didn't had same parent. (if you access their methods or properties, from the base they may even be implemented differently, but you know they have access point that are exactly alike, and in some calculation which could even be long and complicated, this, would remove the duplication of code if you are knowing that the incoming data going to be same. for my case, it was a complicated form validation stuff, for someone else it can be long mathematical calculation, or graphical calculation or rendering, it can be anything.

[deadmann]

Agency and Person

Interfaces for sure are good and made life easy in many places, but we are talking about objects of different types, you do not always access to object of a lower system which you are referencing in your system. also adding an interface or class, sometime, adds to complexity.

How ? here i had only two object overlapping with same data structure... what about if i have other object that are overlapping on something else? or i have sealed base class which i can't create a wrapper around?, in one method, my target is X and Y of object 1 and 2, but in another i'm targeting X and Z of object 1 and 3, sometime you got to define too many interfaces, and in such a case, we do not try to convey a protocol in our code, although our life is fulled with abstract classes and interfaces, but they had a propose. and do our lacks, we put our burden on them too.
Someday someone told me somethings, he said, people don't know that they need somethings, until you introduce those needs into their life... and i always wrote many duplicate codes, in balance of not make the system more complicated, and someday ago, i though it was great if i could filter out what are shared between the two, three, N objects at the same time, and only process those items. only that one or two times.

[theunrepentantgeek]

For the situation where you have multiple types that have a similar structure, and you want to treat them in the same way, check out Exploration: Shapes and Extensions #164.

The essence of that proposal is that you would declare a shape that described the structure your method needed - and anything that matched could be passed in.

For things that were close, extension methods could be written to adapt the type (e.g. string has .Length but the same needs .Count).

To illustrate, you could write something like this:

public shape SEmailable
{
	public string EmailAddress { get; }
}

public ValidationResult ValidateEmailAddress(SEmailable entity)
{
    // elided
}

And then any entity that had a public string property called EmailAddress could be passed in.

[deadmann]

and you want to treat them in the same way

No, not treat them, they may or may not be treated the same way. and their core functionality and concept may or may not be the same.

The essence of that proposal is that you would declare a shape that described the structure your method needed

Well that's what we learn because we are told to...

Shapes and Extensions #164.

It was a little hard for me to understand the text, since i'm not native english talker, but as far as i see, it can overlap with our context here, but still that provide another hassles to remove another hassles that my appear in one block of code only, and you have to think what to add to that shared shape, what i'm looking at is C# just control our action, but not force us to add copeling, complexity, and more object to work with, etc...
But the shape could provide the basing block of what we need to provide Multi-casting functionality behind the scene

[rakshith-ravi]

Here's an example of how this can be easily solved with a switch expression (I'm still figuring out the nuances of switch expressions, so forgive me if my syntax is wrong, but you get the point):

var email = switch (owner) {
    case Agency a:
        return a.ContactEmail;
    case Person p:
        return p.ContactEmail:
    default:
        throw new Exception("The world has come to an end");
};

if( !emailRegex.IsMatch(email)) {
    return false;
}

[deadmann]

Here's an example of how this can be easily solved with a switch expression (I'm still figuring out the nuances of switch expressions, so forgive me if my syntax is wrong, but you get the point):

var email = switch (owner) {
    case Agency a:
        return a.ContactEmail;
    case Person p:
        return p.ContactEmail:
    default:
        throw new Exception("The world has come to an end");
};

if( !emailRegex.IsMatch(email)) {
    return false;
}

Totally irrelevant...
I just happen to know more than these trivial stuff. and more to that, my model does not match at all, i just gave this suggestion, because i know how much usage it will have, and i and my partner are faced, and i saw in other people codes. for my case, it just remind me of this need as a "Need", so i just came here to say it, but when i was struggling with those duplicate code, i never once though that this could be solved i such a way.

[The-Futurist]

@deadmann - I'd consider reflection. You could (in effect) create an object that "knows" how to access instances of both Agency and Person, then use that and pass the actual instance in along with the name of the property you want to access. Yes this doesn't have compile time checking but it can be made to operate very fast. If you designed this well you could end up with neat robust little library that does most of what you need.

[deadmann]

@deadmann - I'd consider reflection. You could (in effect) create an object that "knows" how to access instances of both Agency and Person, then use that and pass the actual instance in along with the name of the property you want to access. Yes this doesn't have compile time checking but it can be made to operate very fast. If you designed this well you could end up with neat robust little library that does most of what you need.

Thank you for saying it in a fluent way, i couldn't get it right without your help, or being there explain it face to face as you put it into words...