Hi Przemek,
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.
We could instead have our own Harbour specific replacement
for .mem files (called .hbm f.e.), with a new set of
functions and while leaving existing .mem commands/functions
and file format intact for compatibility.
[ maybe it'd be enough to add a layer above serialization
functions to go through a list of var names and serialize
them. ]
I agree this is not the path to fix RL anyway.
[ 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.
I know, what I didn't know that it's such frequent.
It'd be nice to address it, but the price seems to high
to pay, it's most of the time just some mistyped
function names after the 10th char. At least in my
experience.
Also, while the MEMVAR problem will most of the time
give an RTE, the long function name problem will
usually result in link time error, which makes it
much easier to catch it. (of course functions names
compiled in macros could still be a 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.
And that is exactly the problem. I'm not very positive
that we can clean Harbour to use only 10 chars symbols.
It's a pretty heavy restriction and it was violated
all over Harbour. It's also almost impossible to enforce it.
Such limitation could also contradict with other Clipper
dialects, f.e. xhb and Xbase++. So there were quite some
strong reasons to remove it.
There are quite many symbols which would need to be renamed
to make Harbour compile in 10 chars mode (HB_CODEPAGE_*,
HB_INET*, HB_LANG_*, HB_THREAD_*, HB_Z*, THREAD*, method
names, __DBG*). Many contribs: hbfimage, hbole, hbwin,
rddads, xhb, hbwhat, hbhpdf, hbcurl, gtwvg.
So the list is pretty long.
Considering all these, maybe it would be a somewhat good
compromise to just cut the memvar names (plus maybe
something else, like symbols in macros?), but not the
function names. If such distinction can be made in the HVM.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
