Separate Meaning From Presentation

I used to use SyntaxFollowsSemantics for this concept, but realized that it is beyond just programming syntax. It comes up in user interface issues also (such as WimpIsBroken), for example. Thus, I am creating a wider topic. I don't yet have a good written description of the concept. Volunteers? --top

Related topics:

Maybe it is not so much about "separating", since physical location has little or no meaning in the virtual world, but more about accessing the "atoms" of information without parsing or hacking.

I strongly suggest to click on the LikePages button and have a look at the left column.

In OoBestFeaturePoll, Top suggests SeparateMeaningFromPresentation is a not yet existent ideal when he says "separation is a bit idealistic". There are many DomainSpecificLanguages out there, surely there is one which demonstrates SeparateMeaningFromPresentation. -- PeterLynch

Perhaps you mean SeparateDomainFromPresentation?


Top uses 'SeparateMeaningFromPresentation' in a manner inconsistent with its normal usage. SeparateMeaningFromPresentation is violated when presentation features (such as bold, font, font size) are combined in representation with semantic features (e.g. structure: paragaphs, tables, chapters, titles). A DomainSpecificLanguage that demonstrates better SeparateMeaningFromPresentation includes the use of CascadingStyleSheets to attach presentation features to XML or HyperTextMarkupLanguage.

Top uses 'SeparateMeaningFromPresentation' with intention that might better be described by 'SeparateDataFromRepresentation?'. This concept is violated by languages such as C++ that encapsulate attributes inside objects in a manner that automatically implies conditions on the physical representation of that data. It can be repaired by allowing access to and storage of attributes of an object to be specified independently of the procedures that describe that object's behavior. Doing so would allow objects to essentially be 'views' (potentially updateable views) of a database, whilst still allowing local data storage where it is appropriate for optimizations (e.g. caches). This sort of separation has been used to good effect for such things as arbitrary mixin support and concept-oriented programming. A few OO languages, including Ruby and Smalltalk, seem to support SeparateDataFromRepresentation? by treating attributes as a pair of getter/setter procedures that may be overridden at any time.

One thing to note about SeparateDataFromRepresentation? is that it forbids 'pointers' as they are usually utilized, because you cannot 'point to the representation' of any particular data item. Everything (including pointers and references) must be stored as values (which must be first class), and if one needs a 'pointer' the one gets what is essentially a FirstClass 'getter' (for dereference), a FirstClass 'setter' (for assignment), or a pair of the two. While parsing or serialization or database queries or whatnot might be part of executing these mechanisms, those tasks become encapsulated within the 'view' mechanism (getter/setter) functions. A 'pointer to another object' really is a getter procedure that returns another view of data with its own getters and setters and associated procedures.

Personally, I am in agreement with both SeparateMeaningFromPresentation (its normal use) and SeparateDataFromRepresentation?, and fully believe that languages should automatically support them. But I feel TopMind often overstates the benefits of following SeparateDataFromRepresentation? more extremely... he seems to believe one could get a major benefit out of putting everything into a database, and on such pages as 'AdvantagesOfExposingRunTimeEngine' he points out the benefits for debugging, but he completely ignores issues of security, of modularity, of CouplingAndCohesion, and even of SeparateMechanismFromPolicy? (which is his goal in the first place!). You can't really specify which database the object accesses to get/set attribute data if you are to SeparateDataFromRepresentation?: a single runtime could have objects with components stored in over a dozen distributed databases.


You'd need to be more specific about the alleged downsides of TableOrientedProgramming with regard to security, modularity, etc.

Note the I find some forms of "modularity" to be hard-chunking of concepts that should be relative. In other words, view-based modularity instead of a hard separation is a better goal. One can use a separate table(s) or attribute to provide a virtual grouping without changing the original info; and have multiple orthogonal groupings that don't conflict with each other. Attribute-handling math is generally easier than behavioral math. --top


I wish I had not asked -- PeterLynch

In response to the bar conversation above, I can resolve your differences. I sentence you to collaboration in development for more than six months. Eventually you will see the basics upon which you agree. All peer reviews will be filmed to provide enlightenment and entertainment to many of us. (Not to exclude those of us who need no enlightenment)

Make sure you take out good insurance on such an office building.


OctoberZeroEight

CategoryInfoPackaging


EditText of this page (last edited July 9, 2010) or FindPage with title or text search