>>>>>>>When I write the code I will never have the problem of using the m.dot or not using the m.dot. My coding convention uses the above rules. However, when we use classes that the community has written now we could have potential naming conflicts between variables and fields. So having the compiler enforce the rules is preferable.
>>>>>>>
>>>>>>
>>>>>>Just want to point out that the Hungarian naming convention isn't infallible. While it's a bit of a stretch, it's certainly possible to have a field name lOrange and a variable named loRange. I haven't gone hunting for other examples, since one makes the point, but I'll bet there are others that are plausible.
>>>>>>
>>>>>>In my view, VFP developers should always use mdot where there's any chance of ambiguity. That's even more important for tool writers since they have no control over the naming of fields in tables their users create.
>>>>>>
>>>>>>Tamar
>>>>>
>>>>>To avoid ambiguitiy as much as possible I tend to use objects instead of simple variables. An object with the same name as a field can be used without m. as long as you reference any of the object members. It also provides you a level for extension methods that can be very useful in daily coding life.
>>>>>
>>>>>CREATE TABLE Test (loTest C(10))
>>>>>INSERT INTO Test Values ("Field")
>>>>>LOCAL loTest AS Label
>>>>>loTest = NEWOBJECT("Label")
>>>>>loTest.Caption = "Label text"
>>>>>MESSAGEBOX(loTest)
>>>>>MESSAGEBOX(loTest.Caption)
>>>>>>>>>>Therefore I use classes for repetitive work like for counters or strings:
>>>>>
>>>>>* Instead of
>>>>>LOCAL lnCounter
>>>>>lnCounter = 0
>>>>>lnCounter = lnCounter + 1
>>>>>Messagebox(TRANSFORM(lnCounter))
>>>>>* it is better to do
>>>>>LOCAL loCounter AS Counter OF Utils.vcx
>>>>>loCounter = NEWOBJECT("Counter","Utils.vcx")
>>>>>loCounter.DoAdd()
>>>>>Messagebox(loCounter.Value_toString)
>>>>>>>>>>
>>>>>And with strings for example:
>>>>>
>>>>>LOCAL loString AS StringBuilder OF Utils.vcx
>>>>>loString = NEWOBJECT("StringBuilder","Utils.vcx")
>>>>>loString.DoAddNewline("Hello")
>>>>>loString.DoAdd(" World")
>>>>>Messagebox(loString.Value)
>>>>>loString.Replace(" ",CHR(13))
>>>>>Messagebox(loString.Value)
>>>>>Messagebox(loString.Lines.Count)
>>>>>etc
>>>>>>>>>
>>>>Hi Christian
>>>>
>>>>That works, but objects and properties are horribly slow compared to memvars - like more than 5 times slower. If you add access and assign methods then the performance drops even farther.
>>>>
>>>>I'm also always telling people that arbitrarily grouping different things in a vcx is wrong. The point of programming is to make encapsulated little pieces which operate at runtime as separate entities. So why then aggregate them at design time? Instead of counter in utils.vcx, it would be better for a development team to have counter in counter.vcx. Then one developer could work on counter while another works on some other class. This aggregating of things, whether classes or udfs is really completely unnecessary and actually slows down development - because you must use source control or have developers waiting on each other.
>>>
>>>You are perfectly correct with that statement. I also simplified the examples to show the general idea. But yes, after learning those design principles I also moved from creating those monster libraries to now separating those into the logic building blocks.
>>>So what I have now is Utils_DateAndTime.vcx etc.
>>>
>>>Regarding performance: Also correct, but when performance needs to be tweaked there is always a necessity to think outside the box. The best design is not always the best performance, that needs to be decided in those situations.
>>
>>I'm going to send you an article I wrote - I got massive re-usability and massive performance improvements by knitting SQL together at runtime. So instead of a SQL command calling out to an external UDF or object.method, I knitted the formula of the UDF directly into the SQL. That sped things up a lot! Then - because I stored the UDF formula as a string with "templated" sections, I could alter the one formula to fit any field names - that made a single complex formula very reusable. It seems like overkill, but I view most programmers' code as severely "underkill". Thinking outside the box - as you say - the way I did in the article hit all the points of code reuse, code performance and encapulation and did it without preventing multiple developers working in the library at the same time.
>
>Thanks a lot. I must say that I learned a lot from your SQL queries you helped me with in the past. I saved most of them for reference and often go back to them when I need to refresh my memory. Since then I also never needed to revert to VFP side data crunching.
>
>Downside is that I now need to work on a VFP Program with Foxpro tables. The project was started 35 years ago and got converted to VFP using the converter. It is like a time capsule, with a main.prg that contains hundreds of procedures and hundreds or probably thousands of global variables. I constantly need to decide if it is better to introduce new functionality using a language that is foreign to the project, or to write the code in the same style to keep integrity of the code style.
>The first has the advantage of creating reusable powerful code, while the latter has the advantage that it seamlessly integrates with the existing code base. However my personal preference is often the first, because on the long run you get rewarded by having to do less work and more stable and testable code.
Maintaining the style of the code is not important. It's a fact that the previous programmer - even or especially if it was oneself, could not be as skilled as now. Incorporate new knowledge at the expense of "style" - the benefit is to the customer - which is really all that matters. I have done some queries in FoxPro against FoxPro tables - even recently that dropped 10 hour jobs down to 30 minutes - and could have done much more, but I was in a hurry. I did one recently that dropped 3 hours down to under a minute. "Style" is irrelevant.
