Hi Przemek,
On 2008.09.22., at 1:14, Przemyslaw Czerpak wrote:
For now, I'd personally vote to make PUBLICs visible for
all threads (otherwise most apps would need to be rewritten
in this respect I guess), and PRIVATEs to the threads that
define them. 'THREAD PUBLIC' could be introduced to create
PUBLICs visible only for the current thread if someone
needs such thing. It would be analogous to THREAD STATIC.
I thought about it and I think that making PUBLIC common for
all threads may force code rewriting.
What I had in mind is code like this (which I use frequently
for app global settings - which are for the most part read-only
and global to the whole app, however programming practice it
may be)
FUNC MAIN()
PUBLIC app[_APP_SETTING_MAX_] := { ... }
customer_handling()
item_handling()
RETURN NIL
FUNCTION customer_handling()
open dbs, open window
... IF app[_APP_SOMEGLOBALSETTING] ; ... ; ENDIF ; ...
close window, open dbs
RETURN NIL
FUNCTION items_handling()
open dbs, open window
... IF app[_APP_GLOBALSETTING] ; ... ; ENDIF ; ...
close window, open dbs
RETURN NIL
If I'd like to move *_handling to separate threads, I'd
be in trouble I guess. If they'd be inherited and global,
the only place I'd have to deal with blocking reentrancy
is the setup functions - where these values are actually
written.
Now I decided to add thread attributes which allows to
control what will happen with existing memvars when new
thread is created so it's possible that child thread will
have copy of all existing PUBLIC and/or PRIVATE variables
or making them common (shared) with parent thread.
It allows to reach nearly the same effect as in xBase++.
Many thanks this looks good. I'd also make the defaults
XBase++ like to make it easier to grasp.
For strict xbase++ compatibility we will need to divide memvars
handles to store PUBLIC and PRIVATE ones separately. If users will
vote for such solution then I'll add it too. In such case we
probably should also add support fot THREAD PUBLIC variables.
One vote to be (or to have to option to be) fully XBase++
compatible.
Now let's return to GLOBALs. GLOBALs are application wide STATIC
variables. If we do not want to add them then we should add support
for automatic PUBLIC declaration and initialization with the same
conditions as STATIC initialization. This will cover the necessary
functionality. We can make it in two ways:
1. use existing syntax and only allow to declare PUBLIC out of
function body just like file wide statics. The bad effects
of such solution is forcing -n compilation. It also make such
code harder to locate when program have to be ported for some
other xbase language.
2. we will introduce new syntax, f.e.
INIT PUBLIC <var1> [ := <exp1> ] [, <varN> [ := <expN> ]
For me the second one seems to be cleaner.
As far as the syntax goes, I seem to like better option 1),
since it's more "natural". But I also like the collision detection
feature you mention for INIT PUBLIC.
It may be nice if we could somehow support GLOBALs with some
#translates or #defines in hbcompat.ch. I'm not sure which option
supports this better.
Also - XBase++ users -, how is this solved in that language?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
