Przemyslaw,
I see your point and thanks for the patch, but I'd rather change my code to
add a private and keep the syntatic sugar of :cgiOut(...) changing it to
__oCGI:cgiOut( ... ) while parsing the page because I don't like having a
personal harbour core.
Thanks a lot.
Maurilio.
Przemysław Czerpak wrote:
> 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)
> [email protected]
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
__________
| | | |__| Maurilio Longo
|_|_|_|____| farmaconsult s.r.l.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
