On Wed, 03 Feb 2010, Maurilio Longo wrote:
Hi,
> I'd like to see a sample of code which uses with var as well.
> Right now, with object enables me to write dynamic html pages via an
> interpreter which uses &() to evaluate source code and to hide to this
> interpreted code whether it is being run as a CGI or as a fast CGI (sort of,
> it is xitami lrwp protocol).
>
> I try to explain more in detail so that you can grasp what I'm looking for and
> tell me if it is feasible or not with harbour (and following harbour rules).
>
> My web server has an association between .prg files and a cgi program called
> hscript (like the old contrib one from which I borrowed several ideas).
>
> When a request comes in for a page with .prg extension the web server calls
> hscript which 'executes' the source code like a cgi program and, before
> returning, starts another instance of itself which attaches to the webserver
> via the lrwp protocol so that all following requests for the same page are an
> order of magnitude faster.
>
> Inside hscript I have code like this:
[...]
> // interpreted
> with object oCGI
> Interprete( .... )
> end
> // fast cgi
> with object oLRWP
> Interprete( ... )
> end
[...]
> where <% and %> delimit clipper code which calls the oCGI/oLRWP methods to do
> its work, output things, or access oCGI/oLRWP iVARs like :Sever_Name or
> :Query_String.
> So, if with var works with &() it is perfect for me, I don't mind having to
> change a few with object statements.
> with var oCGI
> Interprete( ... )
> end
> I'm really not able to give you more valid reasons to have such a capability,
> because I'm using it just for this kind of code (my employer web site, for
> example, is completely written this way).
In the above text you haven't presented anything what causes that you
have to use WITH OBJECT at all. In such context you can reach the same
effect using some private variables, i.e. _WITH and make all such code
Clipper compatible so for me it's not the reason to change core code.
If I add such extension and document using :<msg> in macro compiler
then it will be very hard to revert it in the future and it will close
door to optimize code generated for WITH OBJECT because it will be
necessary to keep current implementation which needs additional HVM
stack register <lWithObject> which can be eliminated and by compile
time calculations. In my opinion it's bad idea and I think that most
of users prefer better performance then some seldom use extensions
which are not structural and volatile language semantic (it's possible
to use such macros outside WITH OBJECT / END statement what should be
forbidden). Also HB_QWITH() function comes from XHB library and it's
not Harbour core functions because in the future it's possible that
we will have to eliminate it.
Now WITH OBJECT is in practice compiler only extension. It was added
replicating xHarbour behavior for compatibility but it introduced
series of anomalies like hacked preprocessor (I sent examples in
previous message) or code with more then one meaning, i.e.:
case : msg()
used inside DO CASE and WITH OBJECT statement can be compiled as:
case ( :msg() ) // DO CASE condition
or:
(case):msg() // 'msg' is sent to object in 'case' variable
Such things should not happen in well designed language so I would
like to eliminate it in the future even with the cost of compatibility
with xHarbour.
As long as current WITH OBJECT is compiler only extension then when
we replace it by some new one users can easy fix their code because
old syntax is reported as error at compile time so it will be simple
process. If we add official support for :<msg>[(<params,...>)] to
macrocompiler then compiler won't report any errors at compile time
making switching to new syntax much harder.
Now probably only few users like you used it in macrocompiler creating
code for xHarbour so such extension will only increase the problem in
the future.
I can understand that you have some xHarbour code and it's serious
problem for you. In last commit I cleaned some grammar code used
to compile messages so you can enable it very easy in your own
personal Harbour builds. It's enough to add this line to macro.y[485]:
| ':' SendId { $$ = $2; }
and regenerate macro.yyc
below is a patch.
HTH and you understand why I do not want to change it in SVN code.
best regards,
Przemek
--- harbour/src/macro/macro.y (wersja 13789)
+++ harbour/src/macro/macro.y (kopia robocza)
@@ -482,6 +482,7 @@
/* Object's instance variable
*/
ObjectData : LeftExpression ':' SendId { $$ = hb_compExprNewMethodObject(
$3, $1 ); }
+ | ':' SendId { $$ = $2; }
;
SendId : IDENTIFIER { $$ = hb_compExprNewSend( $1, HB_COMP_PARAM ); }
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
