c# Generics Trouble, sub item generics [on hold]












-1














So the following code is just the "summary" of what I am trying to do, and is not the full code. It has been reduced for posting purposes.



This is the event handler and args class definitions that pertain to the issue at hand.



public delegate void IncomingMessageEventHandler<TMsg>(Object sender, IncomingMessageEventArgs args);
public class IncomingMessageEventArgs<TMsg> : EventArgs
{
public TMsg Message { get; private set; }
public IncomingMessageEventArgs(TMsg msg)
{
Message = msg;
}
}


This is the summary of the implementation issuing the problem for me. Again, it's not the full code, just enough to understand the plan I tried to implement, and comments in the code provide the exact error location, and warning message being issued by the IDE.



public class MessageFactory<TMsg>
{
private class MessengerState
{
public Messenger Msger { get; private set; }
public event IncomingMessageEventHandler Message;
public MessengerState(Messenger msger)
{
Msger = msger;
msger.Message += OnMessage;
}
private void OnMessage<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}

private List<MessengerState> _states;

/* ... */

public void MonitorMessenger(Messenger msger)
{
MessengerState state = new MessengerState(msger);
state.Message += this.OnMessengerMsg;
_states.Add(state);
}

/* PROBLEM:
The warning is issued for the <TMsg> part of the following method
definition.

WARNING ISSUED: CS0693 Type parameter 'TMsg' has the same name as the type parameter from the outer type 'MessageFactory<TMsg>'. */
protected void OnMessengerMsg<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}


So I understand that this warning is here for a reason, but in this specific case the protected method is intended to provide inheriting implementations of the MessageFactory type an opportunity to directly process the event, but in addition is used as a pass-through event handler to issue this same event (when required) through it's own Message event. Both would require and use the exact same event signatures due to this implementation.



Should I be simply suppressing the warning in this specific case, disabling the warning prior to the method signature, and re-enabling it after the method in code? Or is there a better way to implement this?



Any help would be appreciated, thanks in advance!










share|improve this question









New contributor




FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as off-topic by t3chb0t, JanDotNet, IEatBagels, Denis, Jamal 2 days ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – t3chb0t, JanDotNet, IEatBagels, Denis, Jamal

If this question can be reworded to fit the rules in the help center, please edit the question.









  • 3




    On Code Review we require the real code, it also has to be complete. If you think this is not necessary and are not actually interested in a review then you should probably try Software Engineering
    – t3chb0t
    2 days ago












  • Either remove the type parameter of the method and use the existing type parameter of the class, or if you need it to be another one, give it another name. In addition, if it must be equal or derived, add a type constraint: protected void OnMessengerMsg<TMsgDrived>(Object sender, IncomingMessageEventArgs<TMsgDrived> args) where TMsgDrived : TMsg
    – Olivier Jacot-Descombes
    2 days ago


















-1














So the following code is just the "summary" of what I am trying to do, and is not the full code. It has been reduced for posting purposes.



This is the event handler and args class definitions that pertain to the issue at hand.



public delegate void IncomingMessageEventHandler<TMsg>(Object sender, IncomingMessageEventArgs args);
public class IncomingMessageEventArgs<TMsg> : EventArgs
{
public TMsg Message { get; private set; }
public IncomingMessageEventArgs(TMsg msg)
{
Message = msg;
}
}


This is the summary of the implementation issuing the problem for me. Again, it's not the full code, just enough to understand the plan I tried to implement, and comments in the code provide the exact error location, and warning message being issued by the IDE.



public class MessageFactory<TMsg>
{
private class MessengerState
{
public Messenger Msger { get; private set; }
public event IncomingMessageEventHandler Message;
public MessengerState(Messenger msger)
{
Msger = msger;
msger.Message += OnMessage;
}
private void OnMessage<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}

private List<MessengerState> _states;

/* ... */

public void MonitorMessenger(Messenger msger)
{
MessengerState state = new MessengerState(msger);
state.Message += this.OnMessengerMsg;
_states.Add(state);
}

/* PROBLEM:
The warning is issued for the <TMsg> part of the following method
definition.

WARNING ISSUED: CS0693 Type parameter 'TMsg' has the same name as the type parameter from the outer type 'MessageFactory<TMsg>'. */
protected void OnMessengerMsg<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}


