On Fri, November 3, 2006 12:11 pm, Marcus Boerger wrote:
> In PHP it might work
> as
> expected but then all programmers that come from langiages like C++
> get
> confused.
I'm sorry, but, really, I'm not interested in crippling PHP to cater
to C++ converts... :-) :-) :-)
I don't think this is a particularly strong point for you to make.
I believe PHP stands on its own as its own merits, and forcing it to
conform to some way C++ behaves, especially an artifact of the
"compile" phase of C++, is just not a Good Idea.
> Also it would disallow a few optimizer things later (going
> the C++
> way of compile time function invocatoin binding).
Just this morning I was thinking that PHP would be better off
following the Lisp #. model rather than the C++ borg-like model.
In Lisp, if you *want* something computed at compile-time, and you
agree to it being a 'constant' after that, you can wrap it in a #.
construct:
#.( [expression] )
as I recall.
For example:
set_cookie("oatmeal", "raisin", time() + #.(60*60*24*365*2), '/');
#.() gives the first-pass compiler the option to compute that value
immediately, substitute in the result, and use it as a CONSTANT from
that point forward.
Obviously we could not use #.() syntax -- That's just an example.
But it could be useful in PHP for all kinds of stuff, particularly in
tight loops.
Of course, something as simple as:
define('ME', $_SYSTEM['PHP_SELF']);
define('MAX_COOKIE_TIME', 60*60*24*365*2);
might be a lot easier and just as useful :-)
Last time I checked, though, you couldn't do that...
> In PHP it would eventually work
> but add
> more confusion that it would help.
Really?
Because I find myself more and more confused by the PHP OOP model's
continued restrictions and syntax and behaviour every few months than
I am by it NOT behaving like PHP.
It's like I'm in some Twilight Zone where PHP is being taken over by
C++/Java borg that doesn't actually like PHP as it is. [shrug]
The PHP OOP model behaves less and less like PHP and more and more
like all the other languages I choose *not* to use.
As much as I prefer PHP 5 OOP referencing over the PHP 4 copy mess,
the rest of it is quickly becoming a lot of baggage I don't really
want to deal with.
I've been too badly burned in the past by private/protected morass in
large-scale projects from somebody else's code I can't change without
all kinds of problems.
Every time you guys lock something else down and force it to work your
way instead of leaving it up to the Developer, I'm counting on it
biting me on the butt a few years from now. That's just the way it
works. :-v
> However the point of adding E_DEPRECATED is still open. Where open
> only
> means which version will first have it. From my perspective that will
> be
> either 5.3.0 or 6.0.0 depending on whetever comes out first. Helping
> here
> would be greatly appreciated.
I honestly belive that 6.0.0 is the Right Answer, as it will change
the way too many things work from 5.2 to 5.3, as things stand now, as
I understand it...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
