Replaceable Members

[AnthonyDGreen]

Metaprogramming is our holy grail. It comes up time and time again. Combined with the Code-injectors compiler feature I think the ability to replace members could get us most of the benefit. Even though in C# we've been working under the assumption that you'll just have a member modifier replace I'm considering something broader in VB. These modifiers parallel what we can do today with inheritance but instead work across partial class definitions.

Replaceable
Opts a member into being replaced. Replacement isn't required. Maybe we might need a way to specify this at the class level?

Replaces
Specifies that the decorated member implementation will replace a matching replaceable definition elsewhere.

MustReplace
Creates a member stub which code can bind to but whose implementation must be provided elsewhere. This is almost exactly like a Partial but it can apply to more member types and have any accessibility.

NotReplaceable
Specifies that the decorated member may not be replaced. Attempting to do so results in an error.

And, of course, we'd need some kind of MyOriginal keyword to call into the original implementation.

There are more moving parts than what we've considered in C# but they come in handy when thinking about how multiple code-injectors would compose with each other.

The big scenarios I'm interested in with a feature like this is somehow making INotifyPropertyChanged implementations less tedious and MVVM much more approachable. But I believe this feature would also allow us to create more abstractions without having to modify the language itself so much. For example, if we allow a field to be replaced with a property we could implement (convention based) Handles without the WithEvents modifier/special code gen. There might also be some stuff in My we could do better. Need a prototype to see how far we can go.

Some open questions

• Should you have to opt-in to being replaceable?
• Should we allow a single member to be replaced more than once?

[xieguigang]

The Replace doing something like?

Class Foo
    Replaceable Public Field As Type
End Class

Class F2: Inherit Foo

    ReplaceAs Public Function Field() As Integer 
    End Function
End Class

Class F3: Inherit F2

    ReplaceAs Public Property Field() As Integer 
        Get
            ' Function Field in F2
            Return MyOriginal 
        End Get
        Set
            ' Class Field in Foo
            MyOriginal = value
        End Set
    End Property
End Class

[AnthonyDGreen]

I think replacing a field with a property is a scenario worth looking at. For example WithEvents effectively does this today. Replacing a field with a method seems more problematic.

[AnthonyDGreen]

@rskar-git, dotnet/charplang#107 is the corresponding proposal on the C# side, yes.

[rskar-git]

I read thru https://github.com/dotnet/roslyn/blob/master/docs/features/generators.md - the "Modifying Types" section seems to be the one that parallels this proposal. Being too far away from the problem, (and ashamed to say) I lack the understanding/appreciation of the solution.

But, to ask succinctly, is the scope of this proposal just about adapting the replace/original concept for facilitation of "Source Generator"/tooling issues on the VB side? Or is this also about opening a door to some sort of template class system?

[AnthonyDGreen]

It is about adapting (and possibly expanding) replace/original to VB. The last iteration of replace/original had just the idea of one method replacing another with no way for user code to opt in to or out of replacement and it was one-directional; generators added code but user code and generators couldn't collaborate.

INotifyPropertyChanged and MVVM would be the key scenario to hit for this feature.

[vbcodec]

Putting Replace/original is wrong way to do AOP. If there is need for example, to measure execution time of methods in hundred classes, then Replace/original requires to create another hundred classes which is ridiculous. Better way to do AOP is to expand CLR and System.Reflection, where we can register our handlers for basic method's execution events: OnEnter, OnFinish and OnError, This will fulfill 99% needs for AOP-ing including INotifyPropertyChanged, measuring time, cal count and any other needs.

[AnthonyDGreen]

Another 100 partial class definitions, actually. That said, replace/original is a bit of a Rube Goldberg approach to profiling. For that you should use the profiler.