Code Puzzler: How quickly can you figure out why this acting "weird"?

[Marc Clifton]

Richard Deeming wrote:

select the block to view:

Now THAT is snazzy!

Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802

[Marc Clifton]

Richard Deeming wrote:

But it won't work, in the sense that the returned instance will be using the default connection string for the context, not the connection string from the instance passed in.

Hmm. But the parameterless constructor uses the connection string of the (hopefully) already initialized context: public ModelDataContext() : base(Context.Connection) However, it's a moot point anyways as I refactored the whole mess into something much less weird. It'll be an interesting question though to pose to a couple of the devs at work, though I'll reduce the complexity of it omitting the DataContext base class - it's rather superfluous to the example.

Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802

[Richard Deeming]

OK, so it's not quite as bad as I though. :) You could still break it though:

var context1 = new ModelDataContext(new SqlConnection("server=A;database=B"));
var context2 = new ModelDataContext(new SqlConnection("server=C;database=D"));

CreateNewContext(context1, out var newConn, out var newContext);

// As expected:
Console.WriteLine(newConn.ConnectionString == context1.Connection.ConnectionString); // True

// Not as expected:
Console.WriteLine(newContext.Connection.ConnectionString == context1.Connection.ConnectionString); // False
Console.WriteLine(newContext.Connection.ConnectionString == newConn.ConnectionString); // False
Console.WriteLine(newContext.Connection == newConn); // False

// Also not as expected:
Console.WriteLine(newContext.Connection.ConnectionString == context2.Connection.ConnectionString); // True

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[Mike Hankey]

I also see what I meant to write as opposed to what I actually wrote. I've been tired and looked at two spellings of same word and get compiler errors and don't spot the error for some time.

Everyone has a photographic memory; some just don't have film. Steven Wright

[OriginalGriff]

Annoying, isn't it? :-D

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!

[Mike Hankey]

Yes very frustrating. As I get older it seems to be more prevalent.

Everyone has a photographic memory; some just don't have film. Steven Wright

[Marc Clifton]

Richard Deeming wrote:

You could still break it though:

Yeah, but it's never used that way - two different connection strings. But ideally, it shouldn't be possible to use it that way. Sigh. The irony of this is that it's code I wrote a while back that my DataContext extension methods rely on, and looking at this now, it's some serious code smell. Fortunately, fixing it affects only a couple web servers that are in operation, but I feel embarrassed. But I blame .NET's DataContext. :laugh: It does way to much with regards to the state of the Table object. I get what they're trying to do, but there must be a better way that doesn't end up throwing exceptions like "this object was created in a different data context."

Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802

[soulesurfer]

The reason for the results are pretty obvious, when a new instance is created in "CreateNewContext", the parameter "context" is still referring to the original context, not the new one ==> false; When the main program does the compare afterwards, the comparison is done to the static that holds the new context ==> true. Fixing this is not obvious because you didn't specify what the correct behavior should be. Do you wish it to be "True" always, or "False" always :) Simply update the context parameter in the method to get True always, but I would personally recommend to re-write this whole thing, it is full of code smells. Perhaps some practice in TDD would also be helpful. Cheers, Anthony

[englebart]

It took about a minute to solve. Assigning over the static for each constructor call is a WTF (as others have called out). Way too many statics in this Program, if it was rewritten to eliminate all of the statics, then the Program instance would hold a single context and the Main would look like this:

Main(...)
{
new Program().Run();
}

If new instances of the "context" are really needed, then create a Copy constructor to reuse the default context settings on a new instance. Or use your favorite IOC container.

[User 11542641]

OriginalGriff wrote:

I tend to see what I meant to write, rather than what I did

Yup that's me! As an answer: I haven't gone further in the thread, but at first glance the FALSE comes from comparing 2 different instances, where the TRUE result is comparing the same instance to itself? Fix: the first comparison is not necessary

[jfren484]

It's the assignment of the static member from the instance constructor. HUGE no-no. If you want to make a singleton without using a DI framework, at least make the constructor private and have the static "Context" member be a property that will create a new object if one doesn't exist, and set it to a backing field. Something like this (might need to make Current a method instead of property if you need to pass constructor arguments, but you get the idea):

public class Singleton
{
private Singleton _current;

public Singleton Current
{
	get
	{
		if (\_current == null)
		{
			\_current = new Singleton();
		}
		
		return \_current;
	}
}

private Singleton()
{
}

}

[Q The First Timelord]

The first 'true' you receive you explicitly cast the object on the function call to a DataContext type. The second you're comparing a ModelDataContext.Context object - which I'm not sure if it's a DataContext type - if not - then you're comparing unlike objects and the call will fail. Try explicitly casting the ModelDataContext.Context, and for overkill the newdc to a DataContext type and do the comparison that way. ie: Console.WriteLine((DataContext) ModelDataContext.Context == (DataContext) newdc);

[AnotherKen]

It is a simple newb mistake. Basically, you have written overly complex code making it hard for you to debug. Simplify the syntax as much as possible and the symantec issues will reveal themselves ;)