* harbour/src/vm/classes.c
% small optimization in __CLSGetProperties() function
* harbour/src/rtl/tpersist.prg
! force linkin ARRAY() function when HBPersistent class is used
! use hb_ValToExp() instead of local ValToText() function which
didn't work correctly for memos and some other types
! fixed infinite loop in HBPersistent:LoadFromText() used with
empty text. The problem was also exploited by :LoadFromFile()
method if file does not exists or it's empty()
! fixed deserialization of strings containing "=" char inside
! fixed deserialization of strings containing "::"
! added support for decoding nested objects - the code was not
finished and this part was not implemented at all
+ added support for serialized text using ":=" assign operator
instead of "="
* use ":=" instead of "=" as assign operator in new serialized
text
+ ignore lines starting with "//" and added support for files
which do not start with OBJECT directive
* ignore pointer and codeblock items stored in instance variables
during serialization
; now HBPersistent class in Harbour should read serialized files
created in xHarbour with few exceptions:
- Harbour does not allow to serialize codeblocks
See "CODEBLOCK SERIALIZATION / DESERIALIZATION" in
doc/xhb-diff.txt for the reasons.
If Harbour application restores xHarbour HBPersistent files
with serialized codeblocks then RTE
Undefined function: HB_RESTOREBLOCK
is generated.
- xHarbour serialize pointer items as numeric items
saved in hexadecimal notation. Then restore them as numbers.
- HBPersistent does not support hash arrays - they are
serialized by default serialization code used by both
compilers to generate expressions.
In Harbour it's done by hb_valToExp() function and
in xHarbour it's ValToPrg() is used.
ValToPrg() does not create valid macrocompiler expressions
for arrays and objects so HBPersistent files created
by xHarbour are broken and cannot be correctly deserialized.
It happens if objects has hash arrays in instance variables
and these hash arrays contain normal arrays or object
If Harbour application restores such xHarbour HBPersistent
file then RTE "Syntax error: &" is generated.
; xHarbour encapsulates deserialization code inside TRY/CATCH/END
statement saving errors to trace.log file. Harbour generates RTE.
If programmer needs similar behavior then he should
call :LoadFromText() and :LoadFromFile() methods inside
BEGIN SEQUENCE [ / RECOVER ... ] / END SEQUENCE
statement.
; xHarbour reinitialize all or properties instance variables to
default state inside :LoadFromText() and :LoadFromFile() methods.
The 3-rd parameter in above method <lPropertiesOnly> allows to
chose which install variables should be reinitialized:
all (default) or properties only.
Harbour does not have such functionality.
If programmer needs it then he should reinitialize them himself.
It can be easy done be simple function.
Alternatively we can implement this functionality but in such
case I'd suggest to define three actions for such switch:
none (default), all, properties only.
; Harbour does not support 2-nd parameter <lIgnoreBadIVars> which
exist in xHarbour versions of HBPersistent:LoadFromText() and
HBPersistent:LoadFromFile():
If necessary we can implement it though it's usable only if we
want to ignore some wrong lines and process others.
; Warning: Neither Harbour nor xHarbour supports arrays and objects
with cyclic references in HBPersistent code - infinite
loop appears in such case.
; I've never used HBPersistent and the state of the previous
HBPersistent code in Harbour suggests that no one used it for
some serious jobs so I'm open for any opinions and suggestions
about it from xHarbour users.
* harbour/src/compiler/harbour.y
* generate line numbers before extended codeblocks - it gives
more debugger friendly code.
* harbour/src/compiler/harbour.yyh
* harbour/src/compiler/harbour.yyc
* regenerated (with bison 2.4.1)
a44e171cc2