So I understand that this warning is here for a reason, but in this specific case the protected method is intended to provide inheriting implementations of the MessageFactory type an opportunity to directly process the event, but in addition is used as a pass-through event handler to issue this same event (when required) through it's own Message event. Both would require and use the exact same event signatures due to this implementation.



Should I be simply suppressing the warning in this specific case, disabling the warning prior to the method signature, and re-enabling it after the method in code? Or is there a better way to implement this?



Any help would be appreciated, thanks in advance!










share|improve this question









New contributor




FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as off-topic by t3chb0t, JanDotNet, IEatBagels, Denis, Jamal 2 days ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – t3chb0t, JanDotNet, IEatBagels, Denis, Jamal

If this question can be reworded to fit the rules in the help center, please edit the question.









  • 3




    On Code Review we require the real code, it also has to be complete. If you think this is not necessary and are not actually interested in a review then you should probably try Software Engineering
    – t3chb0t
    2 days ago












  • Either remove the type parameter of the method and use the existing type parameter of the class, or if you need it to be another one, give it another name. In addition, if it must be equal or derived, add a type constraint: protected void OnMessengerMsg<TMsgDrived>(Object sender, IncomingMessageEventArgs<TMsgDrived> args) where TMsgDrived : TMsg
    – Olivier Jacot-Descombes
    2 days ago
















-1












-1








-1







So the following code is just the "summary" of what I am trying to do, and is not the full code. It has been reduced for posting purposes.



This is the event handler and args class definitions that pertain to the issue at hand.



public delegate void IncomingMessageEventHandler<TMsg>(Object sender, IncomingMessageEventArgs args);
public class IncomingMessageEventArgs<TMsg> : EventArgs
{
public TMsg Message { get; private set; }
public IncomingMessageEventArgs(TMsg msg)
{
Message = msg;
}
}


This is the summary of the implementation issuing the problem for me. Again, it's not the full code, just enough to understand the plan I tried to implement, and comments in the code provide the exact error location, and warning message being issued by the IDE.



public class MessageFactory<TMsg>
{
private class MessengerState
{
public Messenger Msger { get; private set; }
public event IncomingMessageEventHandler Message;
public MessengerState(Messenger msger)
{
Msger = msger;
msger.Message += OnMessage;
}
private void OnMessage<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}

private List<MessengerState> _states;

/* ... */

public void MonitorMessenger(Messenger msger)
{
MessengerState state = new MessengerState(msger);
state.Message += this.OnMessengerMsg;
_states.Add(state);
}

/* PROBLEM:
The warning is issued for the <TMsg> part of the following method
definition.

WARNING ISSUED: CS0693 Type parameter 'TMsg' has the same name as the type parameter from the outer type 'MessageFactory<TMsg>'. */
protected void OnMessengerMsg<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}


So I understand that this warning is here for a reason, but in this specific case the protected method is intended to provide inheriting implementations of the MessageFactory type an opportunity to directly process the event, but in addition is used as a pass-through event handler to issue this same event (when required) through it's own Message event. Both would require and use the exact same event signatures due to this implementation.



Should I be simply suppressing the warning in this specific case, disabling the warning prior to the method signature, and re-enabling it after the method in code? Or is there a better way to implement this?



Any help would be appreciated, thanks in advance!










share|improve this question









New contributor




FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











So the following code is just the "summary" of what I am trying to do, and is not the full code. It has been reduced for posting purposes.



This is the event handler and args class definitions that pertain to the issue at hand.



public delegate void IncomingMessageEventHandler<TMsg>(Object sender, IncomingMessageEventArgs args);
public class IncomingMessageEventArgs<TMsg> : EventArgs
{
public TMsg Message { get; private set; }
public IncomingMessageEventArgs(TMsg msg)
{
Message = msg;
}
}


This is the summary of the implementation issuing the problem for me. Again, it's not the full code, just enough to understand the plan I tried to implement, and comments in the code provide the exact error location, and warning message being issued by the IDE.



