Automatic Properties Follow-up

August 27, 2007 at 10:48 am · Filed under .NET

Back in March, I posted Automatic Properties in C# 3.0 which included a couple of questions.  At the time I hadn’t installed any Orcas beta.  My post was based on other posts (including one from Bart DeSmet’s excellent blog: C# 3.0 Automatic Properties Explained).  My questions leapt out at me (maybe I’ll post about why that is . . .). Since that post, I have played a bit with the VS 2008 betas as well as built and tested the Digipede SDK samples.

A recent comment reminded me that I should revisit the questions.

Question 1: Is there an attribute to set the automatic field name?

Reason?  To maintain binary-serialization compatibility when moving from automatic properties to “normal” properties. 

Answer:  I don’t know if there is explicitly.  The underlying field name seems to have been changed since Bart’s first post and VS 2008 beta 2 (they have improved it so the field name can be derived from the property name).  This is good, because it might mean that the automatic property could be converted to the “normal” kind of property while maintaining default binary serialization; however, the backing field name looks like:

<PropertyName>k_BackingField.   

. . . and angle brackets are not valid for member names – the compiler can generate them, but aren’t valid C# syntax.  So, this is not quite what I want.

Question 2: Is there an attribute you can put on the automatic property to hide the underlying field or is it automatic?

Reason?  By default, properties with backing fields result in (usually) duplicated information in the debugging views.  If the backing field is generated by the compiler, it would make sense to just hide it (with the DebuggerBrowsableAttribute or some other way).

Answer:  This is automatic.  Good.  Probably a result of the CompilerGeneratedAttribute that is added to the generated backing field.

Summary

Based on what I know now, I wouldn’t use automatic properties if default binary serialization is likely to be used.  Regardless of this possibly arcane issue, automatic properties are cool.  I like them.

Tags: .NET, .NET3.5, c#, C#3.0, Digipede

Comments

System.Uri.Equals(…) What?

August 8, 2007 at 4:03 pm · Filed under .NET

Can someone explain why the following expression evaluates to true?  There must be some historical perspective that I’m just missing.

new Uri("mailto:somebody@example.com") == new Uri("mailto:somebodyelse@example.com")

I would understand:

1. A use case for a separate Uri.Compare method giving the caller control over which components should be compared;
2. If Uri.Equals performed its comparison against canonicalized URIs.

The docs say that the user info, fragment, and  (in older .NETs) query are all ignored for comparison.  There is no mention for the email address in a mailto; however.

What?  Why?

Tags: .NET, BCL, c#, Microsoft

Comments (5)

Twitter and Verizon

August 7, 2007 at 6:01 am · Filed under Web 2.0

Update 2:If you reading this (mild) rant, don’t. Nothing to see here. This all works fine. See updates on the bottom, if you are so inclined.

Twitter is cool.  But is it fun enough for me?

The Twitter page says:

Twitter is more fun when used through your mobile phone or instant messenger client. Set yours up!

I tried to.  And I tried again.

It turns out that Twitter doesn’t talk to Verizon.

This fact doesn’t warrant a mention on the setup page, nor in the Help, and not even in the FAQ.  Nowhere does it say this — mostly nowhere, it is mentioned in some Twitter feed.

So — I’ll just make an outlandish claim here — a whole bunch of people have entered their text number only to find it doesn’t work.  Then these whole bunches of people tried again.  And then, third time’s a charm?  Nope. 

I can understand not leading with your weaknesses, but not mentioning it at all? 

I’m not complaining that it doesn’t work with Verizon.  I know messaging between the U.S. wireless carriers is a crapshoot — my problem is that the Twitter pages don’t mention it.

C’mon Twitter, your app is cool, but have more respect for your users.  That alone will make it more fun for me.

Update: Crystal from Twitter says (very politely) that I’m wrong about Twitter and Verizon. I’ve contacted Twitter support to get it worked out. My fault for not contacting Twitter first — and now I can’t locate the feed that mentioned problems sending SMS to Verizon. It was probably outdated, after all.

Update 2:This all works fine. I made an assumption about the process. All my fault.

Tags: SMS, Twitter, Verizon, Web2.0, Wireless

Comments (4)