Why not consider collection(s) or list over the array? The collection seems so much more flexible than dealing with an array.
On Thu, Apr 4, 2013 at 9:44 PM, Ken Dibble <[email protected]> wrote: > This may be a question for Christof or someone with similar deep knowledge > of how VFP works. > > I use arrays a LOT. > > I DIMENSION, ASCAN(), ADEL(), and ASORT() them, and consult their ALEN()s > constantly. I iterate through them and perform actions on their elements > repeatedly. Sometimes I even AINS() them. > > I'm thinking it would be wise to create a class that encapsulates this > stuff and clean out all my duplicated use of those commands and functions. > It certainly would put an end to unexpected "Array dimensions invalid" > errors when I forget to check an ALEN() somewhere. > > I think the class would have an array property, and methods to carry out > those functions on it. Whenever I need an array I'd instanciate the class, > if necessary ADDOBJECTing it to another object. > > I can easily see how to do this. > > My question is, what is the "weight" of having potentially several dozen > instances of this array object hanging around in memory, even if, for some > of them, I will only need one or two of the object's capabilities? Is this > a bigger drain on resources than just duplicating array manipulation code > whenever I need it? > > I'm thinking that I remember hearing that VFP only really stores one > instance of a class's structure in memory no matter how many times it's > instanciated in code, then uses reference counters and maybe some kind of > "diff" function to keep track of the values of the class properties > associated with each instance. If that's true, maybe this isn't something > to worry about. > > I know that the answer is "Test it and find out." Writing a test of this > proposition will probably take longer than creating the class, and creating > the class will take a while, considering all the stuff I want in it. So if > it wouldn't take someone very long to answer this question, I would sure > appreciate it. > > Thanks. > > Yours in Keeping VFP Something to Talk About, > > Ken Dibble > www.stic-cil.org > > > > ______________________________**_________________ > Post Messages to: [email protected] > Subscription Maintenance: > http://mail.leafe.com/mailman/**listinfo/profox<http://mail.leafe.com/mailman/listinfo/profox> > OT-free version of this list: http://mail.leafe.com/mailman/** > listinfo/profoxtech <http://mail.leafe.com/mailman/listinfo/profoxtech> > Searchable Archive: > http://leafe.com/archives/**search/profox<http://leafe.com/archives/search/profox> > This message: http://leafe.com/archives/**byMID/profox/5.2.1.1.1.** > 20130404222940.01fbb0d0@POP-**Server.stny.rr.com<http://leafe.com/archives/byMID/profox/[email protected]> > ** All postings, unless explicitly stated otherwise, are the opinions of > the author, and do not constitute legal or medical advice. This statement > is added to the messages for those lawyers who are too stupid to see the > obvious. > -- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN 901.246-0159 cell --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cajidmykty7wswjj_rmjzevxhnzke1rbz-d2i9tr9pan81g6...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
