But this doesn't save much on the typing front, which apparently is the real objective of the question :-(
However, with a 'smart' pre-compiler you can achieve your OO objectives, AND(or) reduce typing. (Of course we have such a beast within our Visage environment) There are some other advantages to this pre-compiler approach, like being able to freely (and easily) change the physical implementation of something if you DO find that there is a more efficient way to work. For example your pre-compiler directive may look like this : &vl REC 15 mysub (I've assumed REALLY short names like vl (for a value loop) to reduce typing, and that mysub is a reference to an internal subroutine to "do something with the variables") The initial implementation of "vl" may initially generate code something like : LAST = DCOUNT(REC<15>,@VM) FOR I = 1 TO LAST GOSUB mysub NEXT I which is a saving on the typing front (my "favourite" is the select/readnext/read/write loop). Or perhaps (better) with a small change to mysub LAST = DCOUNT(REC<15>,@VM) FOR I = 1 TO LAST THIS.REC = REC<15,I> GOSUB mysub NEXT I Our next iteration on the journey may generate this code TEMP.REC15 = REC<15> LAST = DCOUNT(TEMP.REC15,@VM) FOR I = 1 TO LAST THIS.REC15 = REC15<1,I> GOSUB mysub NEXT I to avoid jumping over the leading 14 attributes every time, and if LAST was getting big, then we could change the implementation to generate LOOP REMOVE THIS.REC15 FROM REC<15> SETTING DELIM GOSUB mysub WHILE DELIM REPEAT to gain the advantages of REMOVE (internal pointers for where we were up to in the string) The "nice" thing about this approach is that if you DO find a better way to do "something" that you do often, it becomes very easy to change it "everywhere" in your application. (You can also have 'implementations' of things that may generate something other than Basic code, but that is a whole other story - suffice to say that this "snippet technology" also powers our multi-lingual capabilities) Within the context of our Visage development, by adopting his technique we have a single source tree that can generate code that is targeted/optimised for a particular OS & database version & type. Whilst we can debug with the generated code, we develop at a higher (macro) level Maybe a long way off topic, but if you are serious about reducing keystrokes, as part of our Active Code Reduction initiative we have found that using this type of technique, a single high level pre-compiler directive may generate 5-50 (or more) lines of "efficient", error-free, local-standards compliant code, resulting in faster development, and easier maintenance & enhancements >> Ross Ferris Stamina Software Visage > Better by Design! >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:owner-u2- >[EMAIL PROTECTED] On Behalf Of Symeon Breen >Sent: Friday, 6 January 2006 10:25 PM >To: u2-users@listserver.u2ug.org >Subject: Re: [U2] DCOUNT > >If we where obj orientated we could have REC<15>.dcount but alas no .... > > > >On 1/6/06, Larry Hiscock <[EMAIL PROTECTED]> wrote: >> Mark Johnson wrote: >> >> > REMOVE doesn't give you the MV counter for the associated fields >> > by itself. You have to manage separately and hope to keep in sync. >> > That's more code. >> >> You can do multiple removes on different MV strings instead of keeping a >> counter and referencing the associated fields as REC<X,X>. >> >> For example: >> >> LOOP >> >> REMOVE VAR1 FROM REC<15> SETTING DELIM >> REMOVE VAR2 FROM REC<16> SETTING NOTHING >> ... >> >> { do something with the variables } >> >> WHILE DELIM REPEAT >> >> >> Larry Hiscock >> Western Computer Services ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
