Use of past tense (passive voice) to connote immutability? (E.g. Array.Transposed vs. Array.Transpose)

[Note: The below is a bit C# heavy in its syntax and conventions, such as citing FxCop rules, because this is my background, but the intent of this discussion is to be language-agnostic and the code examples used should generally be regarded as pseudo-code. — Mike]

I think we would all agree that classes should generally be designed so that their object instances are immutable wherever practical, and the results of calling class members should be free of side effects, as much as possible.

Historical naming conventions, however, tend to use the active voice: 'GetSomething', 'DoSomehing', etc. and this is good because it states clearly what action that the class member is going to take.

I am now beginning to think, however, that members might sometimes (or possibly often) benefit by being named in the past tense to connote that a value is returned without affecting the referenced object.

For example, for a method that transposes an array, current naming styles would probably have it called 'Array.Transpose', but if this member returns a new array, without transposing the referenced object, then I think that calling it 'Array.Transposed' would be more accurate and makes it clearer to the programmer.

When working with an 'Array.Transpose()' method one might accidentally try to use code such as the following:

Array myArray = new Array(); 
myArray.Transpose();

But if the 'Transpose' method returns a new array without affecting the referenced object, then this code does nothing — that is, 'myArray' would quietly not be transposed. (I suppose that if 'Transpose' were a property, then the compiler would catch that the above is not legal, but FxCop guidelines state that a member that performs a conversion should be a method.)

But if the method were named in the past tense as 'Array.Transposed', it would be clearer to the user that the following syntax is required:

Array myArray = new Array(); 
Array transposedArray = myArray.Transposed();

Other names that I think would fit into this category would be members named 'Resized' vs. 'Resize', 'Shifted' vs. 'Shift', etc. The present tense would be used for members that affected the referenced object, while the past tense would be used for members that returned a new value without affecting the referenced object.

Another approach that is more common currently is to prefix each name with "Get" or "To", but I think that this adds unnecessary weight, while changing to past tense communicates the meaning effectively.

Does this make sense to other programmers here, or does this past tense idea sound too awkward when reading it?

Edit:

Great discussions below, I thank everyone a lot. A few points I'd like to summarize based on your comments and my own revised thinking on this follows below.

Method Chaining "Fluent" Syntaxes

Based on the discussions below, the use of the past tense is probably of some value when used on a mutable class in order to make it clear which members do, or do not, affect the internal state of the referenced object.

However, for immutable classes, which should be the majority of the cases (one would hope), I think that the use of the past tense can make the syntax unnecessarily awkward.

For example, with "fluent syntaxes" such as those created by method chaining, the use of past tense would make the code less readable. E.g., when using LINQ via C#, a typical method chain could look as follows:

dataSource.Sort().Take(10).Select(x => x.ToString);

If changed to the past tense, this would become awkward:

dataSource.Sorted().Taken(10).Selected(x => x.ToString);

Mind you, dataSource.Sorted() is actually clearer in meaning than dataSource.Sort(), because LINQ expressions always create a new enumeration without affecting the source. However, since we are fully aware of this when using this paradigm, the use of past tense is redundant and makes the "fluency" of reading it awkward for no real gain.

Use of Properties vs. Methods

A key issue that was brought up below regards the FxCop guidelines for the use of "Get" methods vs. read-only properties. E.g., FxCop rule CA1024.

Although not explicitly mentioned in that FxCop rule, the use of "To" methods would seem to apply to this rationale as well, since ToXXXXXX() methods are conversion methods. And in the case of ToArray(), the method is both a conversion method and is a method that returns an array.

Use of Past Tense for Boolean Properties

Some suggested that the past tense can connote a boolean value, e.g. a 'Succeeded' or 'Connected' property. I believe that the retorts below emphasizing the use of an 'Is', 'Has', or 'Are' for Boolean properties and fields are correct. Past tense can help in this regard too, but not nearly as much as using an 'Is' prefix. Feel free to use the past tense for Boolean properties and fields, it does help, but I think that it's even more important to prefix the name with 'Is', 'Has', or 'Are'.

Overall Conclusions?

For the issue of Tranpose() vs. Transposed(), I think that 'skizzy' got it right, suggesting that it should be Transpose() for a mutating action vs. GetTransposed() for a non-mutating result. This makes it 100% clear. But, again, I think that this might only apply for a mutuable class, such as an array.

For immutable classes, especially where a fluent method-chaining syntax might be used, then I think that this syntax would become unnecessarily awkward. For example, compare:

var v = myObject.Transpose().Resize(3,5).Shift(2);

to:

var v = myObject.GetTransposed().GetResized(3,5).GetShifted(2);

Hmmm… actually, even here it seems to make it 100% clear that the result does not affect the source, but I'm not sure.

I guess for a paradigm like LINQ where it is well known, the use of "Get" and/or the past tense is not necessary, but for a new API, it might have some value — at first! If the API contains only immutable objects, once the user understands this, the use of "Get" and/or the past tense only reduces the readability.

So I think there are no easy answers here. I guess one needs to think about the entirety of your API and choose carefully!

— Mike