Object initializers. [modified]
-
class Foo
{
public string Description { get; set; }
public String Name { get; set; }
}public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}private void InitFoo()
{
Foo foo = new Foo() { Description = Name = "name" };
}
}After running
InitFoomethod foo.Name is not initialized. Can you spot the bug? You can see answer at my blog post: Object Initializers and Possible Bugs[^]Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
modified on Friday, September 19, 2008 2:19 AM
-
class Foo
{
public string Description { get; set; }
public String Name { get; set; }
}public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}private void InitFoo()
{
Foo foo = new Foo() { Description = Name = "name" };
}
}After running
InitFoomethod foo.Name is not initialized. Can you spot the bug? You can see answer at my blog post: Object Initializers and Possible Bugs[^]Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
modified on Friday, September 19, 2008 2:19 AM
You can't initialize objects like this. You need to use Description="Blah", Name="Blah".
Deja View - the feeling that you've seen this post before.
-
You can't initialize objects like this. You need to use Description="Blah", Name="Blah".
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
You can't initialize objects like this.
That's correct but the above code compiles. But foo.Name is not initialized. That's why it is a subtle bug ;)
Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
-
class Foo
{
public string Description { get; set; }
public String Name { get; set; }
}public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}private void InitFoo()
{
Foo foo = new Foo() { Description = Name = "name" };
}
}After running
InitFoomethod foo.Name is not initialized. Can you spot the bug? You can see answer at my blog post: Object Initializers and Possible Bugs[^]Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
modified on Friday, September 19, 2008 2:19 AM
I didn't know you could do this (citing the correct way to do it):
Foo foo = new Foo() { Description="Blah", Name="name"};
Putting the constructor body here is, IMHO, bad programming technique.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
class Foo
{
public string Description { get; set; }
public String Name { get; set; }
}public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}private void InitFoo()
{
Foo foo = new Foo() { Description = Name = "name" };
}
}After running
InitFoomethod foo.Name is not initialized. Can you spot the bug? You can see answer at my blog post: Object Initializers and Possible Bugs[^]Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
modified on Friday, September 19, 2008 2:19 AM
That was subtle! Actually Visual Studio tooltips help in spotting it. Another way to spot it is to change the assignment to the following:
Foo foo = new Foo() { Name = Description = "name" };
Initially I tought the problem was the order of assignement, so I inverted it. Well the result was somewhat surprising :-D
-
I didn't know you could do this (citing the correct way to do it):
Foo foo = new Foo() { Description="Blah", Name="name"};
Putting the constructor body here is, IMHO, bad programming technique.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
I didn't know you could do this: Foo foo = new Foo() { Description = Name = "name" };
You can't. But in this case it compiles. That's why it's a subtle bug :)
Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
-
That was subtle! Actually Visual Studio tooltips help in spotting it. Another way to spot it is to change the assignment to the following:
Foo foo = new Foo() { Name = Description = "name" };
Initially I tought the problem was the order of assignement, so I inverted it. Well the result was somewhat surprising :-D
yes, changing the assignment really helps :)
Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
-
John Simmons / outlaw programmer wrote:
I didn't know you could do this: Foo foo = new Foo() { Description = Name = "name" };
You can't. But in this case it compiles. That's why it's a subtle bug :)
Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
When I said "I didn't know you could do this", I was talking about initializing the properties when instantiating the object.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
When I said "I didn't know you could do this", I was talking about initializing the properties when instantiating the object.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Oh my mistake. It's a new feature in c# 3.0 called object initializers.
Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
-
Oh my mistake. It's a new feature in c# 3.0 called object initializers.
Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
Ah, more new "features" to avoid. I wish they'd add the features the I want.
-
I didn't know you could do this (citing the correct way to do it):
Foo foo = new Foo() { Description="Blah", Name="name"};
Putting the constructor body here is, IMHO, bad programming technique.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
Putting the constructor body here is, IMHO, bad programming technique.
I second that.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
-
class Foo
{
public string Description { get; set; }
public String Name { get; set; }
}public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}private void InitFoo()
{
Foo foo = new Foo() { Description = Name = "name" };
}
}After running
InitFoomethod foo.Name is not initialized. Can you spot the bug? You can see answer at my blog post: Object Initializers and Possible Bugs[^]Giorgi Dalakishvili #region signature my articles My blog[^] #endregion
modified on Friday, September 19, 2008 2:19 AM
Giorgi Dalakishvili wrote:
Foo foo = new Foo() { Description = Name = "name" };
OMG! I didn't even know that was legal syntax! (but I can see it now) Good spot :)
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008)
((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x)) -
I didn't know you could do this (citing the correct way to do it):
Foo foo = new Foo() { Description="Blah", Name="name"};
Putting the constructor body here is, IMHO, bad programming technique.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001What do you mean with this?:
John Simmons / outlaw programmer wrote:
Putting the constructor body here is, IMHO, bad programming technique
It's not like you are moving the ctor out from the class and into the initializer. the initializer is the initializer, configuring stuff that are not default values. eg: Person you = new Person() {FirstName = "John",LastName="Simmons"}; Ofcourse you could write your own constructor that takes those as in params. But there are cases where a class has alot of properties and you are not likely to provide a constructor with every possible set of in param combination for those. Or did I completely misinterpret what you said?
-
What do you mean with this?:
John Simmons / outlaw programmer wrote:
Putting the constructor body here is, IMHO, bad programming technique
It's not like you are moving the ctor out from the class and into the initializer. the initializer is the initializer, configuring stuff that are not default values. eg: Person you = new Person() {FirstName = "John",LastName="Simmons"}; Ofcourse you could write your own constructor that takes those as in params. But there are cases where a class has alot of properties and you are not likely to provide a constructor with every possible set of in param combination for those. Or did I completely misinterpret what you said?
This falls neatly under the category of "Just because you *can* do it, doesn't mean you *should* do it". Why is that better than writing the appropriate constructor and using
new Person("John", "Simmons");? Further, an appropriately designed class initializes all of its properties when it's instantiated. This new feature of .Net appears to propagate lazy programmers."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
This falls neatly under the category of "Just because you *can* do it, doesn't mean you *should* do it". Why is that better than writing the appropriate constructor and using
new Person("John", "Simmons");? Further, an appropriately designed class initializes all of its properties when it's instantiated. This new feature of .Net appears to propagate lazy programmers."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
This new feature of .Net appears to propagate lazy programmers.
All the
.NETthing goes in such a direction... :-DIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
This falls neatly under the category of "Just because you *can* do it, doesn't mean you *should* do it". Why is that better than writing the appropriate constructor and using
new Person("John", "Simmons");? Further, an appropriately designed class initializes all of its properties when it's instantiated. This new feature of .Net appears to propagate lazy programmers."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
Why is that better than writing the appropriate constructor
As I said in my first post. Lets assume that your class contains 20 properties, all of those recieve default values in the default ctor. And the user only wants to init custom values in 5 of them.. (Think winforms control or such, eg a grid) Should you create a constructor for each possible combination of properties that the user _might_ want to set? No way..
-
John Simmons / outlaw programmer wrote:
Why is that better than writing the appropriate constructor
As I said in my first post. Lets assume that your class contains 20 properties, all of those recieve default values in the default ctor. And the user only wants to init custom values in 5 of them.. (Think winforms control or such, eg a grid) Should you create a constructor for each possible combination of properties that the user _might_ want to set? No way..
Not to mention if they're all the same type you can't create a ctors for all of them. That said, this is just a return of optional parameters. Personally I'd prefer a syntax of
FooBar myFooBar = new FooBar(1,2,,,5,,,8,,,,,,15,,,,19,20);and a ctor that looked likeFooBar(optional int param1, optional int param2, optional int param3,.... ) {...}Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
This falls neatly under the category of "Just because you *can* do it, doesn't mean you *should* do it". Why is that better than writing the appropriate constructor and using
new Person("John", "Simmons");? Further, an appropriately designed class initializes all of its properties when it's instantiated. This new feature of .Net appears to propagate lazy programmers."Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Ten! Or we should be able to use something like the syntax that Attributes use.
-
Ah, more new "features" to avoid. I wish they'd add the features the I want.
I am still holding out for them to add a DoAllMyWork class ;P
-
I am still holding out for them to add a DoAllMyWork class ;P
You can make one by inheriting
HireRentACoderand implementingCheapOutsourcing().Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
