More thoughts on properties and methods

Wow – thanks for your feedback on this issue.  I am going to start bringing you people more of my hard problems.  As of a few minutes ago the consensus seems to be slightly in favor or going with methods in the case I outlined (about 16 pro methods to 9 pro properties).  There were really great points throughout the discussion, I will not highlight them all here, you should really go read them if you are struggling with this issue.

But I couple of recurring themes I thought it was worthwhile to comment on:

  1. Fix it in the docs… I hear this argument many times a day.  Essentially whenever a problem seems too hard to solve we “punt” and fix it in the docs.  As if 100% of our users read the docs end-to-end before they begin writing code.  Now I am a huge fan of the docs, I think we have done some amazing stuff in V1 and V1.1 but that doesn’t change the fact that many users don’t read the docs and should not have to.  In fact in our API reviews we look at the “header file” view of the types (just the signatures of the methods).  You should be able to intuit about an object model from just that information. Once that is simple, the docs will be simple, the IDE experience will be simple, etc.
  2. Network Transparency… I will not go into detail here, but I’ll just say that I don’t buy the argument that we will ever have networks that are robust, fast and predictable as needed for effective transparency… I am sure you can grab one of Don Box’s many talks for the PDC and get the same message.
  3. Local Caching … A couple of you wanted to change the question – a good PM skill ;-).  You wanted to know if we could cache the values locally then use properties to the local cache.  Personally, I think that would work in general, but for this area the feature owners believe the 90% scenario requires have live data.  
  4. The debugger – Yes, the debugger does evaluate properties by default.  I added a very brief discussion of this to the design guidelines doc thanks for highlighting it!

 

Published 17 November 03 06:23 by BradA

Comments

# Keith Patrick said on November 17, 2003 11:02 PM:
On the issue of network transparency, I'm not saying that any time soon calling a method across the internet will incur no penalty. What I'm trying to get at is that I think that something as fundamental as an API signature should reflect what its function is logically, without regards to a physical limitation such as geography (although I do think that we will see network communications, at least local, that perform at a speed that is for all intents and purposes instantaneous, whether it's 30 or 50 years away...guess "we" is a poor choice of words, then ;) ) Something like performance tips can be documented, and additional restrictions one or more conceptual layers up can be tacked on via attributes. So for something like .CurrentTime, I consider it really a matter of opinion based on the question "Is that a property of a system (or space-time, I guess) or is that an action that performs a calculation (.GetCurrentTime())?".
# Pierre Arnaud said on November 18, 2003 2:05 AM:
How about defining attributes which would get attached to potentially slow properties. This would allow the debugger not to evaluate them by default, and the IDE to show a hint about the fact when editing the code.
# David Levine said on November 18, 2003 5:25 AM:
I like the idea of attributes related to access retrieval cost. For example, a control has a property called InvokeRequired to denote when a calling thread should use an async delegate. There could be something like that for a property called IsRemoted to indicate that the value is not cached locally and requires a network roundtrip to update. There could be a design pattern that falls out of this to handle caching remote values.
# Diego Vega said on November 18, 2003 4:17 PM:
I read the original post again and then some of the comments I didn't read before. I have to agree that if the calls consume an unbounded ammount of time they shoud be exposed as methods. But if the network roundtrip is the only source of this delay then I would sugest to cache the result. If caching is not a choice then I have no strong opinion. It would be interesting to know which WinFX are we talking about, but I guess if you didn't tell from the begining is because you couldn't.
# Brad Abrams said on November 18, 2003 7:09 PM:
I got this note in email because a big pieces of GotDotNet blogs was down... The need for live data is exactly my point, not an argument against it. I wouldn't consider my suggestion an argument for caching the properties locally. I'm trying to get you to consider the granularity at which the information makes sense. If I want to write code that makes use of the relationship between the values the object returns, then the values must have a single common reference point. In the specific example you gave, most of the properties were time-related. Depending on the particular time scales involved, the time it takes to make the network calls could have a significant impact on the semantic meaning of the values returned. I want to be able to ask an object for its consistent state at a specific instant in time, particularly when the object may be remote. If you've ever dealt with satellite-based networks, you quickly realize the impact of latency on network communications. I would like to see API's designed that encourage code correctness first, code security second, code performance third, and code elegance last
# Anonymous said on November 19, 2003 1:45 AM:
Even the method doesn't solve the problem though. You still have no idea that the call might go across a network. To me, GetUserInformation sounds like looking something up locally. If you want to make it seem like it could go network, you need a name that suggests that, like QueryDomainForUserInformation or something. So I think the question posed was invalid ... since it doesn't really matter whether you make it a method or a property, there's nothing there either way to suggest the call may be slow because the name is poor.
New Comments to this post are disabled

Search

Go

This Blog

本博客中文版 (View in Chinese)

These postings are provided "AS IS" with no warranties, and confer no rights.

Syndication

Page view tracker