Ayende @ Rahien

Colin Jack commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Thu, 20 Sep 2007 15:03:54 GMT

Yeah Microsoft Connect is useless, when bugs are closed you get no feedback. The whole approach seems to be completely broken and I've given up on reporting things. I agree don't think open source is the solution either though, I've logged plenty of bugs/feature suggestions in open source projects and not really gotten much feedback. I can understand why but and I guess I could do the change myself...

Ayende Rahien commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Thu, 20 Sep 2007 05:41:02 GMT

Rhino Mocks should works well on Mono 1.2.5

Pedro Teixeira commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Thu, 20 Sep 2007 01:16:38 GMT

Have you tried calling them directly as it's suggest? You could probably try commenting on CLR developers' blog to get better feedback (not sure if it'll help). Rhino Mocks is really an amazing piece of software. Does it also happen in Mono? I'm just crossing my fingers not to step into such runtime exceptions - otherwise I might have to run my tests on linux :p

Fabian Schmied commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Wed, 19 Sep 2007 11:38:56 GMT

Luke: If the CLR were required to be smart enough to figure out that the constraint fits, it would be a verifier bug. Otherwise, it is a bug in the C# compiler, because the compiler shouldn't assume the CLR was smart enough. All: The links above aren't actually related to RhinoMocks, see the RhinoMocks group (http://groups.google.com/group/RhinoMocks/browse_thread/thread/e0307787e810fde7?hl=en). However, I'm also often annoyed at bugs being closed without any further information, especially as "By Design". That's just not satisfying at all, and it rather discourages people from reporting bugs in the first place. I wonder whether there is a place to lobby for better feedback... I mean, the first stage of Connect works alright - the bugs I've reported so far are usually reproduced/acknowledged and sent to the appropriate group in a few day, sometimes even hours. If there's something missing, I get contacted and asked for more details - that's all great. But as soon as the bug has been forwarded to the group, the flow of feedback stops all too often.

Samir commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Wed, 19 Sep 2007 11:38:03 GMT

Some WCF, that i found out in the net ... :) http://sendhil.spaces.live.com/Blog/cns!30862CF919BD131A!927.entry

Luke Breuer commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Wed, 19 Sep 2007 10:13:59 GMT

The constraint _should be_ T2 : List, but you have it as T2: List, ICollection. As I pointed out above, theoretically this ICollection should not affect anything as List implements it, but the CLR isn't smart enough to figure this out. I argue this isn't necessarily a terrible thing, as the IL-emitting code could remove superfluous constraints and/or match exactly the constraint found in the generic interface definition.

Ayende Rahien commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Wed, 19 Sep 2007 06:49:57 GMT

Luke, The constraint is for T2 : T, where T is List It is not on T2 : T where T : IEnumerable, because you already have defined T to be list

Luke Breuer commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Tue, 18 Sep 2007 21:45:36 GMT

Your code should produce a StackOverflowException not because you tried to implement a generic interface method with stronger constraints than the interface definition, but because the CLR does not recognize that ICollection is implemented by List, so adding ICollection doesn't actually change the constraint. However, the spec seems to indicate that neither the compiler nor the CLR does this. The spec says "When a generic method implicitly implements an interface method, the constraints given for each method type parameter shall be equivalent in both declarations...": http://en.csharp-online.net/ECMA-334:_25.6.2_Virtual_generic_methods Why is this necessarily bad design/a bug? Requiring the CLR to determine that ICollection can be ignored because List implements it seems unnecessary work that can be done statically by the programmer or, in your case, the person emitting IL. Am I missing something?

Michael Morton commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Tue, 18 Sep 2007 21:43:40 GMT

@LukeB Unfortunately that is not the perfect argument. Just because you are able to find a bug in an open source project doesn't mean you will be able to fix it. And even if you are able to fix it, your "fix" may introduce other bugs because you don't have a complete understanding of the code base (something that someone working with it day to day would have). So, let's say that you don't have the skill to fix it, or don't have the time to go over the code-base to fix it properly and instead you ask the people working on the project to fix it. They may or may not see the bug as the same priority as you do. Just because it is a critical issue for you, doesn't mean it is for the 99% of the other people using the project. And besides, they might be buried at work this month and not be able to get to any of the bugs, cause let's face it, a lot of the best projects out there are done by people in their spare time. For the sake of brevity we won't get into what happens when the maintainers get burned out. And with that, unless you are able to fix the problem correctly and *have* the time to do so, you are really left in the same boat as with closed source software. At least with closed source software, more often then not, there are people that are *paid* to maintain it and to support it. It's their job day in day out. I'm not saying that closed source software is better than open and I'm not saying that open source software is better than closed... It's just software and all software is going to have problems that you may or may not be able to get fixed, either by your hand or by involving another party. That's just the way it is. Throwing around "open source software" as the "fix all" to all software bugs will only lead one to trouble. No software is perfect... It's all written by humans in one way or another.

LukeB commented on Microsoft Connect: Redefining bugs as features as a standard operation procedure

Tue, 18 Sep 2007 20:04:39 GMT

Here is the perfect argument for staying away from closed-source software. Not only have you found the bug, are able to reproduce it, I don't doubt that you could fix it as well. It's just that you can't.