[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mumps-l
Subject:    Re: /M and OO Programming, the micro - M programmi
From:       Greg Kreis <Greg_Kreis () ATLMUG ! ORG>
Date:       1996-08-26 19:04:22
[Download RAW message or body]


In message ID <4uliut$lcm@newsbf02.news.aol.com> on 8/11/96, vanharten@aol.com
wrote:
> l. Routinenames are not descriptive. They are used to give to the routine
> a physical allocation and, within groups, a hierarchical position.

I would be careful about overloading the routine reference.  If you put too
much information into it, then circumstances may require it to change,
particularly the hierarchical aspect.  Then we have a maintenance/referential
integrity problem.

> 2. The first three characters of the routinename are used as the
> Systemidentifier.This is to avoid conflicts with often used two byte
> identifiers.

I am not sure here what you mean by the System identifier.  Please clarify?

> 3- The names are build in hierarchical order, so ABC1 calls ABC11 which
> calls ABC111 and so an. So you will get some kind of access levels and
> everybody in the team will now where a particular routine has to reside.

What happens if I decide, due to a design change, that I need to insert a
routine into the hierarchy?  Then I have to rename the routines below it,
right?  Also, this limits the depth of the calling tree, right?

> Routines are divided into Three Types:
> . Gate
> . Body
> . Library

I like the idea of creating classes of routines.  This gives some uniformity
to the developer's approach and that generally makes for easier maintenance
and training.  Also, if well defined, these permit easier substitution of user
interfaces.  MANY M based systems did not take this approach early on (no
blame being placed here, I did it too), so the view and the business rules and
the data are totally stirred together.

> all right, this has been a lot off stuff for now. But one thing leads to
> another and this set of conventions is the base system we are using now
> successfully for years. lt is not as restrictive as it might seem to be by
> the first look, but it helps keeping your system transparent. Try it out.
> lf some explanations are not clear, ask.

Coding conventions and non-standard M isolation is important in a standards
document (IMHO).  The VA's software owes much of its success to its adherences
to some standards, particularly with respect to non-standard M isolation.
Without it, portability is quickly lost.

BTW, does anyone else notice how all too easily many in the M community are
swayed to a MicroSoft-centric approach to development?  Have the M community
and vendors lost their zeal for open standards due to the long struggle they
have seen in the MDC?  It seems strange to me that as a new day is dawning on
the computing community and open standards are finally beginning to take root,
that a large portion of the M community will be found in Microsoft's camp.  I
know, business puts great demands on vendors to provide what customers want.
But I wonder how many customers are just responding to what their vendors
provide?  It just seems ironic to me that such a strong heritage of
portability and standards has resulted in a thickening Microsoft umbilical
cord.  Comments?, he says, as he stands back to avoid the flying fruit and
vegetables.. ;-)

[prev in list] [next in list] [prev in thread] [next in thread]