Richard Bucker

Object oriented namespace fractal dimension

Posted at — Oct 9, 2013

Back in the early days of assembly language programming and even some of the earlier basic programming the idea of object-oriented programming was never a consideration. Everything from  variable names to subroutines all existed in the same namespace. Software in the 70s and 80s work just as well as their counterparts today however modern programming languages have partitions libraries and access to functions and variables by using namespaces. The current project I’m working on emphasizes the notion of global namespace is a global variable names global functioning. The names themselves of becoming a mod the old days of COBOL when artifact names are much larger than they are typically today.While name spaces can Clyde it doesn’t typically happen the reality is that the names are predictable and there’s absolutely no reason why they should ever overlap. Because they’re predictable one can develop an internal mechanism for predicting the way names and functions and artifacts in general are named making it easier to predict across the blurry lines of object-oriented programming.One can consider that artifact types and artifact names are synonymous. Instances are still possible however that is managed by context container.One can consider a variable name called credit card and it may be a commit container for a generic credit card number however in the most specific use case one what identified as being either a Visa MasterCard or American Express credit card number and attached to the artifact would be the validation that goes with it. Since it is intrinsic to the type as well as the artifact name the realized artifact name this means that as the artifact itself is changed those changes are inherited by all of its instances. This type coupling or contract between the players make for a much more predictable system.