|
|
Posted by Csaba Gabor on 11/18/66 11:45
Jerry Stuckle wrote:
> Kimmo Laine wrote:
> > "Emil" <emjot_wytnij_to_@podczta.onet.pl> wrote in message
> >>Is there any hope that new versions of PHP
> >>will support macros similar to C or C++?
> >>I've searched manual and didn't find anything
> >>except define directive, but it can be used
> >>to define constant values only.
> >>Of course it is not THAT neccessary functionality,
> >>but it could be very useful.
> >
> > What's the actual difference between a function and a macro? How would use
> > of macros differ from functions?
>
> Personally, one construct I use heavily and would like to replace with a macro:
>
> $var = isset($_POST['postvar']) ? $_POST['postvar'] . 'default value';
It's unfortunate that the javascript approach does not work (since in
php a boolean is returned):
$var = $_POST['postvar'] . 'default value';
Macros are not necessarily more efficient. Depends on the context.
For example, if I had a large (global) object or array (or string) that
I wanted to keep referring to, but I didn't feel like passing it around
nor declaring it globally, a macro might be well suited to contain the
definition. But it would not be as efficient as toting around a
pointer to it. But regardless of these examples one way or another, it
is very rare for these types of efficiency differences to matter,
unless you are well buried in nested loops. As Dana Cartwright pointed
out, it is usually more a matter of mindset and convenience.
There is an approach (that I use in another context) that I think one
could use that would support macros, but it's not clean, and it would
take very careful programming... If you have an auto_prepend_file, you
can determine, within the auto_prepend_file, that it is an
auto_prepend_file and also the main file name (via
get_included_files()). In this case, you could use file_get_contents
on the upcoming, but to then unread/unparsed, file to slurp it in and
effect any macro substitutions, and then replace the original file.
This scheme can work, but it has a few major issues that must be
accounted for.
1. The scheme as outlined, leaves a changed file. Thus, the first
thing the revised file must do is to replace itself with the original
file (and don't forget to use the same time/date info).
2. How do you deal with a file that has parse errors? In that case,
the code injected at the beginning of the file would never be run.
Better account for this. And by the way, remember that the injected
code should all be on one line, so that the line numbers of any errors
are reported correctly.
3. Do you really want to write a parser? I'd rather not. But now one
must be aware that macro definitions within strings will also be
expanded.
Csaba Gabor from Vienna
Navigation:
[Reply to this message]
|