Expand Namespaces interrogated for use with Extension Methods

[TonyValenti]

Often times I find myself using empty, "Marker" interfaces and then putting all of the static members into extension methods as shown below. The problem with that is that I have to then add a using statement in order to be able to use the extension methods that are specifically designed for my interface. I would like to request that the namespace of the object, and namespaces of any interfaces it implements, always be searched for extension methods so the following would work:

// Get Some class, somewhere that implmenets ITemplateVariables.
var C = Some.Namespace.Somewhere.SubjectTemplateVariables(); 

//This works without an explicit using to AlphaDrive.Data
var Table = C.GetTokenTable();

This would also greatly aide in the "Discoverability" of extension methods.

Main code:

namespace AlphaDrive.Data {
    public interface ITemplateVariables {

    }


    public class TemplateVariableTable {
        public string Name { get; set; }
        public string Value { get; set; }
        public string Description { get; set; }
    }

    
    public static class ITemplateVariableExtensions {

        public static IEnumerable<TemplateVariableTable> GetTokenTable(this ITemplateVariables This) {
            var Values = This.PropertiesToTokenDictionary();
            var Descriptions = GetPropertyDescriptions(This.GetType());

            var ret = (
                from x in Values
                let Name = x.Key
                let Value = x.Value
                let Desc = Descriptions.TryGetValue(Name, "")
                select new TemplateVariableTable() {
                    Name = Name,
                    Value = Value,
                    Description = Desc,
                }).ToLinkedList();

            return ret;
        }

        public static IEnumerable<PropertyDescriptor> GetPropertyDescriptors(Type T) {
            var Props = (
                from x in TypeDescriptor.GetProperties(T).OfType<PropertyDescriptor>()
                where !x.IsReadOnly && x.PropertyType == typeof(string)
                select x
                ).ToLinkedList();

            return Props;
        }

        public static IDictionary<String, String> GetPropertyDescriptions(Type T) {
            var ret = new SortedDictionary<String, String>();
            var Props = GetPropertyDescriptors(T);

            foreach (var Prop in Props) {
                ret[$"{Prop.Name}"] = Prop.Description;
            }

            return ret;
        }


        public static IDictionary<String, String> PropertiesToTokenDictionary(this ITemplateVariables This) {
            var ret = new SortedDictionary<String, String>();
            var Props = GetPropertyDescriptors(This.GetType());

            foreach (var Prop in Props) {
                ret[$"{{{Prop.Name}}}"] = Prop.GetValue(This).ToStringSafe();
            }

            return ret;
        }

        public static IDictionary<String, String> PropertiesToDictionary(this ITemplateVariables This) {
            var ret = new SortedDictionary<String, String>();
            var Props = GetPropertyDescriptors(This.GetType());

            foreach (var Prop in Props) {
                ret[$"{Prop.Name}"] = Prop.GetValue(This).ToStringSafe();
            }

            return ret;
        }


    }

}

[Joe4evr]

Often times I find myself using empty, "Marker" interfaces

If anything, using marker interfaces is considered an anti-pattern.

The problem with that is that I have to then add a using statement in order to be able to use the extension methods that are specifically designed for my interface.

So why are you not putting those extension methods in the same namespace? 🤔

Also, this would be a massive breaking change, as it could suddenly add ambiguous extension methods in scope where there previously was not.

[TonyValenti]

I am though. The extension methods are located in the same namespace as the marker interface. They are just consumed from a different namespace.

[HaloFour]

This would add a third level of namespace lookup that I think would be confusing. The compiler would have to target instance members first (obviously), then imported namespaces and then the namespace of the target type.

[jveselka]

I disagree that it would be confusing. Resolving otherwise erroneous cases with what is apparently a desired behaviour takes burden out of a programmer. I think the idea is a good one.

[louthy]

If you own the interface then you could just put your extensions in the global namespace, then they will always be available.

…

On 28 Jun 2018, at 09:09, Jiří Veselka ***@***.***> wrote: I disagree that it would be confusing. Resolving otherwise erroneous cases with what is apparently a desired behaviour takes burden out of a programmer. I think the idea is a good one. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jveselka]

@louthy That's true, but that would introduce static classes holding those extensions into scope everywhere as well.

[stakx]

If you own the interface then you could just put your extensions in the global namespace[.]

[T]hat would introduce static classes holding those extensions into scope everywhere as well.

@zippec: You make that sound as if it were a problem. If it is, why?

[YairHalberstadt]

Now championed at #4029