>>I don't want convince you.
>>Only, a logical proposition:
>>- you can think to all the correct programs that can be written with VFP,
>>and now divide this set with in that use m. those that do not use m.
>>
>>VFPUniverse = VFPUniverseWithMDot U VFPUniverseWithoutMDot
>>
>
>>In the VFPuniverseWithMDot all the programs they work,
>>while
>>in VFPuniverseWithoutMDot
>> - a part works,
>> - a part does not work
>>and
>> a part generates wrong outputs.
>
>If the above were the absolute and only truth I´d be convinced. However:
>
I'm happy for this.
>- There a certain situations were you cannot work with m. (e.g. macros)
Yes, but
a) VFP formal design, it is a lot far away from the correctness,
then m. rules it is not strong rule:
rule it is : when you want to use a memvar, and language it is ambiguous
then you have to use m.:
- on macro VFP uses only memvars ( then the context it is not ambiguous )
and this program are within VFPuniverseWithMDot because
a program with
&m.memvarname where m. it is the prefix is out of VFPUniverse.
True cause it is a little bad design:
clear
memvarname='1'
&m.memvarname
m='? '
&m.memvarname
&m.m
>- There are certain situations that are buggy when using m. (e.g. I remember a bug reported by you because of using m.THISFORM) and I recall to be other problems when referencing problems with m.
>
Walter, any program with bug effects it is out of VFPUniverse
I cannot compensate a bug with an instruction formally mistaken
(in practical I will be forced to make it in waited for of the correction of the bug)
>In a sense my point is this:
>- There is no way you can program all posible solutions either with consistent use of m. for each and every variable, and there is no way you can everying program without it. So there is no VFPuniverseWithMDot and no VFPuniverseWithoutMDot either.
>
Walter, you merge formal universe with real universe. The use formal universe because it sure more exact of the real world
>OTOH, if I´ve got to choose between the way the majority uses m. (as outlined on the wiki) or the way you use to emply, I´d choose the latter. IMO the wiki topic is an idiotic way of coding having to learn stupid rules when to use them or not, from at least an outsiders point of view.
>If you want to be consistent then use them in all cases possible and not having stupid rules when not using them because there can be no confusion.
>
Not to debit things to me that I have not never said.
I say to always use m., and I always use it.
>No then, either use them religiously or don´t use them at all, unless forced to (to avoid referincing problem).
>
>BTW, for the lurkers, who like to think to avoid the referencing of a field using m.:
>Do you realize if you really want to avoid this 100%, you´ll have to code.
>
>m.MyObject.Myproperty ISO MyObject.MyProperty
>
>m.THIS.MyProperty ISO THIS.MyProperty
>
>m.THISFORM.MyProperty ISO THISFORM.MyProperty ?????
>
Bravo, you have correctly deducted! I did not doubt that you can.
>Please look at you source code and tell honestly you did this consistently...
If you look into my source code, you see only, say 1000% this coding form!
m.blabla.blublu
m.thisformset
....
Nothing of strange for me. Therefore it must be made.
>
>I´ve seen Fabio do this and beeing burned for this. But you might give him more credit for doing this way.
:( Not understood
>
>Walter,
Fabio
