Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>My educated guess would be to make things operate like the built in types in .NET do, namely that == should work like reference equality where possible, and that Equals should work like value equality where possible. Consider the actual difference between <code>==</code> and <code>Equals</code>:</p> <pre><code>object myObj = new Integer(4); object myObj2 = new Integer(4); //Note that == is only called if the ref'd objects are cast as a type //overloading it. myObj == myObj2; //False (???) myObj.Equals(myObj2); //True (This call is virtual) //Set the references equal to each other -- note that the operator== //comparison now works. myObj2 = myObj; myObj == myObj2; //True myObj.Equals(myObj2); //True </code></pre> <p>This behavior is of course inconsistent and confusing, particularly to new programmers -- but it demonstrates the difference between reference comparisons and value comparisons.</p> <p>If you follow this MSDN guideline, you are following the guideline taken by important classes such as string. Basically -- if a comparison using <code>==</code> succeeds, the programmer knows that that comparison will always succeed, so long as the references involved don't get assigned to new objects. The programmer need never worry about the contents of the objects being different, because they never will be different:</p> <pre><code>//Mutable type var mutable1 = new Mutable(1); var mutable2 = mutable1; mutable1 == mutable2; //true mutable1.MutateToSomethingElse(56); mutable1 == mutable2; //still true, even after modification //This is consistent with the framework. (Because the references are the same, //reference and value equality are the same.) Consider if == were overloaded, //and there was a difference between reference and value equality: var mutable1 = new Mutable(1); var mutable2 = new Mutable(1); mutable1 == mutable2; //true mutable1.MutateToSomethingElse(56); mutable1 == mutable2; //oops -- not true anymore //This is inconsistent with, say, "string", because it cannot mutate. </code></pre> <p>It boils down to that there's no real technical reason for the guideline -- it's just to remain consistent with the rest of the classes in the framework.</p>
    singulars
    1. This table or related slice is empty.
    1. POOverriding the == operator in non-immutable types
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USBilly ONeal
    1. USBilly ONeal
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POOverriding the == operator in non-immutable types
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1 this is clearly the answer
      singulars
      1. PO
      1. USDavid Heffernan
    2. COVery well thought out good answer.
      singulars
      1. PO
      1. USjason
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload