I was just listening to The Aquabats – The Baker and I guess I paid attention to the lyrics for the first time. It just tells the story of every webdeveloper and their conflict with webdesigners:
I am the BakerI bake the cakeYou’re the decorator and you decorateYou take the creditWhile I slave awayI mixed, I made, I baked!
You can check the lyrics here.
Ouvindo: The Aquabats - The Baker
Or: Unavailability of value comparison of objects in .NET, a technical or philosophical restriction?
I was working on unit tests and then a question came to me – why comparing objects by value is not provided out-of-the-box by the .NET Framework? We all (should) know that by default, comparing objects leads to a reference comparison, unless of course you override Equals() or implement operator == on your class.
But what if I want to compare two objects from a class provided by the Framework? That would be quite handy specially for unit tests. While we have System.Object.Equals() and System.Object.ReferenceEquals() working the very same way – reference comparison – we don’t find something like System.Object.ValueEquals().
Then I started having a discussion with a friend and colleague of mine the reasons for such functionality not existing in .NET.
Although I agree that the default option should be reference comparison, I don’t see any technical limitations for not having that implemented – Reflection could be the way to do it, going recursively down each property and checking if their values are equal.
So why not? Is it something related to the theory of object orientation or was it a mere technical decision?
Let’s take one of the classical examples of OO lessons: a Car class. In a Car, you have properties such as Color, Model, Category, etc. In real life, when two cars come out of production line, while you can’t say they are the same car, one would have no problem identifying they were built by the same method. Just compare each of their properties and you will end up knowing they are not the same car, but they share the same properties and were built the same way. They don’t share a reference equality, but value equality.
As far as I am concerned, OO does not provide a specific way or method to apply the property-by-property comparison, but there isn’t a prohibition on doing that as well.
However, providing such functionality could be an expensive trade-off, since gigantic objects with collections with millions of items could be compared. It would be possible, but sometimes not practical. But then not providing that for the developer’s discretion, or at least providing ways to ensure it could be safely used? Doesn’t seems right to me.
From my point of view, such functionality could be very useful and there is no true restriction that should be applied for having something like that provided by the Framework. As I said, my opinion is that not providing it is a technical decision, and not a philosophical restriction imposed by OO theory.
What do you think? I’d be glad to listen to other opinions!
Ouvindo: The Real McKenzies – Scots Wha' Ha'e
Although I’ve worked with WWF (Windows Workflow Foundation) during all 2009, I haven’t posted anything about the technology yet, so I thought it was maybe the time to do it. I’ll start with one of the bases of the implementation of custom ActivityValidator classes. Despite being simple, that is an error that strikes new workflow developers quite often.
When creating a custom ActivityValidator, you might receive a compilation error from the newly created validator, even when the custom Activity it is targeted against is not in use yet.
But how come? Let’s take a look at the example below:
[ActivityValidator(typeof(MyCustomValidator))]
public partial class MyCustomActivity : Activity
{
public static DependencyProperty PriceProperty = DependencyProperty.Register("Price", typeof(float), typeof(MyCustomActivity));
[DescriptionAttribute("Price")]
[CategoryAttribute("Price Category")]
[BrowsableAttribute(true)]
[DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)]
public float Price
{
get
{
return ((float)(base.GetValue(MyCustomActivity.PriceProperty)));
}
set
{
base.SetValue(MyCustomActivity.PriceProperty, value);
}
}
public MyCustomActivity()
{
InitializeComponent();
}
}
public class MyCustomValidator : ActivityValidator
{
public override ValidationErrorCollection Validate(ValidationManager manager, object obj)
{
MyCustomActivity myCustomActivity = obj as MyCustomActivity;
ValidationErrorCollection errors = base.Validate(manager, obj);
if (myCustomActivity == null)
{
throw new ArgumentException("MyCustomValidator can only be used to validate MyCustomActivity instances.", "obj");
}
if (myCustomActivity.Price <= 0)
{
errors.Add(new ValidationError("'Price' must be greater than zero.", 1));
}
return errors;
}
}
In the example above, when you build the project you will receive an error such as
Error 1 Activity 'MyCustomActivity' validation failed: 'Price' must be greater than zero.
Well, that is not nice. You are not even using MyCustomActivity yet!
The reason for that is simple: validators are run during runtime, but also during build time! To avoid the error, we simply check if the custom activity is in use. How? Take a peak:
public class MyCustomValidator : ActivityValidator
{
public override ValidationErrorCollection Validate(ValidationManager manager, object obj)
{
MyCustomActivity myCustomActivity = obj as MyCustomActivity;
ValidationErrorCollection errors = base.Validate(manager, obj);
if (myCustomActivity == null)
{
throw new ArgumentException("MyCustomValidator can only be used to validate MyCustomActivity instances.", "obj");
}
if (myCustomActivity.Parent != null)
{
if (myCustomActivity.Price <= 0)
{
errors.Add(new ValidationError("'Price' must be greater than zero.", 1));
}
}
return errors;
}
}
As you can see, all we did was checking if the activity parent is not null (line 13).
Try to build now, no error will be triggered. Then drop MyCustomActivity to a workflow, don't fill in Price and build again. The error is now there, correctly returned!
Well, that was it... No black magic but surely resourceful! I hope it helps!
Ouvindo: Cólera – Vira-Latas
You are here. You are a nerd. And you are proud of that.
Be happy, today is our day! Happy Nerd Pride Day!
Ouvindo: Twoface – Road Rage (Live)
You are coding an UserControl for your Silverlight 2 application that might change the world. You are almost done with it, already told all the guys that the first round is on you. You are thrilled about your fabulous coding skills.
And then you find him. An horrendous, terrible, dreadful enemy. His name: AG_E_PARSER_UNKNOWN_TYPE.
You start looking for reasons of such an error, but all you find is despair. No hints, no clues, you start loosing your temper – and possibly your hair. You curse the framework for not supplying you with enough information: just a plain AG_E_PARSER_UNKNOWN_TYPE on your xaml file. Googling does not help you much, as few have faced that horrible vilain.
Fear not, friend, as I have found him myself, and I am going to share the secrets of some of his weak spots. Explore them, and I hope you defeat him the way I did.
Jokes apart, that was an error that took me a while to figure it out. Everything happened when I was creating user controls that were related to each other by their parent class. And impressively I run into two different situations in the same task that lead me to AG_E_PARSER_UNKNOWN_TYPE.
My solution was structured as follows:
using System;
using System.ComponentModel;
namespace MySolution
{
public abstract class MyBaseClass : UserControl
{
}
public partial class MyClass1 : MyBaseClass
{
}
public partial class MyClass2 : MyBaseClass
{
}
}
First error in the intended code above: the MyBaseClass derivating from UserControl can’t be declared abstract. I know, it is a pain in case you want to create an abstract method within – you won’t be able to do that at all. Try a workaround like creating virtual methods throwing a NotImplementedException, and then overriding it with the real implementation.
The other situation I found that error in was related to listeners and the user control constructor. I’m not entirely sure why that happens, but if you register for a listener on the constructor class (or call any method registering it from the constructor) of your user control, you might have a chance to encounter the might evil AG_E_PARSER_UNKNOWN_ERROR is.
Also, a collegue pointed out for me a blog post with some explanations to AG_E_PARSER_UNKNOWN_ERROR and other Silverlight hell minions alike. Despite being related to Silverlight 1.1 alpha, I found the list to be trully helpful. I wish I had found that one before, the struggle would be much smaller!
Ouvindo: Deluxe Trio – Mais Pimenta Menos Sal
