All Representations are Equal, but some Representations are More Equal than Others

Steve Maine responds to my rant against attributes with some interesting and quite revealing comments about the centrality of attributes to the Indigo programming model. I'll leave aside the assumption that I want a new language, as I've already dealt with that. I want focus on Steve's comment about attributes:
 
I can see where John’s coming from; other frameworks have used CLR attributes to convey “extra stuff” that’s not really central to the core programming model. In Indigo, though, attributes are central to the programming model and are by no means “second-class” or unimportant. Indigo uses CLR types to denote two equivalent representations of the same underlying concept that exist simultaneously. Each representation is equally important, and external contracts aren’t relegated to subservient status just because they’re defined in attributes.
 
Hogwash! The "other frameworks" are actually doing the right thing and it's Indigo that's in the wrong here. The word "attribute" has a specific meaning in the English language and that meaning is reflected in the nature of attributes in the CLR. An attribute is a quality or characteristic inherent in someone or something. Grammatically, an attribute is a word or phrase syntactically subordinate to another word or phrase that it modifies. It is quite obvious that CLR designers chose the name "attribute" for the programming construct because it fits perfectly. A CLR attribute is both syntactically subordinate to the construct it modifies and expresses a quality or characteristic of that construct. Consciously or not, by using attributes for the CLR version of the contract, the Indigo team is making a value judgment about how we should design our applications. That is clearly reflected in Steve's example:
 

[DataContract( ContractName = "Foo" )]           
public class
Bar                                        
{                                                                    
    [DataMember( Name = "Whoosit" )]    
    private string Baz;
}

=>

<xs:schema xmlns:tns="http://schemas.datacontract.org/2004/07/" xmlns:ser="http://schemas.microsoft.com/2003/10/Serialization/"
       elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/"
       xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:import namespace="http://schemas.microsoft.com/2003/10/Serialization/" />
  <xs:complexType name="Foo">
    <xs:sequence>
      <xs:element name="Whoosit" nillable="true" type="ser:string" />
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="ser:VersionDelimiter" />
        <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##targetNamespace" processContents="lax" />
      </xs:sequence>
    </xs:sequence>
    <xs:attributeGroup ref="ser:TypeAttributes" />
  </xs:complexType>
  <xs:element name="Foo" nillable="true" type="tns:Foo" />
</xs:schema>

 

These two supposedly equal representations aren't equal at all. It's fairly obvious how to go from the CLR representation to the XML Schema, but how would one reverse the process? You can't. The Indigo team has been quite clear that if you want to design the message first, they "will get out of your way" which is just another way of saying they won't help at all. I will say it again. What I'm asking for is not difficult or bizarre, but it is something that is best done by Microsoft. It won't be done, because Microsoft (especially the Indigo team) doesn't believe that it has value. They are too wrapped up in OO orthodoxy to see what's plainly there. Writing true service oriented applications requires service oriented analysis and design, not half-baked, after the fact, sprinkling magic SO pixie dust on your same-old object model.

 

 

Posted May 10 2005, 11:35 PM by john-cavnar-johnson
Filed under:

Comments

Sam Marcuccio wrote re: All Representations are Equal, but some Representations are More Equal than Others
on 05-11-2005 3:01 PM
Let me start by saying that I completely agree that the use of attributes in Indigo's programming model is unorthodox. But...

In your previous post you said:

"If the VB.Net team can do that, I don't see what the problem is with implementing the concept of a Message as a restricted reference type."

In my personal opinion, if Microsoft is going to kluge the programming model with the use of mechanisms like Module in VB.NET, I have no problem with their apparent disregard to the proper use of attributes. This, if you think about it, is your argument for the Message type.

On a side note: wouldn’t any encapsulation of the message restrict your access (at some level) to the message?
John Cavnar-Johnson wrote re: All Representations are Equal, but some Representations are More Equal than Others
on 05-12-2005 5:36 AM
Sam,

We've had the VB module discussion before. I don't really have strong feelings either way on it, but that wasn't the point of my post. I used it as an example of how a language can be innovative without needing to change the CLR or CTS. Maybe I should used the Eiffel.Net example (multiple inheritance for .Net).

Yes, the whole point of the encapsulation of the message is to restrict how you can access a message. I don't think you have to go as far as BizTalk does (where the message is essentially immutable), but I think messages are different from class instances in important ways.
Bruce Williams [MSFT] wrote re: All Representations are Equal, but some Representations are More Equal than Others
on 05-13-2005 11:33 PM
I can't really comment any further about the native C# 'message' issue - I don't know what if any efforts we made in that direction. I suspect that if we did pursue that, we were either too late in the C# 2.0 ship cycle to get it in, and/or we weren't able to convince the C# folks that our library was core enough to be worth changing the language specification. However, I'm just guessing. I'll ping someone else on the team who might know more, perhaps they'll chime in.

As for the XSD -> Code scenario, we do support that; you can feed the XSD in your post to our tools and get code generated for you. If you have any problems with this functionality, please let us know!

I do agree there is a lot more we could be doing; graphical message construction and transformation sounds very cool to me. Tell us what you want or need, and we'll get as much goodness in before RTM as we can.

There may be some points on which, in the end, we'll have to agree to disagree (attributes?); but if there are issues with Indigo that block the development of any type of distributed scenario, we want to know about it.
Dion Hinchcliffe's Blog - Musings and Ruminations wrote An Evening of Indigo with David Chappell in Washington, DC
on 05-14-2005 10:01 AM
Dion Hinchcliffe's Blog - Musings and Ruminations wrote An Evening of Indigo with David Chappell in Washington, DC
on 05-14-2005 10:09 AM
Message for you, sir! wrote 10 Things I Hate About Indigo
on 08-13-2005 11:05 PM

Add a Comment

(required)  
(optional)
(required)  
Remember Me?