Attumi (email Batch C) - A Java-like Language with default immutability...

This is the fourth in a series of 5 posts:

1. Why?
2. Attumi (email Batch A) - A Java-like Language with default immutability
3. Attumi (email Batch B) - A Java-like Language with default immutability
4. Attumi (email Batch C) - A Java-like Language with default immutability (this article)
5. Attumi (email Batch D) - A Java-like Language with default immutability

---

This is the next post showing the self-email-chain I wrote in response to my  creative brainstorm started in 2010/November regarding my designing a "What's next?" language to follow Java. 

Here is the third batch (of four) notes, mostly unedited:

<BATCH_C>

1. define notion of an init-once, read many method (for lazy initialization) to clear overhead of check for initialization every time method called
2. default of transparency (everything is public) and hidden state must be specifically called out
3. check out http://fantom.org/ for their approach to multi-threading (i.e. actor based with immutability)
4. allow passing parameter by name (while ensuring no speed gain/loss for using name as opposed to position - use stubbed API call point to map name to position
5. allow defaulting of unpassed parameters - when combined with parameter by name, vastly reduces boilerplate code for implementing class constructors
6. allow struct/tuple (multi-value) return instance so return from function can be multi-dimensional without formalization of class definition (temp class which will likely reify into real class later)
7. consider removing null entirely (force the meaning of empty, or undefined)
8. mature versions of modules, packages, access along with something like partial classes (develop requirements for information hiding versus deployment versus security) 
9. promote aspect oriented programming (useful for logging/transactional separated from functional code) - consider it being useful for debugging (and during debugging, allow aspects to be explicitly skippable)
10. consider defining a "test" characteristic that when a class is defined as a test, it can have access to more private parts of a package/module so as to allow for exhaustive testing without impacting the design by forcing the package/module to expose things to the world just so testing can be complete
11. facilitate immutable pathing to enable soft/weak reference implementation - lazy instantiation pathway can be marked with degree of expense in regenerating so that how that reference is stored (more local to CPU all the way to some form of swapped network based storage) enabling a continuously changing set of options for memory locality - also enables regions to cycle through heating up (come closer to CPU) and then cooling down (push closer to network storage)

</BATCH_C>

As I said with batches A and B, depending upon interest, I will consider diving into some/all of these and exploring my thoughts and reasoning.