public class MessageFactory<TMsg>
{
private class MessengerState
{
public Messenger Msger { get; private set; }
public event IncomingMessageEventHandler Message;
public MessengerState(Messenger msger)
{
Msger = msger;
msger.Message += OnMessage;
}
private void OnMessage<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}

private List<MessengerState> _states;

/* ... */

public void MonitorMessenger(Messenger msger)
{
MessengerState state = new MessengerState(msger);
state.Message += this.OnMessengerMsg;
_states.Add(state);
}

/* PROBLEM:
The warning is issued for the <TMsg> part of the following method
definition.

WARNING ISSUED: CS0693 Type parameter 'TMsg' has the same name as the type parameter from the outer type 'MessageFactory<TMsg>'. */
protected void OnMessengerMsg<TMsg>(Object sender, IncomingMessageEventArgs<TMsg> args)
{
Message?.Invoke(sender, args);
}
}


So I understand that this warning is here for a reason, but in this specific case the protected method is intended to provide inheriting implementations of the MessageFactory type an opportunity to directly process the event, but in addition is used as a pass-through event handler to issue this same event (when required) through it's own Message event. Both would require and use the exact same event signatures due to this implementation.



Should I be simply suppressing the warning in this specific case, disabling the warning prior to the method signature, and re-enabling it after the method in code? Or is there a better way to implement this?



Any help would be appreciated, thanks in advance!







c# generics






share|improve this question









New contributor




FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 2 days ago









Olivier Jacot-Descombes

2,5981217




2,5981217






New contributor




FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 2 days ago









FSGFSG

1




1




New contributor




FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






FSG is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




put on hold as off-topic by t3chb0t, JanDotNet, IEatBagels, Denis, Jamal 2 days ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – t3chb0t, JanDotNet, IEatBagels, Denis, Jamal

If this question can be reworded to fit the rules in the help center, please edit the question.




put on hold as off-topic by t3chb0t, JanDotNet, IEatBagels, Denis, Jamal 2 days ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – t3chb0t, JanDotNet, IEatBagels, Denis, Jamal

If this question can be reworded to fit the rules in the help center, please edit the question.








  • 3




    On Code Review we require the real code, it also has to be complete. If you think this is not necessary and are not actually interested in a review then you should probably try Software Engineering
    – t3chb0t
    2 days ago












  • Either remove the type parameter of the method and use the existing type parameter of the class, or if you need it to be another one, give it another name. In addition, if it must be equal or derived, add a type constraint: protected void OnMessengerMsg<TMsgDrived>(Object sender, IncomingMessageEventArgs<TMsgDrived> args) where TMsgDrived : TMsg
    – Olivier Jacot-Descombes
    2 days ago
















  • 3




    On Code Review we require the real code, it also has to be complete. If you think this is not necessary and are not actually interested in a review then you should probably try Software Engineering
    – t3chb0t
    2 days ago












  • Either remove the type parameter of the method and use the existing type parameter of the class, or if you need it to be another one, give it another name. In addition, if it must be equal or derived, add a type constraint: protected void OnMessengerMsg<TMsgDrived>(Object sender, IncomingMessageEventArgs<TMsgDrived> args) where TMsgDrived : TMsg
    – Olivier Jacot-Descombes
    2 days ago










3




3




On Code Review we require the real code, it also has to be complete. If you think this is not necessary and are not actually interested in a review then you should probably try Software Engineering
– t3chb0t
2 days ago






On Code Review we require the real code, it also has to be complete. If you think this is not necessary and are not actually interested in a review then you should probably try Software Engineering
– t3chb0t
2 days ago














Either remove the type parameter of the method and use the existing type parameter of the class, or if you need it to be another one, give it another name. In addition, if it must be equal or derived, add a type constraint: protected void OnMessengerMsg<TMsgDrived>(Object sender, IncomingMessageEventArgs<TMsgDrived> args) where TMsgDrived : TMsg
– Olivier Jacot-Descombes
2 days ago






Either remove the type parameter of the method and use the existing type parameter of the class, or if you need it to be another one, give it another name. In addition, if it must be equal or derived, add a type constraint: protected void OnMessengerMsg<TMsgDrived>(Object sender, IncomingMessageEventArgs<TMsgDrived> args) where TMsgDrived : TMsg
– Olivier Jacot-Descombes
2 days ago












0






active

oldest

votes

















0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes

Popular posts from this blog

Сан-Квентин

Алькесар

Josef Freinademetz