On Tue, 11 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
>> I do not know the RL tool and it's internal format used >> in .frm but for .mem files we can introduce new format >> which will allow to store memvars with unlimited variable >> name size. > Of course, but how would you solve two way compatibility > for these .mem files? I do not plan to implement it. Few years ago I looked at this problem and it should be possible to create format which will be accepted by Clipper but it will skip Harbour extensions. But to be sure I will have to make some tests with Clipper. Clipper .mem format does not support also other things which exists in Harbour, f.e. strings longer then 64KB so variable name length it's not the only one problem. > [ IMO still some cmdline/pragma PRIVATE/PUBLIC var length > limit seems the most reasonable. ] It has to be runtime switch. Compiler switch is not enough. Why don't you want to make the same for other symbols? The most often reported problem by Clipper programmers porting their code to [x]Harbour is more then 10 significant characters in function names. It's exactly the same problem. We had Harbour compile time support for 10 character symbols which you removed. The reason was using in core code functions which needs more then 10 significant characters. The same problem will happen if someone will want to link code which uses such memvar variables with a code which needs longer variables. I can understand that we may want reactivate support for 10 character symbols updating core code if necessary because it's a real problem for some Clipper users but introducing such hack only for one type of symbols is a not good idea for me. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour