In the OO forum a while back we had a discussion about namespace standards. On OEHive ( http://www.oehive.org/node/674 ) Jurjen has recently raised a question about providing ProLint with rulesets which would help enforce OERA standards such as checking for no UI in data access layer components and no database access in UI components. So far, it seems like the only way that either of us can see triggering this layer-specific behavior is either through naming standards or using a "hint" contained in the file itself. The latter has a lot of potential, I think, but is unfortunate because it requires modifying the file in order to get the special behavior. If anyone has any other ideas, I encourage them to bring them forward there, but for the moment I thought this might be a good opportunity to talk about naming standards as related to AutoEdge, OERA, and just generally helping to keep things organized.
In the OO namespace thread, I think there was some agreement that we should start emulating the standards of much of the rest of the OO world by putting code in a directory structure whose upper layers are something like:
directory would be very large and thus difficult to navigate. I also feel that if one is working on one type of object for an entity, that the most likely other files that one might want to reference as a part of the same piece of work would be other types for the same entity and this is best served by a directory per entity.
Of course, to be useful, if file type is to be indicated by a prefix, prefixes would have to be universal. It seems that there is a tendancy to make prefixes short, "Hungarian-like", if you will, while it is more natural to use longer names as suffixes, but there is no reason that one couldn't use the same indiacted in both places, i.e., DSCustomer.cls or CustomerDS.cls.
As a footnote, I will observe that the AutoEdge standards specify all lower case file names, but I see no reason personally why we haven't outgrown this along with 8+3 filenames. Not every operating system will respect the difference, but the only downside I see to this is if one was daft enough to want to name two files the same, except for case ... which I wouldn't exactly suggest as a best practice. Other than that, it only means that one must be careful in one's typing, but I think that the advantage in readability is worth that effort.
So, what do other people think?
I'm not sure about commenting on the topic Tom's raised here, but I did find this interesting paper over on http://www.namesys.com/whitepaper.html, which discusses namespace management issues in the context of designing and implementing a high-performance file system.
From the page: "The utility of an operating system is more proportional to the number of connections possible between its components than it is to the number of those components. Namespace fragmentation is the most important determinant of that number of possible connections between OS components."
Could the same ideas discussed in this paper could be applied to the development of OO class and procedure-managed objects?
Some amusing bits about that paper, but ...
For starters, the naming standards questions I have raised here about naming a file in a filesystem. That pretty much has to mean that it will be hierarchical even though there are obviously ways in which we would wish it to be multi-dimensional.
Relative to the issues I raise above, I don't think it is necessarily even a bad thing that at least the upper portions are hierarchical. The groupings from module on up correlate strongly to principles such as "interact with each other" and "must be installed together".
Which said, one of the things I wondered is just how old that paper is, since it seems to have been written in a pre-Google world. I have been interested in fully inverted system since at least the early 70s and there have been a lot of interesting things done there, but Google and the other search engines have quickly catapulted these systems into a whole new realm of reach and speed.
For finding things in a code base, I think we want multiple tools suitable to the type of query. One can fantasize about an interface which unifies these tools into a single query function, but frankly I think that the ability to make the query is more important than whether or not one has the unified interface. The tools one would want include:
1. The filesystem based classification described and questioned above since it groups related files (one of the reasons I favor grouping by entity rather than layer).
2. Grouping by annotation as implemented in OEA, which provides a simple, free form, classification system.
3. Retrieval by syntax, i.e., a database resulting from XREF and Proparse analysis of the code so that one can ask where a particular field is used, even when it is in a buffer differently named than the table.
4. Unstructured, fully inverted search.
What struck me from what I read of the paper was the idea that being able to interconnect portions of the system increases the ability to have the system get things done, which mirrors what I've found in working with my procedure management system.
On finding things in a code base, I hear you completely - in fact the xref parser code I'd released was a big step in that direction before other things took priority. If one could take the output from that and a Proparse system, feed it to a db, and then query that db....writing new or legacy code would be revolutionized.
In mapping object naming standards to a filesystem files, there'll naturally be a hierarchical structure imposed not just on the nature of how filesystems work, but because because "table/driver" level code has to follow the db structure. But once a program gets about two - three levels of functionality above the table / driver level, I've seen more cross-table / functional area interactions. These functional blocks may not necessarily easily map to a directory / filesystem structure.
So far, my experience's been that these cross-functional "integration points" have all occurred at 'top of the tree' of a program structure. As such, I've been able to keep map all the lower level code to places in the file system hierarchy.
So far. I keep expecting to find some situation in the future where this can't be done. But I haven't run into that situation quite yet.
I do think we might actually see this from PSC
one of these days ... just the XREF part, of course. I think the
XREF to XML piece in 10.1B was intended as a precursor for that in
part. But, I doubt they will do the equivalent of what one could do
to extend that by using Proparse to index every token. Just think
how lovely it would be if they did that and then funded extensions
to ProRefactor to cover all the deprecated keywords. What a boon to
modernization ... at least of the low level code, if not the
architecture. This isn't, however, getting us any farther along in
the basic program naming standards question which opened this
thread. I'm not getting how your "cross functional integration
points relate to naming. Or, even perhaps what you mean in concrete
terms.
This isn't, however, getting us any farther along in the basic program naming standards question which opened this thread. I'm not getting how your "cross functional integration points relate to naming. Or, even perhaps what you mean in concrete terms.
TMH - It's Dec 23 and you're responding to my posts?!? I'm watching "flip this house" while fiddling with my laptop on PSDN during the "dead air" parts of the show. What are you doing?
Wrt cross-functional integration points - naming objects from an ordering system or customer system's easy.
When you have an object that needs something from a combination of the order, customer, accounting, et al systems - what do you call it? Such an object doesn't necessarily fall under the purview of any single hierarchy - so (a) where would it go, and (b) what would it be named?
The XREF->XML feature's a "nice to have", but it'll be years before 10.1B and following versions will become the predominant PSC platform in use out there. And "all" it really does is make parsing the xref output a lot easier, but it doesn't deal with the "everything that comes after" part.
But it is a start!
There are, of
course, two problems here ... one is getting the tool actually
built and the other is making it available to the people who are
"stuck" or getting them "unstuck". Unfortunately, the XREF->XML
piece and suggestions of databasing this information in the future
actually demotivates a third party to try to create their own
Eclipse plug-in, which might use more information than would be
provided by XREF. This would be a great opportunity for PSC to get
together with people in the developer community and do something
open source. We would get it sooner and it would be a stronger
tool. As for the people on older versions, I think this is one of
the great unsolved mysteries. Solving it could make a major impact.
I wonder if one could package OEA in such a way that one could set
a parameter for the version ... should mostly just be selectable
keyword forget lists, no? Of course, the big victory would be
figuring out how to get people to move forward. This would be so
much more of a dynamic community if we were all on OE10.