1. Computing

Do Properties Dream Of Default Values?

By December 3, 2010

Follow me on:

in Polls :: I just had an interesting email exchange with the support stuff for one of the third-party tools I would like to use in my application. The tool is a COM library exposing some objects with properties, methods and everything you would expect.

Now, evaluating any COM (or any other 3rd party SDK) is a pain since I more or less have to create a full blown application to make sure that what I need from the SDK will actually be working when I embed it into my final application.

First, I spend a few days searching for an SDK that provides the features I am looking for (at least by reading the marketing stuff on the vendor's web site).
Next, I have to "pollute" my environment by installing the SDK in order to test it.

Then I look for some ready made examples, if some exist, in whatever Manual (for that SDK) I can find.

So here I am .. evaluating one SDK (COM object). There's a Manual listing all the exposed classes with their properties and methods. There are even some examples where those properties and methods are used to achieve some results in what the SDK is supposed to be used for.

Of course, the COM object exposes dozens of properties one could set to change the result of some method calls.

The name and the type of the property is specified (of course). Some are boolean, some are int, some are similar to enums (using string values), ....

Looking further in the Manual I cannot find the default value for any of the properties. The question I had for the support personnel of the SDK was "what are the default values for all the properties"?

Of course, my question was toward: "If I do not explicitly set a value of a property how will that reflect on the methods calls (depending on that property)".

I got some non expected answers, but before I go into this I have a question for you:

For the moment I do not want to share the name of the vendor or the name of the SDK ... as I am still exchanging emails ...

Comments
December 3, 2010 at 10:45 am
(1) Mason Wheeler says:

Under Delphi, all properties of an object have a default value, because the construction process zeros the memory space. This is not always the case in other languages, such as C++, though. So it depends at least partially on what the COM library was written in and how careful the people who wrote it were.

December 3, 2010 at 2:15 pm
(2) Zarko Gajic says:

@Mason: for a C++ property with “no default value” as you say, if I “read” the property some value will be returned, right?

December 3, 2010 at 3:56 pm
(3) Rudy Velthuis says:

@Zarko: C++ has no properties, but if you do that on a C++ written COM object, or a C++Builder object, the value may be undefined, i.e. depending on the state of the memory before the object was created, or depending on whatever the accessor function for that property does beside reading a possibly uninitialized class member. One can hardly call that a default value.

I do think that properties SHOULD have a default value.

December 3, 2010 at 5:33 pm
(4) Zarko Gajic says:

@Rudy: having a COM object I do not know what language it was written in (nor I care). It does expose properties though. From my point of view, when I read a property (for the first time) what gets returned is the “default value” – be it NULL, undefined or uninitialized memory address.

Of course this value has no “value” but still something is returned and I consider this a default value.

December 7, 2010 at 4:46 pm
(5) G says:

@Zarko: re “Of course this value has no “value” but still something is returned and I consider this a default value”

My definition of a default value is that all newly created objects would return the same value for the property regardless of when / where it was created.

If the underlying data is not initialised (ie by zeroing the memory or explicitly setting a value in the constructor) then you end up with a random value based on what was previously at that memory address. Therefore, not a default value.

December 7, 2010 at 5:29 pm
(6) Karl says:

The question is a little ambiguous.

I think there are two questions, really:
Do properties have a default value in Delphi?

Should properties have a default value in Delphi?

The first is yes, they do, because if you question them before they have been given a value, you will get a valid result. The problem for me is that that result is often not useful.

The second question is much more interesting.

For me, i believe that most often a Boolean should have 4 possible answers: True, False, Unset, Invalid.
This means that before you assign it a value, if you query a boolean it returns “unset”. The “Invalid” value means that for some reason the result that has been loaded into the boolean is not reasonable.
An example might be if you used a TIniFile, and when reading what was supposed to be a boolean u get a result of 3. That’s not valid.

Thoughts?

December 7, 2010 at 6:45 pm
(7) Lyle says:

I feel your pain and as a developer I can understand the problem. From a users standpoint, the documentation should tell you what uninitialized properties return period. The user should not be expected to have to understand the developer’s thought process, package language, etc. If we have to do all that, then we can just develop the package ourselves and spare the heartache. We use a tool to save time and if we have to study the original code or do endless testing to understand how it works, that’s not useful.

In another point point, about the testing. When you develop a component don’t give us a 10,000 line example test program. At the least have one very simple example of program usage that has just code necessary to run the component. Often poor or non-existent documentation makes it a nightmare just to understand how to call and use the component. When you develop a component you know every detail about it but I don’t. Show me a simple call to the component and not from a command line so I can understand how to use it. Then show me the 10,000 example for all the bells and whistles!

December 8, 2010 at 3:55 am
(8) Zarko Gajic says:

@G: Ok, so the main problem is what do we think when we say “default value”.

Let’s say we have a tool/COM/SDK/class to convert a report to PDF. Let’s say there’s a property “Linearized” (can be true or false).

If I call “Export” the PDF generated will either be linearized or not. The Manual does not say what is the default value (if I do not set the “Linearized” property).

If “Linearized” would sometimes be false and sometimes true, I consider this a bug.

From my point of view I would always expect that the same value is returned by a property (if you do not set it), everything else is a BUG!

December 8, 2010 at 9:48 pm
(9) G says:

@Zarko: I agree, any object that does not have “default Values” for their properties should be considered a BUG.

Undefined values = undefined behaviour = BUG

To me properties like these should allow you to optionally modify default behavior. If there is no default behavior, and the value should always be specified, then it should be a parameter passed to the function call eg:
procedure export(…; in_linearized: boolean);

Documentation should list the default values for properties but I’ve found that most don’t. Personally I’m not too worried about that as you can reasonably quickly test the value of a newly instantiated object. Of course this assumes you don’t have a BUG as you’ve described.

December 22, 2010 at 6:45 am
(10) Stelios says:

A bit off topic, but loved the metaphore from the original book of Philip K. Dick “Do Androids dream of electric sheep?”! Cracked a smile in my face…

December 22, 2010 at 7:44 am
(11) Zarko Gajic says:

@Stelios: at least you had a good smile :) )

Leave a Comment

Line and paragraph breaks are automatic. Some HTML allowed: <a href="" title="">, <b>, <i>, <strike>

©2014 About.com. All rights reserved.