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

Reply via email to