You'll experience a reduction in performance albeit a small one for two reasons. Every access to the array now has to first resolve the object reference, which takes some time. More noticeably, though, is replacing direct array function calls with a user defined method. A method call takes some time, because VFP has to create a new stack level.
I think this is the sticking point. Simple, non-redundant code seems like a good goal, but I've already got enough slow spots in my framework. I don't want to slow down anything further. Especially since I use arrays a lot.
The reason, by the way, for most of my recent questions is that I'm working through my current "5 year plan", first item of which is to repair and optimize my framework based on everything I've learned since I first built it back in 2004.
I eventually plan to port to another language, such as Python, but before I do that I'd like to have my ducks in a row so I'm not repeating dumb mistakes in a language I won't understand nearly as well as I do VFP.
My guess is that the biggest issue is something you haven't mentioned at all: Array properties cannot be passed by reference. So any code that currently passes the array to another function or method has to be rewritten to use the array property. That's either an all or nothing approach by replacing the array in the called method with an object reference, or involves a lot of conditional code based on whether the parameter is an array or an object with the array.
Yes. I had already mapped out a bunch of methods to handle array manipulations so there would not be much need for callers to manipulate the array directly. I was toying with CopyTo() and CopyFrom() methods that would wrap ACOPY(). But as you suggest above, all of this would simply slow things down further.
I could create a library of procedures to be made available in SET PROCEDURE.. ADDITIVE to handle common tasks that take a few lines of code, such as adding a new row. This is kind of what Thierry is referring to. This would eliminate the overhead of a class but would still require a new stack level for each call.
Ah well. It was a cool idea. Thanks to all who responded. This is the fun stuff. Ken Dibble www.stic-cil.org _______________________________________________ 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/[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.
