At least some embodiments described herein relate to a language extension that advances safety in system programming. In accordance with the language extension, an entire type may be declared to be immutable in the case in which all instances of that type are immutable. The immutable type declaration automatically causes any instances of that type to be treated as immutable, and automatically causes all directly or indirectly reachable members (e.g., fields, methods, properties) of the instance to also be treated as immutable.
Ada95 introduced constant, which was far as I can tell was the first implementation of immutable type in the Object Oriented Design paradigm.
Nothing like trying to patent a +20 year old idea.
D has had immutable types for years, very similar in definition to the patent claim: http://dlang.org/const3.html
The first release of D 2.000 in 2007 had transitive immutable types in it. https://dlang.org/changelog.html
Object immutability is nothing new. C and C++ have had the
const qualifier for years, which achieves exactly what's mentioned in the excerpt you posted and can be imbued in a type by means of a
However, the abstract from the page you linked mentions:
... Furthermore, any construction time reference that allows for field assignment of the instance is not permitted to survive beyond the point at which the instance becomes accessible to its creator.
I didn't read the whole thing, but this might be where the novelty of the patent is: it somehow doesn't let modifiable references to an immutable object escape the object's constructor (which is something I don't believe the other examples posted here do, though I might be wrong.)
I am able to find references to immutable objects in Java dating back to at least 2003/2004 here...http://www.javaranch.com/journal/2003/04/immutable.htm
Also for another source of immutability in D, page 159 starts the section on immutability in Ali Cehreli's Programming in D which is copyrighted 2009-2012 http://ddili.org/ders/d.en/Programming_in_D.pdf
To my understanding the third sentence that you quoted:
The immutable type declaration automatically causes...
does not necessarily imply what other users here call transitive immutability. It rather depends on how you define directly or indirectly reachable members.
Also, it seems that some users don't understand that it's not about declaring objects or instances constant but rather declaring a type in such a fashion that all instances of that type are constant by default.
What you are looking for is limited types in Ada (since Ada83). In Ada there is no assignment operation defined for limited types, which prevents any assignment to objects of limited types or assigments to objects of which you have a limited view. The actual specification is rather more intricate and detailed. Here are some references, knock yourselves out:
Wikibooks, Ada Programming (imcomplete but simple explanation of limited types)
Ada95 LRM, 7.5 Limited Types (Completely revamped specification)
Ada05 LRM, 7.5 Limited Types (There were lot's of changes concerning initialization in this version)
Ada95 Rationale, 7.3 Limited Types (Contains some discussion about limited views)
The Lambda-the-Ultimate discussion yielded a couple new answers. One is about Mezzo/ATS, and there are various others which might be relevant.
The other one says that this patent is a copy of work done in prior art in BitC:
As far as I can tell, this work is a direct transcription of explanations I made to people at Microsoft about BitC immutability. The particular approach to immutability that they have applied to patent has been discussed multiple times on the BitC programming language list, not as something that we had any doubts or difficulties with, but as something that we took for granted as obviously doable. We even discussed the escape analysis necessary to ensure constructor safety.
This is the second case of a patent application by someone on the Midori group since my departure that appears to be directly based on my own work and/or my discussions at Microsoft regarding my prior work and the prior work of others. I do know that Duffy has done a bunch of work on resolving some issues in C# that preclude proper implementation of readonly, but he is not the inventor of either the notion of transitive immutability in a programming language nor of immutability permitting construction. Both were discussed on the BitC list prior to my arrival at Microsoft, including a much more general form of immutable initialization relying on confinement. I discussed this work with Duffy while I was at Microsoft. Heck, I've done a Ph.D. dissertation and two formal verification efforts on this topic; it's hardly new.
Given this, I think there is a problem insofar as the patent fails to credit an inventor at Microsoft (me), but more to the point, the patent application fails to cite prior art about which they knew: BitC, EROS, and KeyKOS. Given the prior work, I would have refused to support this filing on the basis of prior art.
Many people at Microsoft hold the view that outsiders can't do anything interesting. They are, in my experience, appallingly unaware of prior art in the field, and sincerely believe that they have invented many things that have existed for some time.
As far as I can guess, Duffy must be the first inventor in the patent, "Duffy, John J. (Seattle, WA, US)". This makes the statement much more important.
Google has maintained a public open source set of immutable data structures for Java since Spring of 2008, and used them extensively internally long before that. Presently part of their Guava library, it was originally released as part of the Google Collections library.
ML has had immutable values (by default) since the early 70's. There are hundreds to thousands of commercial and academic dialects that have been made since then. Particularly relevant here is OCaml, which has "objects", with a keyword to enable mutability. A large percentage of all programming languages today are based on ML in one way or another.
Java (one of the world's most used programming languages) has objects and optional immutability through the "final" keyword. It existed since the early 90's.
In E, it's typical to construct "transitive immutable" versions of objects by pattern, but I can't remember if it has a particular construct to do this automatically.
More lately, Rust and Scala have immutable types with various mechanisms for qualification.
Perl's Moose object system has had immutability since 2010
I am unsure if that counts as prior art, but I once made a proposal to add transitive immutability to RedHat's new ceylon language.
It is available here (will no longer work easily):
but it is fairly easy to see that it assigns an immutability category to every RVALUE and program construct (with the programmer able to declare if the default is not desired), checks if these match with the code, inheritance etc, and generates errors if mismatches are found.
The gist is in there:
That amounts to transitive immutability, although the approach is finer-grained. I don't believe I could possibly be the first to execute this simple corollary of immutability in a mutable environment, but so far, it seems to me, no suggestions seem to have matched as well.
So, I don't know if my work counts (it was on github all the time, was publicly proposed to the ceylon team, but that may not be regarded enough), it never really worked, and is relatively new. I just hope it might help to fend off this silly patent.
Clojure is mentioned in the es-discuss thread ES6,ES7,ES8 and beyond. A Proposed Roadmap. as having these features. It's functional but also has some imperative characteristics. Somebody knowing the language well could probably study the case and determine whether there's anything corresponding to the patent application's notion of safety (which seems to make sense only from an imperative point of view).