Further ideas

This page collects some ideas that could be implemented in the future.

• Dependency management
  Currently the caller has to manage the creation and linking of the mixins on his own. To improve this, mixinSharp could automatically generate the code that is needed to wire up all mixins (e.g. via constructor injection). The user should be able to configure this behavior (e.g. through an options screen). This management could get complicated, if a class uses two or more mixins and these mixins also include each other. In that case, the wiring should be done by a separate method maybe. (This case is skipped as it is quite specific and might not happen too often).

• include method documentation
  If a method or property of a mixin has additional documentation (in the form of a documentation comment), this documentation could also be added to the forwarding method.

• define access specifier Somehow the user could define the access specifier of the forwarding methods, e.g. he could say that some methods should be public while others should only be private or even skipped at all. For this, an additional user interaction dialog would be necessary before the generation.

• remove obsolete member forwarding In case a method is removed from a mixin, it will still be available in the child class and has to be removed manually. This is because mixinSharp currently cannot determine whether the method was created by the user or automatically. By checking the method implementation, it would be possible to identify a forwarding method and remove it if the original method is no longer available in the mixin.

• add region block around forwarding code The generated code that does the method forwarding could be enclosed in a region statement As regions are not everbody's cup of tea, there should be an option to turn this feature on/off.

• add option to avoid line breaks in property accessors There is already an option to turn additional line breaks in property accessors on/off, but at the moment the option is always set to "Avoid line breaks". The options dialog could be extended to let the user choose between these two settings.

• add option to auto subscribe to mixin's events If events are declared in the mixin, the child class could subscribe to these events and fire them whenever the mixin fires them. It would be also good if the child class would set itself as event source instead of the mixin when republishing the event. The generated code could be implemented in the constructor of the child class, e.g.:

  public class ChildClass
  {
     _mixin.PropertyChanged += (s,e) => this.PropertyChanged(this,e);
  }

Especially the sender parameter of the event could be a bit problematic: When should it be replaced? How can we determine which of the parameters is the sender if any (maybe by parameter name and type object / type of mixins seems to be a good identification criteria)