"Heresy is a controversial or novel change to a system of beliefs ... that conflicts with established dogma" (Wikipedia)
If you start working with Soplets you must be prepared to do away with some well-established beliefs you (or worse, some of your coworkers) might have with respect to a 'good' programming praxis:
has written since its inception in the 80's a success story without parallel. It is universally regarded as the foundation of modern software development, and a synonym for well structured programming par excellence.
However, amidst all the euphoria, it might be overlooked that nothing is perfect in this world, and that also OOP has its limitations and shortcomings. In fact, we will discover that OOP cannot be applied with the same level of success to all aspects of software engineering.
One of the unwanted side-effects of OO programming is the lack of transparency. Objects exist just in the code, and are not (immediately) visible to an outside observer. An emphasis on thorough documentation as well as auxiliary tools, such as MDA (model driven architecture) or JavaDocs try to alleviate this issue, but they come with a high price tag, and do not really meet the evil at the root.
Another drawback of object orientation is the high level of freedom it offers. While in many cases, this level of freedom is a good thing, it also leads to a high level of arbitrarity (meaning there are potentially many solution for a given problem), which makes it difficult to write the code in the first place, and read it for the next programmer to come in the second place.
Last but not least, there are quite limited options to manage object oriented code during its life cycle with administrative tools. Again, MDA and other approaches such as RAD (rapid application development) tools try to get a hold on the code by repeatedly generating it, but they add considerable complexity to the code, while severely limiting the flexibility of the programmer (agile programming!), making it hard for the programmer to efficiently maintain the code over time.
Considering all these circumstances, it becomes clear that OOP is a very powerful and versatile paradigm at the hands of the programmer. But on the other side it has a number of drawbacks, which have to be addressed. The strategy of axiomatic programming is to limit the use of OOP to where it is really needed and makes sense and use a simpler, more structured approach in all other cases.
This process has several drawbacks, namely:
a) the Semantic Entropy (no strong typing, no navigation support, no inherent orphan control),
b) sending documents back and forth is outdated,
c) merging problems during ongoing development processes
Soplets treat translation just as any other property of a semantic concept. There is no compelling reason to handle them in a special way - all the contrary. By embracing translations as regular Soplet citizens, they enjoy the same advantages and life cycle support (refactoring etc.) as any other attribute.
You can find a Soplet-based solution for translations at http://www.freenls.com, which supports round-trip engineering support for multi-language applications.
The chapter Static or Dynamic? discusses this issue in depth. For what Soplets concerns, one should be conscious that putting data in a database has a price tag attached, which must not be overlooked.
a) Semantic Entropy (again..!)
b) Onerous release management
c) More code (O/R mapping configuration, DAO access)
d) Strong typing (in many cases, static entities have references in the code)
The only drawback of Soplet based entities which is important to consider is the referential integrity, which is not possible with the identifiers located in the code.
Basically, configuration is nothing other than wiring things together. The difference to actual (Turing complete) programming is that it has no strong typing, no refactoring support and a high level of inherent entropy. Again, the question must be asked, how often the change actually happens, and what is the cost of having this kind of flexibility.
Soplet proposes to do the wiring the Soplet way, inside the code, and just put in external files that is absolutely indispensable and actually context dependant (such as the deployment environment, or parameters which must be changed during running course).
Sopity Java Extension, and leave the path of the pures and immaculates.
Sopity adds certain language enhancements to the Java language (such as enumeration/annotation inheritance or byte-code generation) which are not supported by the standard development environment. This means that you have to commit to a new, unproven, non-standard technology for the rest of the project's life span, which can be 10 years and beyond. And, to make matters worse, there is no easy way back if you (or one of your successors in charge of the project) will one day change your mind.
Having said all this, it is also fair to make a point in favor of a language modification, namely: