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

This is the fifth 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
5. Attumi (email Batch D) - A Java-like Language with default immutability (this article)

---

This is the final 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 fourth and final batch notes, mostly unedited:

<BATCH_D>

1. make sure that interfaces provide extendable/configurable factories for implementations based on general performance requirements (as opposed to encoding them in a particular implementation strategy available at the time the code was written) - this will enable better and deeper implementations to be written, thereby elevating the available performance without code recompiles - it will also allow better self-tracking resources which can replace their implementations with better strategies through accumulated metrics (perhaps with secondary thread "watchers" who keep the metrics costs away from the primary code pathway)
2. facilitate collections code mapping to support a SQL query style syntax (should work very efficiently with immutable object trees) - thought based on this FLOSS extension for Java: http://josql.sourceforge.net/index.html
3. vastly reduce the cost of composition to reduce the desire to use inheritance - consider having a class able to implement an interface and also specify the internal reference to a class to which all non-reimplemented methods will be forwarded (UnassignedReferenceException thrown if method forwarding attempted and instance has not assigned the internal reference)
4. move equals() and hasCode() out of Object and into an interface - logically groups the functionality so that if one is reimplemented, so is the other - do not implement at Object...do like Eiffel and have as independent implementation which can be specialized/extended via inheritance or interface/composition
5. consider adding Iterable interface by which is optimized for use in for() loops
6. provide tuples (temporary grouping of values without methods without having to formally define a class, i.e. a temporary struct) for both arguments into a method (like Java's varargs) and as a return value - should minimize amount of boilerplate "temp" code required to implement simple composition and re-implementation classes and methods
7. default to NotNullable for all declarations and require Null be explicitly requested/defined
8. default to methods NOT being overridable (must explicitly identify method as being overridden)
9. can allow decendants to extend (don't have to make final) immutable classes as the immutable guarantee holds
10. when determining requirements for collection type, use these characteristics: A) identity duplicates allowed (==), B) value duplicates allowed (.equals), C) value similarity allowed (Comparator), D) iterator ordered (Comparable.compareTo()), E) immutibility, F) degree in which to favor speed (of specific operations) versus space (weak and/or lazily instantiated context) - use a builder with these parameters to return appropriate implementation to specific interface - enable plug-in replacements at Builder itself (for replacement implementations)
11. in specialized file for enhancing execution optimization logic, allow alternative lower level optimization (perhaps even assembly) where the context of the assumptions outlining the use of the alternative code would be asserted and it would only call the alternative if the assumptions were true
12. consider all potential sources of side-effect randomness and attempt to eliminate to allow perfect deterministic models to be written without accidental side-effects (ex: Java HashSet/HashMap.keySet() and the multi-threaded GC interaction resulting from the default implementation of hashcode being an interpretation of the instance's memory location - use in thread Random)
13. Research Google's Go as a possible influencer on direction of design : http://golang.org/doc/go_faq.html
14. Good Java concurrency subtlety article (influence how operators are grouped - increase domain of atomicity - or explicitly disallow the syntax - i.e. assume immutable and multi-threaded throughout the entire language - create "safe zones for mutation" and for "thread communication"): http://www.ibm.com/developerworks/java/library/j-concurrencybugpatterns/index.html
15. Nice coverage of using inheritance in OO versus delgates in functional languages (need to facilitate both) using Clojure: http://www.ibm.com/developerworks/java/library/j-clojure-protocols/index.html

</BATCH_D>

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