Support for immutable at the class level

[GoogleCodeExporter]

Currently, you can declare an attribute as immutable.

However it can often be extremely useful to create entirely immutable classes. 
For example a class that encapsulates a point or a complex number.

Suggested umple syntax:

immutable; // all by itself not followed by an attribute name

Semantics:

1. All attributes would be immutable (no setters).
2. No -- (bidirectional) associations
3. Outgoing associations -> only allowed to other immutable objects.
4. Incoming <- associations allowed.
5. No state machines (since no ability to change attribute values).
6. Lazy immutable would be allowed. Lazy would default to lazy immutable.

We might want to enable these to implement clone by default.

Original issue reported on code.google.com by TimothyCLethbridge on 19 Oct 2011 at 7:59

[GoogleCodeExporter]

Original comment by TimothyCLethbridge on 1 Dec 2011 at 6:34

• Added labels: Type-ProjectUG
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Feb 7th : immutable" keyword added at class level. Immutable classes force the 
class's attributes to be immutable as well.

Feb 17th : made changes to meta-model to make associations immutable, and 
enforce rules for the types of associations an immutable class can have. Parser 
modified and tested in accordance with these changes and with the resulting 
parsing errors that may now occur if the rules are violated.

Note: the above rules for permitted associations were analyzed and deemed to be 
correct.

Original comment by perpetua...@gmail.com on 18 Feb 2012 at 12:39

[GoogleCodeExporter]

Feb 18th : added logic to meta model and parser to prevent immutable classes 
from having state machines.

Feb 20th : Java JET templates modified so that immutable associations are now 
represented correctly in Java code.

Original comment by perpetua...@gmail.com on 20 Feb 2012 at 5:20

[GoogleCodeExporter]

Feb 20th: Additional changes made for the Java code generation. (If/when 
critiquing the original patch for the JET template changes, please additionally 
take into account the improvements that have been made in subsequent commits, 
up to revision 1498.)

Original comment by perpetua...@gmail.com on 21 Feb 2012 at 12:00

[GoogleCodeExporter]

Feb 20th : Changes to the php code generation have now been committed.

Original comment by perpetua...@gmail.com on 21 Feb 2012 at 6:29

[GoogleCodeExporter]

Feb 21st : ruby code generation changes have now been committed.

Original comment by perpetua...@gmail.com on 22 Feb 2012 at 2:46

[GoogleCodeExporter]

This issue remains in progress pending the development of C++ support to the 
point of sufficient stability that this language feature can be added to the 
code generated for C++.

Original comment by perpetua...@gmail.com on 29 Mar 2012 at 7:32

• Changed state: Started

[GoogleCodeExporter]

Original comment by TimothyCLethbridge on 15 Jun 2012 at 2:27

• Changed state: MostlyDone
• Added labels: Type-Enhancement
• Removed labels: Type-ProjectUG

[GoogleCodeExporter]

Original comment by TimothyCLethbridge on 27 Sep 2012 at 8:07

[GoogleCodeExporter]

When a class is declared immutable, the default trace should be getter instead 
of setter because it doesn't make sense to use a default tracer for an 
immutable class that doesn't generate setters. Another option is to return an 
error. Currently, if you run the following example:

tracer File;

class A {

  x;
  trace x for 5;
  immutable ;

}

No error in the generated code, but the tracepoint (or filetracer calls) are 
not there although tracing artifacts are being generated. This doesn't look 
very cool. Therefore, I guess either we should inject tracepoints (FT calls) in 
getter or remove these artefacts.

Original comment by thesulta...@gmail.com on 5 Dec 2012 at 8:41