Trick for young players.
-
If I may be clear, I understand what is happening and why - the fact remains it is an inconsistency. If each object had two booleans, would it act the same? As an'outside observer' the behavior is inconsistent. In the case where this came up, the framework was processing parameters passed to a constructor, and trying to find the best constructor to use based on the parameters. The routine in question failed if two booleans were passed because e second was deemed to be the same parameter as the first when their values were equal. Because this is a framework, and until now nobody had happened to write a constructor with multiple value types of the same type, and subsequently try to use it with those value types having the same value, nobody had noticed the issue. If lit had been integers rather than booleans it would have been even more interesting - as the chances of the values also being equal wold be that much smaller. So, I under stand what is happening, but I still regard this as an issue with the potential for causing larger problems I an application. The fact that the Contains method works inconsistently depending on the contents of objects is the problem. I ask 'does object a contain object b' And I expect the answer to be yes or no - and not 'well, if it's an object containing only a value type, then the collection contains at least one similar Object where the value type has the same value, but if it's a reference type then that instance exists I the collection' This means in principal that I need to know about the objects in any collection beforehand - which especially in a framework environment, I do not.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_Maxxx_ wrote:
If each object had two booleans, would it act the same?
Depends if it's a value type, and whether Equals is overridden.
_Maxxx_ wrote:
The fact that the Contains method works inconsistently depending on the contents of objects is the problem.
It does not behave differently depending on the contents. It depends differently depending on the type. You can think of it like string interning: there is only one false so when you have two of them, they are always equal, both in value terms and in reference terms. I think this is true for all value types; it's certainly true for all basic types.
_Maxxx_ wrote:
And I expect the answer to be yes or no - and not 'well, if it's an object containing only a value type, then the collection contains at least one similar Object where the value type has the same value, but if it's a reference type then that instance exists I the collection'
The answer is yes if there is an object in the collection for which Equals with the one you've passed returns true. That's what equality means, and it's usually much more useful than checking for reference equality. You can override == on custom types to make that check whatever you want. By default the behaviour is to check references for reference types and to check values for value types (or at least base types). Choosing which constructor to use based on the values of parameters, instead of the types of parameters, is a WTF all to itself. Edit: Equals, not ==. I always override both of these, and also !=, if I do either, so I get them mixed up sometimes.
-
I used to think that some years ago - couldn't see the point; until I started using them - and fell in love!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Look at the prog below - a collection has one(object)bool in it. And I want to find out if one of them exists in the collection. Using collection.Contains() would seem like a good idea. But isn't!
class Program
{
static void Main(string[] args)
{
object arg1 = true;
object arg2 = true;List<object> collection = new List<object>() { arg1 }; bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2)); Console.WriteLine(string.Format("{0} {1}", first, second)); first = false; second = false; for (int i = 0; i < collection.Count; i++) { if (collection\[i\] == arg1) { first = true; } if (collection\[i\] == arg2) { second = true; } } Console.WriteLine(string.Format("{0} {1}", first, second)); Console.ReadKey(); } }MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Gotta love ReSharper
static void Main()
{
object arg1 = true;
object arg2 = true;var collection = new List<object> { arg1 }; var first = (collection.Contains(arg1)); var second = (collection.Contains(arg2)); Console.WriteLine("{0} {1}", first, second); foreach (var t in collection) { //Do fuck all } Console.WriteLine("{0} {1}", false, false); Console.ReadKey();}
-
_Maxxx_ wrote:
If each object had two booleans, would it act the same?
Depends if it's a value type, and whether Equals is overridden.
_Maxxx_ wrote:
The fact that the Contains method works inconsistently depending on the contents of objects is the problem.
It does not behave differently depending on the contents. It depends differently depending on the type. You can think of it like string interning: there is only one false so when you have two of them, they are always equal, both in value terms and in reference terms. I think this is true for all value types; it's certainly true for all basic types.
_Maxxx_ wrote:
And I expect the answer to be yes or no - and not 'well, if it's an object containing only a value type, then the collection contains at least one similar Object where the value type has the same value, but if it's a reference type then that instance exists I the collection'
The answer is yes if there is an object in the collection for which Equals with the one you've passed returns true. That's what equality means, and it's usually much more useful than checking for reference equality. You can override == on custom types to make that check whatever you want. By default the behaviour is to check references for reference types and to check values for value types (or at least base types). Choosing which constructor to use based on the values of parameters, instead of the types of parameters, is a WTF all to itself. Edit: Equals, not ==. I always override both of these, and also !=, if I do either, so I get them mixed up sometimes.
BobJanova wrote:
Depends if it's a value type, and whether Equals is overridden.
Not sure I even follow you there. An object with two boolean properties is not a value type - or am I misunderstanding you?
BobJanova wrote:
and it's usually much more useful than checking for reference equality.
I have to disagree there, and say it entirely depends on the context. If I want to check if two objects are the same object, i would like to be able to do so in a consistent manner, without having to check to see if the object is a value-type wrapper. similarly, if I want to check if the value of two objects are the same, I would expect to be able to use the same methods regardless as to whether the objects in question have booleans or Customers internally. I reiterate - I understand exactly what is happening, and it is a trick for young players (hence the post). But I still think that there is an inherent (pun absolutely intended) discrepancy n the handling of boxed objects vs the handling of 'vanilla' objects.
BobJanova wrote:
Choosing which constructor to use based on the values of parameters, instead of the types of parameters, is a WTF all to itself.
The AIM of the method in question was was to decide on the constructor based upon the TYPES of parameter vs TYPES of arguments. The parameters were in a collection and the arguments in another.
1. For Each parameter in the constructor it is checking
2. For each argument in the collection
3. If THIS ARGUMENT is already in our output collection, continue
4. If this argument is of the same type (or subtype etc) as the current parameter, add it to the output collection
5. Next Argument
6. Next parameterLine 3 is where the issue arises, because if there are two value arguments, and they both have the same runtime value, then this If is triggered and the argument ignored for the 2nd and subsequent parameter.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
== resolves to System.Object.ReferenceEquals while contains determines equality by using the default equality comparer, as defined by the object's implementation.
People say nothing is impossible, but I do nothing every day.
That's exactly the opposite of what would seem reasonable to me.
-
BobJanova wrote:
Depends if it's a value type, and whether Equals is overridden.
Not sure I even follow you there. An object with two boolean properties is not a value type - or am I misunderstanding you?
BobJanova wrote:
and it's usually much more useful than checking for reference equality.
I have to disagree there, and say it entirely depends on the context. If I want to check if two objects are the same object, i would like to be able to do so in a consistent manner, without having to check to see if the object is a value-type wrapper. similarly, if I want to check if the value of two objects are the same, I would expect to be able to use the same methods regardless as to whether the objects in question have booleans or Customers internally. I reiterate - I understand exactly what is happening, and it is a trick for young players (hence the post). But I still think that there is an inherent (pun absolutely intended) discrepancy n the handling of boxed objects vs the handling of 'vanilla' objects.
BobJanova wrote:
Choosing which constructor to use based on the values of parameters, instead of the types of parameters, is a WTF all to itself.
The AIM of the method in question was was to decide on the constructor based upon the TYPES of parameter vs TYPES of arguments. The parameters were in a collection and the arguments in another.
1. For Each parameter in the constructor it is checking
2. For each argument in the collection
3. If THIS ARGUMENT is already in our output collection, continue
4. If this argument is of the same type (or subtype etc) as the current parameter, add it to the output collection
5. Next Argument
6. Next parameterLine 3 is where the issue arises, because if there are two value arguments, and they both have the same runtime value, then this If is triggered and the argument ignored for the 2nd and subsequent parameter.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_Maxxx_ wrote:
An object with two boolean properties is not a value type
Depends whether you want it to be.
struct MyType { public bool a, b; } // value type
class MyType { public bool a, b; } // reference type_Maxxx_ wrote:
If I want to check if two objects are the same object, i would like to be able to do so in a consistent manner, without having to check to see if the object is a value-type wrapper. similarly, if I want to check if the value of two objects are the same, I would expect to be able to use the same methods
You can. ReferenceEquals and ==/Equals respectively. Contains is defined to use Equals not ReferenceEquals because that's almost always what you want when there is a difference.
_Maxxx_ wrote:
The AIM of the method in question was was to decide on the constructor based upon the TYPES of parameter vs TYPES of arguments.
Then why is it using the values? Capital letters don't change what you are actually coding (or what your pseudo-code does). Line 3 is where the issue arises because you shouldn't be doing that; the value of an argument is irrelevant to the parameter matching to find a method.
-
_Maxxx_ wrote:
An object with two boolean properties is not a value type
Depends whether you want it to be.
struct MyType { public bool a, b; } // value type
class MyType { public bool a, b; } // reference type_Maxxx_ wrote:
If I want to check if two objects are the same object, i would like to be able to do so in a consistent manner, without having to check to see if the object is a value-type wrapper. similarly, if I want to check if the value of two objects are the same, I would expect to be able to use the same methods
You can. ReferenceEquals and ==/Equals respectively. Contains is defined to use Equals not ReferenceEquals because that's almost always what you want when there is a difference.
_Maxxx_ wrote:
The AIM of the method in question was was to decide on the constructor based upon the TYPES of parameter vs TYPES of arguments.
Then why is it using the values? Capital letters don't change what you are actually coding (or what your pseudo-code does). Line 3 is where the issue arises because you shouldn't be doing that; the value of an argument is irrelevant to the parameter matching to find a method.
BobJanova wrote:
Then why is it using the values?
It's not. It's using contains in an attempt to determine if the collection contains the object it is looking at. As it turns out, a (very small minority) of the objects are boxed value types, and an even smaller number of these have the same value, and so 'break' the code. The fact that Contains uses the values rather than comparing object references is exactly the cause of confusion. Asking why is it using values is like asking someone who has accidentally shot off their toe "why did you fire the gun at your foot?"
BobJanova wrote:
Capital letters don't change what you are actually coding
Actually they do in C#, which is case sensitive ')
BobJanova wrote:
(or what your pseudo-code does).
The capitals were there for emphasis and to help understand which bits I was TALKING about
BobJanova wrote:
Line 3 is where the issue arises because you shouldn't be doing that;
No shit, Sherlock? I know that is the bit that's causing the problem.
BobJanova wrote:
the value of an argument is irrelevant to the parameter matching to find a method.
Yes - and as I said, the AIM of the code was to check for the presence of the argument, not its value. I capitalised there for emphasis
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Look at the prog below - a collection has one(object)bool in it. And I want to find out if one of them exists in the collection. Using collection.Contains() would seem like a good idea. But isn't!
class Program
{
static void Main(string[] args)
{
object arg1 = true;
object arg2 = true;List<object> collection = new List<object>() { arg1 }; bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2)); Console.WriteLine(string.Format("{0} {1}", first, second)); first = false; second = false; for (int i = 0; i < collection.Count; i++) { if (collection\[i\] == arg1) { first = true; } if (collection\[i\] == arg2) { second = true; } } Console.WriteLine(string.Format("{0} {1}", first, second)); Console.ReadKey(); } }MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
I think the point is... Why would you ever need more than one instance of true or false? The boxing must create a new instance. New instance means more overhead. SmallTalk has a great answer for this: abstract class Boolean {...} class True extends: Boolean { // singleton } class False extends: Boolean { // singleton } You can imagine how easy it is to implement all of the logical operators with this construct! True.OR(Boolean that) { return this; } True.AND(Boolean that) { return that; } False.OR(Boolean that) { return that; } False.AND(Boolean that) { return this; }
-
BobJanova wrote:
Depends if it's a value type, and whether Equals is overridden.
Not sure I even follow you there. An object with two boolean properties is not a value type - or am I misunderstanding you?
BobJanova wrote:
and it's usually much more useful than checking for reference equality.
I have to disagree there, and say it entirely depends on the context. If I want to check if two objects are the same object, i would like to be able to do so in a consistent manner, without having to check to see if the object is a value-type wrapper. similarly, if I want to check if the value of two objects are the same, I would expect to be able to use the same methods regardless as to whether the objects in question have booleans or Customers internally. I reiterate - I understand exactly what is happening, and it is a trick for young players (hence the post). But I still think that there is an inherent (pun absolutely intended) discrepancy n the handling of boxed objects vs the handling of 'vanilla' objects.
BobJanova wrote:
Choosing which constructor to use based on the values of parameters, instead of the types of parameters, is a WTF all to itself.
The AIM of the method in question was was to decide on the constructor based upon the TYPES of parameter vs TYPES of arguments. The parameters were in a collection and the arguments in another.
1. For Each parameter in the constructor it is checking
2. For each argument in the collection
3. If THIS ARGUMENT is already in our output collection, continue
4. If this argument is of the same type (or subtype etc) as the current parameter, add it to the output collection
5. Next Argument
6. Next parameterLine 3 is where the issue arises, because if there are two value arguments, and they both have the same runtime value, then this If is triggered and the argument ignored for the 2nd and subsequent parameter.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_Maxxx_ wrote:
An object with two boolean properties is not a value type
Depends on the type of the object and what you mean by "object". Here's a variation on your original post:
using System;
namespace ClassVsStruct
{
class Program
{
class CBool
{
public bool Value1;
public bool Value2;
}struct SBool { public bool Value1; public bool Value2; } static void Main(string\[\] args) { var c1 = new CBool { Value1 = true, Value2 = true }; var c2 = new CBool { Value1 = true, Value2 = true }; Console.WriteLine("Equals: {0}", c1.Equals(c2)); var s1 = new SBool { Value1 = true, Value2 = true }; var s2 = new SBool { Value1 = true, Value2 = true }; Console.WriteLine("Equals: {0}", s1.Equals(s2)); } }}
-
Look at the prog below - a collection has one(object)bool in it. And I want to find out if one of them exists in the collection. Using collection.Contains() would seem like a good idea. But isn't!
class Program
{
static void Main(string[] args)
{
object arg1 = true;
object arg2 = true;List<object> collection = new List<object>() { arg1 }; bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2)); Console.WriteLine(string.Format("{0} {1}", first, second)); first = false; second = false; for (int i = 0; i < collection.Count; i++) { if (collection\[i\] == arg1) { first = true; } if (collection\[i\] == arg2) { second = true; } } Console.WriteLine(string.Format("{0} {1}", first, second)); Console.ReadKey(); } }MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
First one its checking for true and in the second one its comparing the actual object and not the value of the object, you'd think they'd both be "true true"
-
First one its checking for true and in the second one its comparing the actual object and not the value of the object, you'd think they'd both be "true true"
Mathlab wrote:
you'd think they'd both be "true true"
Been watchin' the true-true in theaters?
-
Look at the prog below - a collection has one(object)bool in it. And I want to find out if one of them exists in the collection. Using collection.Contains() would seem like a good idea. But isn't!
class Program
{
static void Main(string[] args)
{
object arg1 = true;
object arg2 = true;List<object> collection = new List<object>() { arg1 }; bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2)); Console.WriteLine(string.Format("{0} {1}", first, second)); first = false; second = false; for (int i = 0; i < collection.Count; i++) { if (collection\[i\] == arg1) { first = true; } if (collection\[i\] == arg2) { second = true; } } Console.WriteLine(string.Format("{0} {1}", first, second)); Console.ReadKey(); } }MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
The problem is that the Contains() method implements the equality method defined in the object type contained in the collection. As object only has an equals that tests whether or not two value types have the same value (or two reference types point to the same object), which arg1 and arg2 do, the equality test returns true. That is it considers arg1 and arg2 to be identical. The Contains() method should be used for collection objects that implement the IEquatable interface Equals method. This way we can ensure that the correct behaviour for an equality test results. We could, for example, wrap the booleans in objects of a class that does this. That's what I think, but I only program for a hobby so I could be talking rubbish.
anonymous Bot
-
I think the point is... Why would you ever need more than one instance of true or false? The boxing must create a new instance. New instance means more overhead. SmallTalk has a great answer for this: abstract class Boolean {...} class True extends: Boolean { // singleton } class False extends: Boolean { // singleton } You can imagine how easy it is to implement all of the logical operators with this construct! True.OR(Boolean that) { return this; } True.AND(Boolean that) { return that; } False.OR(Boolean that) { return that; } False.AND(Boolean that) { return this; }
Yep - eiffel (from what I remember in my uni days) treats everything as an object - which means there is never any confusion. While I understand the reasons for differentiating between value an reference types, if all types are reference types, then there's no issue as long as the meanings of 'equals' and == etc. are clear. I've sometimes thought about developing a small application using only classes - e.g. create an Int class, a Bool class etc. A lot of work to develop the framework - but it would be an interesting exercise - maybe next time I teach a senior IT class it could be their end of term project ;)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Try this:
Sub Main() Dim arg1 As Object = True Dim arg2 As Object = True Dim collection As New List(Of Object)() From { \_ arg1 \_ } Dim first As Boolean = (collection.Contains(arg1)) Dim second As Boolean = (collection.Contains(arg2)) Console.WriteLine(String.Format("{0} {1}", first, second)) first = False second = False For i As Integer = 0 To collection.Count - 1 If collection(i) = arg1 Then first = True End If If collection(i) = arg2 Then second = True End If Next Console.WriteLine(String.Format("{0} {1}", first, second)) Console.ReadKey() End SubAt least it's consistent. :-D
People say nothing is impossible, but I do nothing every day.
LOL - I am genuinely crying (with a little laughter and a lot of WTF!)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
_Maxxx_ wrote:
An object with two boolean properties is not a value type
Depends on the type of the object and what you mean by "object". Here's a variation on your original post:
using System;
namespace ClassVsStruct
{
class Program
{
class CBool
{
public bool Value1;
public bool Value2;
}struct SBool { public bool Value1; public bool Value2; } static void Main(string\[\] args) { var c1 = new CBool { Value1 = true, Value2 = true }; var c2 = new CBool { Value1 = true, Value2 = true }; Console.WriteLine("Equals: {0}", c1.Equals(c2)); var s1 = new SBool { Value1 = true, Value2 = true }; var s2 = new SBool { Value1 = true, Value2 = true }; Console.WriteLine("Equals: {0}", s1.Equals(s2)); } }}
Yeah - my bad - when I said object I really meant class.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
LOL - I am genuinely crying (with a little laughter and a lot of WTF!)
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Just pulling your leg a little bit. Shorthand for
ReferenceEqualsin VB.Net isIS.=is the shorthand forEquals. So the VB code wasn't the same as your C# code. :) I'v seen this error a few times in code that's been converted between VB and C#. C#==is not the same as VB=, but oh so easy to miss if you only know one of the languages. Should add that this is a standard error in all automatic converters I've tried.People say nothing is impossible, but I do nothing every day.
-
Look at the prog below - a collection has one(object)bool in it. And I want to find out if one of them exists in the collection. Using collection.Contains() would seem like a good idea. But isn't!
class Program
{
static void Main(string[] args)
{
object arg1 = true;
object arg2 = true;List<object> collection = new List<object>() { arg1 }; bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2)); Console.WriteLine(string.Format("{0} {1}", first, second)); first = false; second = false; for (int i = 0; i < collection.Count; i++) { if (collection\[i\] == arg1) { first = true; } if (collection\[i\] == arg2) { second = true; } } Console.WriteLine(string.Format("{0} {1}", first, second)); Console.ReadKey(); } }MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
I used this article for reference: link
object arg1 = true;
object arg2 = true;
List<object> collection = new List<object>() { arg1 };The keyword object doesnt make 'arg1' or 'arg2' a reference type, they are both value types. And as the article clearly states "If the current instance is a value type, the Equals(Object) method tests for value equality. Value equality means the following: 1.The two objects are of the same type. 2.The values of the public and private fields of the two objects are equal." when checking
bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2));as both the conditions are satisfied obviously 'Contains' will return true. As i understand this is exactly the same as doing
int a = 1; int b = 1; List intcollection = new List() {a }; bool first = (intcollection.Contains(a)); bool second = (intcollection.Contains(b)); Console.WriteLine(string.Format("{0} {1}", first, second));in which case we all agree that 'True True' is the output. I think the confusion occurs because of the tendency to assume object arg1 and object arg2 as reference types. I understand this can cause confusion and bigger underlying problems in a framework scenario but the only reason(AFAIK) causing this is whoever coded it dint realize this beforehand. but i appreciate this post as I know I would never have come across such a ascenario in years.Please feel free to correct me if I am wrong as I am one of the young players only :-).
-
Just pulling your leg a little bit. Shorthand for
ReferenceEqualsin VB.Net isIS.=is the shorthand forEquals. So the VB code wasn't the same as your C# code. :) I'v seen this error a few times in code that's been converted between VB and C#. C#==is not the same as VB=, but oh so easy to miss if you only know one of the languages. Should add that this is a standard error in all automatic converters I've tried.People say nothing is impossible, but I do nothing every day.
And then people complain about the confusing use of pointers and pointees in C/C++ ...
-
And then people complain about the confusing use of pointers and pointees in C/C++ ...
Pointers and Pointees have a point, but in 95% of the cases the compiler would do a better job in handling it for you, and you can concentrate on the programming instead. Just my 2c.
People say nothing is impossible, but I do nothing every day.
-
I used this article for reference: link
object arg1 = true;
object arg2 = true;
List<object> collection = new List<object>() { arg1 };The keyword object doesnt make 'arg1' or 'arg2' a reference type, they are both value types. And as the article clearly states "If the current instance is a value type, the Equals(Object) method tests for value equality. Value equality means the following: 1.The two objects are of the same type. 2.The values of the public and private fields of the two objects are equal." when checking
bool first = (collection.Contains(arg1)); bool second = (collection.Contains(arg2));as both the conditions are satisfied obviously 'Contains' will return true. As i understand this is exactly the same as doing
int a = 1; int b = 1; List intcollection = new List() {a }; bool first = (intcollection.Contains(a)); bool second = (intcollection.Contains(b)); Console.WriteLine(string.Format("{0} {1}", first, second));in which case we all agree that 'True True' is the output. I think the confusion occurs because of the tendency to assume object arg1 and object arg2 as reference types. I understand this can cause confusion and bigger underlying problems in a framework scenario but the only reason(AFAIK) causing this is whoever coded it dint realize this beforehand. but i appreciate this post as I know I would never have come across such a ascenario in years.Please feel free to correct me if I am wrong as I am one of the young players only :-).
TheCoolCoder wrote:
whoever coded it dint realize this beforehand.
in fact, when the framework was written, I think there were only a very limited number of objects that were intended to be passed - and all of these would have been reference objects. So, not necessarily that he didn't realise it, but more that he didn't consider anyone might try to pass a bunch of booleans!
TheCoolCoder wrote:
the tendency to assume object arg1 and object arg2 as reference types.
Spot on! Looked at in isolation, that is exactly what most people assume (myself included!). This would be a great example of where TDD would possibly have been useful - as in setting up tests with a variety of parameter types, this issue may have been spotted before going into production!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')