mpd@anomaly.sbs.com (Michael P. Deignan) (04/28/91)
I'm very disappointed with 5.0. Nantucket did a great job giving us arrays. They did a great job giviing us multi-dimensional arrays. They even gave us fantastic commands which can manipulate arrays. BUT YOU STILL CAN "SAVE TO" THE F**KING THINGS! What good is an array if you can't SAVE it in a MEM file and recall it at a later time? What good is setting up that array of user-customized default program operation flags if you can't SAVE them? ARGH! MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
jgb@prism.gatech.EDU (James G. Baker) (04/28/91)
In article <1991Apr27.210921.9751@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: >BUT YOU STILL CAN "SAVE TO" THE F**KING THINGS! > >What good is an array if you can't SAVE it in a MEM file and recall it at >a later time? What good is setting up that array of user-customized default >program operation flags if you can't SAVE them? Sorry you're so upset. Although there *are* libraries out there for a few cents that will allow you to save arrays, you could write a function that would save an array's contents to a disk file or database. It's a bit of a kludge, but back with '86 (when arrays were a dream) and even '87 I concatenated all the elements with ~ separating them. Multi-dimensional arrays would be trickier - probably worth the library. It is more complicated to save arrays than ol' memvars. The dimensions are fairly dynamic and each element can be different data types, which is nice but undoubtedly hell for the compiler to do right. If its just 1-dim array, maybe the {item1}~{item2}~ will work for you. Good luck. -- BAKER,JAMES G - Undergraduate Lab Instructor, School of Electrical Engineering ____ _ _ Georgia Institute of Technology, Atlanta Georgia, 30332 | | _ |_) uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jgb (_|. |_). |_). Internet: jgb@prism.gatech.edu, jgb@ee, jgb@eecom, jgb@cc
mpd@anomaly.sbs.com (Michael P. Deignan) (04/28/91)
jgb@prism.gatech.EDU (James G. Baker) writes: >Sorry you're so upset. Although there *are* libraries out there for a >few cents that will allow you to save arrays, you could write a function >that would save an array's contents to a disk file or database. Of course I could. BUT, I would like to be able to say something like SAVE TO <file> ALL LIKE v* Where the v* variables are a combination of "normal" data elements and some array types. A function which just saves arrays wouldn't help in this case. >It's a >bit of a kludge, but back with '86 (when arrays were a dream) and even '87 >I concatenated all the elements with ~ separating them. Multi-dimensional >arrays would be trickier - probably worth the library. Sure, there are ways to get around it - I've had to use some of them. >It is more complicated to save arrays than ol' memvars. The dimensions >are fairly dynamic and each element can be different data types, which is >nice but undoubtedly hell for the compiler to do right. I can't buy this one. After all, Nantucket gave us such useful tools to manipulate the sizes of arrays - you mean they couldn't use some of those same techniques like AADD, etc., when they were RESTORE-ing an array? MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
tleylan@pegasus.com (Tom Leylan) (04/29/91)
In article <27535@hydra.gatech.EDU> jgb@prism.gatech.EDU (James G. Baker) writes: >In article <1991Apr27.210921.9751@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: >>BUT YOU STILL CAN "SAVE TO" THE F**KING THINGS! >> >>What good is an array if you can't SAVE it in a MEM file and recall it at >>a later time? What good is setting up that array of user-customized default >>program operation flags if you can't SAVE them? > >Sorry you're so upset. Although there *are* libraries out there for a >few cents that will allow you to save arrays, you could write a function >that would save an array's contents to a disk file or database. <balance deleted to save space...> James, You're right that if anybody wanted to do it they could simply write the code... it is a language after all not an end user product. To Michael may I suggest you stop using .MEM files. They are kludge and support for them will diminish over time. And before anyone screams at me to defend the "kludge" remark... I have a dozen reasons but primary among them are that in multi-user apps there isn't any locking mechanism so one workstation can change the values behind another station's back. They don't obey scoping rules... variables created in one place mysteriously appear in another. You don't see a declaration in the code you see RESTORE FROM <file> and whatever happens to be there is pulled into RAM. They can modify existing variables without warning which makes "black-box" routines difficult as the variable name is directly related to the thing operating successfully. Personally I think dBASE suffers major flaws as a computer language and the improvements offered in Clipper 5.0 are a welcome move to bring much of it into line with other languages. The changes will not be welcomed by all one of dBASE's claims to fame is that just about anybody can get something that will operate using EDIT mode. Some will see it as a bother, some will see it as impossible and a few will see it for what it is, an opportunity to improve our applications, make them more robust, make our functions more reusable. If anybody is attending the Clipper Developer's Conference in Palm Desert this June, I'm presenting a workshop titled "Evolving S'87 Code to 5.0" you might want to sit in and find out "why" things are done. tom leylan (ex-Senior Systems Analyst / Nantucket Corporation )
mpd@anomaly.sbs.com (Michael P. Deignan) (04/29/91)
tleylan@pegasus.com (Tom Leylan) writes: >I have a dozen reasons but primary among >them are that in multi-user apps there isn't any locking mechanism so one >workstation can change the values behind another station's back. However, they are immensely helpful for maintaining an individual's personal configuration on disk. For example, if I set a series of variables, the 'v*' variables, to "default" values at the beginning of the program, then a user who does have their own "profile" saved is logging in, a "RESTORE FROM" can restore their PERSONAL defaults from their previous session. This has little or no effect on other users. Although it may break your idea of "scoping laws", it still, however, is much better than sitting around with a single configuration file open all the time to constantly read and modify someone's default configuration. Not to mention the dynamic allocation of tables, which are built at run-time and need to be saved for later recall. This, however, is a completely different story. The plain fact is that Nantucket's oversight once again to give people the ability to save arrays is downright inexcusable - especially in light of all the other nice array handling functions they did include. MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
eichi@forty2.physik.unizh.ch (Stefan Eichenberger) (04/29/91)
>To Michael may I suggest you stop using .MEM files. They are kludge and >support for them will diminish over time. And before anyone screams at me >to defend the "kludge" remark... I have a dozen reasons but primary among >them are that in multi-user apps there isn't any locking mechanism so one >workstation can change the values behind another station's back. They don't >obey scoping rules... variables created in one place mysteriously appear in >another. You don't see a declaration in the code you see RESTORE FROM <file> >and whatever happens to be there is pulled into RAM. They can modify existing >variables without warning which makes "black-box" routines difficult as the >variable name is directly related to the thing operating successfully. Well, I give you two examples I use .MEM files for, which would be awfully complicated and overkill to find other solutions for: - Configuration file: Each user can modify his/her own config.mem file, which contains some - in my app. roughly 50 different - parameters, all of different type, length, etc. Each user has its own file in a local directory, the network remark above doesn't hold, therefore. - For security reasons, I've to store a couple of *.dbf files on diskettes only and copy them to harddisk only for the duration of a session, deleting and wipeing them afterwards. Each diskette now also contains a .MEM file, with which I do automatic version control - what if the program gets updated and an old disk still floats around somewhere, and that sort of thing. Of course, both could be done with an abuse of .DBF files, but much more elegant are .MEM files. Scoping rules are implemented by the variable names: c* come from the config.mem, whereever they appear in the application, etc. It's in any case difficult to implement local variables in Clipper apps. (I haven't swiched to version 5 yet, are there improvements?), and binary files - e.g. all other files apart from .DBF and .NTX, things created with fwrite(), fread() don't document file locking mechanisms in Clipper '87! -- ---------------------------------------------------------------------------- iNet: eichi@physik.unizh.ch Stefan Eichenberger UUCP: ...mcsun!chx400!forty2!eichi Physics Institut BITNET: K807817@CZHRZU1A University of Zurich
tarjeij@ulrik.uio.no (Tarjei Jensen) (04/30/91)
If one considers the possibility of users using different computers then a database with preferences seems like a good idea. Also when one want's to use a server, but are unwilling to allocate space for individual users on the server. I think most people would feel more safe with the database approach; less chance of a scrambeled configuration??? Other possibilities; store information about e.g. arrival of mail in config record. This allows other applications to inform the user about these events. The possibilities are endless. -- // Tarjei T. Jensen - if it ain't broken, fix it anyway! // tarjeij@ulrik.uio.no || +47 87 21138 // Working, but not speaking for the Norwegian National Library.
tleylan@pegasus.com (Tom Leylan) (05/01/91)
In article <1570@forty2.physik.unizh.ch> eichi@forty2.physik.unizh.ch (Stefan Eichenberger) writes: >>To Michael may I suggest you stop using .MEM files. They are kludge and >>support for them will diminish over time. And before anyone screams at me >>to defend the "kludge" remark... I have a dozen reasons but primary among > >Well, I give you two examples I use .MEM files for, which would be awfully >complicated and overkill to find other solutions for: I don't want to get into an argument but I personally feel that .MEM files are a total mistake and have never used them and quite easily handle the two example situations that you mention and hundreds of others. Clipper 5.0 implements true variable scoping with STATIC and LOCAL variables and STATIC functions. LOCAL and STATIC variables and arrays cannot be SAVED TO a file, their names don't exist after compilation, they cannot be referenced from within a macro either (same problem). Nantucket and many others including myself recommend complete elimination of PUBLIC and PRIVATE variables. I speak regularly at developer's conferences and that is one of my standard suggestions. Given that there are no PUBLIC and no PRIVATE variables in my apps (and in time in nobody's apps) there isn't a need or use for SAVE TO since nothing is left to save. Bottom line is you can't save arrays, you aren't going to be able to save arrays. It is a design decision not an oversight... it's a simple matter to AEVAL() a codeblock which will process an array in any way anybody sees fit which could involve writing it to disk using the FOPEN(), FWRITE() functions. In any case, I'm happy to answer questions that you might have but "you know what Nantucket ought to do" type stuff is not something I'm particularly interested in discussing. What IBM or Microsoft or Borland or the Whitewater Group does is their decision, I buy the products I like, I pass on the ones I don't. The universe wasn't implemented solely for my pleasure. tom (formerly of Nantucket... just so people know where I'm coming from)