Dmitry Stogov dmi...@zend.com wrote in message
news:4dd63c03.3090...@zend.com...
The main idea of the patch is inlining and I don't know how can I inline
from external file.
via #include and macros, as many others do.
see longlong.h in GNU libgcrypt-1.4.6/libgcrypt-1.4.6/mpi/
just my 2c
All,
I have cross-compiled php-cgi for a MIPS device (mediaplayer), but the
binary is quite large, more than 3MB. I'm using:
./configure --prefix=../result/php-5.3.5 --host=i686-pc-linux-gnu
--target=mipsel-linux-gnu --build=mipsel-linux-gnu --enable-cgi
--disable-all --without-pear
No. Php if we talk about php with all its extensions is not threadsafe
at
all. Many of the extensions allocate static data and inherently
non-thread-safe.
PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
some extensions might not be thread safe, but basically all
Scott MacVicar wrote in message:
Do you think any locking function is implemented in openssl php
extension?
In PHP a SSL_CTX is per thread and is not shared across other threads so
it isn't an issue. We don't need to implement any openssl locking
functions.
It does not matter
Israel Ekpo israele...@gmail.com wrote in message
news:aanlkti=ixwqkkovkyuluqckdvklqy2nyeyg6pjfza...@mail.gmail.com...
In multi-process environments, such as FastCGI, Apache Prefork MPM etc,
PHP
needs to execute the MINIT and MSHUTDOWN functions for all loaded
extensions
on every request.
Until version 5.3.2 this worked fine, starting from version 5.3.3
parent::getFoo() calls __callStatic() instead of __call().
This is a really bad BC change which i thought you decided to accept only
in minor versions change and not patch-level versions change.
Anyway, I would even be
Yes, there is a reason:
As it was explained before, lemon would not display token names but
actual token values. So instead of Unexpected T_PAABLAH it would say
Unexpected '::' ...
hello,
value of some tokens is not what would be expected either. Think a bit about
T_STRING for example.
Hi.
This was discussed before.
see
http://www.mail-archive.com/internals@lists.php.net/msg37211.html
Tyrael
Rasmus meant (include|requrie)_once, where the same files should be caught
indeed.
As of file_exists(), why would it need realpath's logic at all?
-jv
--
PHP Internals - PHP
Rasmus meant (include|requrie)_once, where the same files should be
caught
indeed.
As of file_exists(), why would it need realpath's logic at all?
In case open_basedir is enabled we have to do some more verifications,
as we have to resolve the true base.
johannes
Good point, thanks.
I
Parsing ends with ? regardless if its a comment or not but its not
context sensitive. It can't understand that its within a string.
- S
Not exactly, it's only // comment style does not comment the tag while /* */
does.
The following script outputs its 'afafa':
?php
if(true){
/* echo
Scott MacVicar wrote:
Yeah because /* */ has a clear end where // and # doesn't.
- S
Shouldn't the end of the line be always considered as a true end of the
one-line comment?
In other words, I think it always has a clear end too.
Similarly, lexer always regognizes the strings - their start and
Ilia Alshanetsky i...@prohost.org wrote in message
news:aanlktilzlbbfucuv-jtmkm-qljl1il7wsqy0fyhn3...@mail.gmail.com...
Including into core of PHP has no impact on other opcode caches, if
they do a better job then APC, people can definitely (and should) use
them. The main purpose of
Rasmus Lerdorf ras...@lerdorf.com wrote in message
news:4c1ed90d.2030...@lerdorf.com...
On 6/20/10 7:44 PM, Stas Malyshev wrote:
Hi!
Can you elaborate? What average user-facing features are non-obvious?
We should document them if nothing else.
This recently caught my attention:
This is an unfixed PHP bug. There have been a number of threads about
the object destruction order on internals. It isn't just APC that is
affected by this. Other extensions are affected as well.
I understand that this effect is caused by the fact that APC destroys PHP
classes earlier
By the way, including APC in the core is actually likely to fix this
problem because it has to do with the order the rshutdown functions are
called. Read Christian's excellent description of the problem here:
http://news.php.net/php.internals/46999
-Rasmus
concerting
keep on the topic pls, which is the inclusion of potentially buggy and
poorly maintained APC.
I'm on topic. You seem to be able to fix this bug very easily, I only
told you how to provide patches.
I do not care of bugs in APC unless this module is NOT in php core.
If they appear in php core,
This bug is not APC specific.
In this case you can easily point out to another module suffering from this
bug, don't you?
License argument does not work at all.
It does, more than ever.
Then is there any reason not to add all code compatible in php license terms
into php core?
If not,
Then is there any reason not to add all code compatible in php license
terms
into php core?
What are you talking about? Who said that we have to add any php
licensed code to the core? I only said that the license is a critical
part of the decision. Nothing else.
APC can be added, this
Competition between opcode caches for php will definitely be reduced by
adding APC into the core,
so the market will shrink, of course.
i think this is a likely outcome indeed. it might also be phrased in a
more
positive tone in that likely efforts will be joined. for example maybe
zend
Ilia Alshanetsky i...@prohost.org wrote in message
news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org...
Several reasons:
1) APC is well maintained, by the same people who work on PHP.
2) The license does not preclude it's inclusion into the base version.
3) most people don't use any
For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
another php.ini flag (sorry!) to choose the behaviour.
-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a
major release, after all.
It would be absolutely enough to add optional var-name
On Wed, Jan 20, 2010 at 02:29:27PM -0800, Rasmus Lerdorf wrote:
Well, that conversion still needs to happen somewhere, since plenty of
apps call extract() on those superglobals, but with register_globals
entirely gone in PHP 6, I suppose that conversion can be moved to the
extract() call.
jvlad wrote:
$a = array(1);
$b = 0;
$c = $b;
foreach($a as $c);
Now you are arguing that $b should not be 1?
The two pieces of code are identical
It's just a nightmare example. I wonder have you ever see anything like
this
in real life?
Could you please let me see it too, for example
Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for _fun_ by core developers and brought
headache
to people developing in php.
We are letting you know that you need to start thinking about migrating
your code away from non-Unicode aware functions like
We are letting you know that you need to start thinking about
migrating your code away from non-Unicode aware functions like
ereg() and split().
Well, this filled up my php logs with some million records telling me
this! Do you think it's safer to keep thinking and have an opportunity
to
as far as I see, the changes depends on how many work has to be done,
to preserve something.
I see the same.
posix functions like split, and so could have been modified to work
with the unicode strings, but nobody cared enough.
Because this work is not in the TODO (milestones).
-jv
--
Rasmus Lerdorf ras...@lerdorf.com wrote in message
news:4b3785ac.2000...@lerdorf.com...
We can't just randomly reset variables based on their scope in this one
specific case. If we are going to fix this, it should be done by
introducing a way to do proper local scope variables. Resetting a
No chance. No .ini settings, and I still maintain it is inconsistent.
So, if I write this:
$a = array(1);
$b = 0;
$c = $b;
$c = $a[0];
Would you agree that $b should be 1 at this point? If so, just because
I rewrite that code like this:
$a = array(1);
$b = 0;
$c = $b;
foreach($a
Hi Pierre,
slow (as you noticed). However it can't be done in 5.3 as it will
break the ABI.
I noticed that a recent fix (http://bugs.php.net/bug.php?id=49936)
added TSRMLS_DC to an API in 5.3.
not to add what
phpinfo() shows in Architecture, to the id string? Are there any reasons not
to do this?
-jvlad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on this info on other platforms but that's definitively something we
should try to do.
Cheers,
On Sun, Nov 29, 2009 at 11:29 AM, jvlad d...@yandex.ru wrote:
Hi all,
Starting with version 5.3 php checks id string when it loads the
extensions
to match its own one and it also shows this string
in the same
binary, and, a binary built 2 ways [i386 and PPC or i386 and x86_64 or
even 4 ways for that matter] can work on any of these archs. How do you
suggest to handle that?
May the source be with you,
Best regards,
Jess Portnoy
jvlad wrote:
Hi all,
Starting with version 5.3 php
:
Windows Seven,6.1.0.7600,MyHostName,x86_64
and btw, it should be clear that Architecture is compile-time thing,
not run-time, so there is one more reason to move it to id-string.
-jvlad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with.
In fact, the IDs will be different in this case - vc6 and vc9 for visual
studio 6 and
2008 respectively. So, still no problems. ID clearly indicates whether an
extension
can be used with particular php core distribution. It's only necessary to
add CPU :)
-jvlad
--
PHP Internals - PHP
The problem with the segfault in memcpy from bug 50207 was that the
pointer result-value.str.val is a 64 bit unsigned integer, and of
course result-value.str.len is a signed 32 bit integer. The value of
you're right, len is declared as int and it's indeed 32bit under 64bit
Linux.
It must be
Code:
?php
$s = str_repeat('A', pow(2,30));
$t = $s.str_repeat('B', pow(2,30));; // fails with segfault
printf(strlen: %u last-char: %s, strlen($s), substr($s, pow(2,30)-1));
?
---
Result:
./sapi/cli/php -d memory_limit=-1 a2.php
Fatal error: Out of memory (allocated 2148270080) (tried
Hi folks,
after discussing the idea with various PHP developers
I now felt safe enough that it's not a completely stupid
idea to post an RFC for it. The idea is to add support
the registration of custom factories which are
responsible for instantiating certain classes.
Here is the first
If you care not to waste userland with new names, use namespaces,
that's the way intruduced by php, and it is not javascript after all.
I'm so old school in my coding, I've not got my head around namespaces
yet. I'm just old.
There is nothing really new in namespaces.
For example the
I have filed a bug (suggestion) at http://bugs.php.net/bug.php?id=50003
What do you think about enabling such a constructions in future
versions of
php?
On Nov 9, 2009, at 1:41 AM, David Zülke wrote:
It's already on the list for PHP6:
http://wiki.php.net/summits/pdmnotesmay09 (see Day 2,
melfar mel...@gmail.com wrote in message
news:0f.f6.03668.ad206...@pb1.pair.com...
Hey,
Yep, I think there might be some caveats to that change.
The original patch did not work on methods, so I've fixed that and also
made the return value an rvalue, so that you can't attempt to modify the
Whilst you are all thinking about this, how about ...
$value = (function(){return $x;})();
Being able to call an anonymous function inline would certainly be a
useful mechanism. Allowing calls without creating dummy user land vars
would be consistent with func()[0].
If you care not to
Hi,
This is not allowed since declaration values should be resolvable at
compile time. I.e. they can not be an expression, but only a value
literal.
While technically expression folding is possible, it's not implemented in
any part of the PHP engine (AFAIK), and I don't think it's
I'm wondered why the shebang line support was removed from scanner.
Because it didn't make any sense for other SAPIs. You could ask Ilia more
about it:
-
r273178 | iliaa | 2009-01-09 19:21:12 +0200 (Fri, 09 Jan 2009) |
Hi,
Can this snippet of shebang checking be removed for php 5.3.+, 6?
Its for external FPM project.
cgi_main.c:
php_fopen_primary_script(file_handle TSRMLS_CC);
if (CGIG(check_shebang_line) file_handle.handle.fp
(file_handle.handle.fp != stdin)) {
/* #!php support */
c =
If this is indeed a use-case for CGI then I think it's a valid argument
and we are probably better off supporting it. I did not remember shebang
works for real CGI.
There are still plenty of use-cases for running CGI (as opposed to
FastCGI) in the industry.
Question now is whether this
From: Richard Quadling rquadl...@googlemail.com
Newsgroups: php.internals
Sent: Monday, September 07, 2009 3:44 PM
Subject: Re: [PHP-DEV] shebang skipping in 5.3.0
2009/9/7 jvlad d...@yandex.ru:
And for windows, the shebang line is not used. So becomes part of the
output - no matter what SAPI
Jani Taskinen jani.taski...@iki.fi wrote in message
news:4a9bb132.6080...@iki.fi...
On 08/31/2009 12:06 AM, Pierre Joye wrote:
Hi,
While trying to fix some tests, I found that display_startup_errors is
ignored by some startup errors like deprecated ini settings. Using:
php -d
1. you're wrong, PHP does not depend on system-wide installed pear, it
will simply use it if present
2. nothing is missing. see http://pear.php.net/PHP_Archive
If installed, phar.phar will function (partially) without the phar
extension being present.
In other words, not a
In other words, I see two bugs there:
1. PHP depends on the system-wide installed pear and tries to run it.
2. One or many files are missed in the package producing the Archive.php
class file not found error.
1. you're wrong, PHP does not depend on system-wide installed pear, it
will simply
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4
As of php5.3-200906221030, the problem under *BSD platforms that I'm
talking
about is still the same.
I see no compile failure bug reports against FreeBSD in the bugtracker...
I successfully built a snapshot on 4.11-STABLE FreeBSD (gcc 2.95.4)
3hours ago, you'll have to be slightly more
Generating phar.php
*** Error code 138
make: Fatal error: Command failed for target `ext/phar/phar.php'
next run of make install produces:
$ make install
Generating phar.phar
make: *** [ext/phar/phar.phar] Bus Error (core dumped)
System information, compiler, and trace would be a plus
specified somewhere?
Can it be fixed or improved?
Try compiling with -O0
unfortunately, it did not help (tried with fresh sources):
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps
--mode=compile
gcc -I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic
tried on another hardware with 1GB RAM. It successfully passed
ext/fileinfo/libmagic/apprentice.c.
Now the problem is:
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps
--mode=compile
gcc -Iext/phar/ -I/home/jvlad/php/php5.3-200906221030/ext/phar/ -DPHP_ATOM_INC
Or it could be possibly fixed by including stdint.h, like
win32/php_stdin.h is included on Windows thrus no compilation error
here. Let me know if the following patch fixes your problem:
Index: php_spl.h
===
RCS file:
, except php 5.3 :)
You might try using gdb, start it up, and run with:
-n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir=
-derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0
install-pear-nozlib.phar -d /export/home/jvlad/testpear -b
/export/home/jvlad/testpear/bin
that way you can
can you run the custom gdb dumpbt so we can see which line of
install-pear-nozlib.phar is triggering the error?
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/ext/phar/phar.php:10
--
PHP Internals - PHP Runtime Development
try running sapi/cli/php passing in a simple script with those
contents and verify you still get the bus error?
Core was generated by `./php 1.php'.
Program terminated with signal 10, Bus error.
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER (execute_data=0x861cc0)
at
/export/home/jvlad/php
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4
jvlad d...@yandex.ru wrote in message
news:38.7a.20019.c9d6f...@pb1.pair.com...
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in RC4.
We fixed several compile failures
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4
more specific.
NetBSD 3/x86 crashed:
/bin/sh
/home/jvlad/php/php5.3-200906221030/libtool --silent --preserve-dup-deps
--mode=compile
gcc -I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/libmagic -Iext/fileinfo/
-I/home/jvlad/php/php5.3-200906221030/ext/fileinfo/ -DPHP_ATOM_INC
-I/home/jvlad
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4
Did you hear about crashes under Solaris and MacOSX, and compiler
failures
under all *BSD systems?
They were posted against RC3 and the problems are still the same in
RC4.
We fixed several compile failures recently (both FreeBSD related and
GCC2), it probably didn't make it into RC4
php5.3-200906221030 make produces suspecious output under FreeBSD
6/amd64:
Generating phar.php
Generating phar.phar
pear: not found
Pear package PHP_Archive or Archive.php class file not found.
This is not suspicious. It is
Hi,
It looks like nothing critical has popped up since RC4.
So it looks like we will be sending the final stable release to the
mirrors next Wednesday and announce the release on Thursday barring any
critical issues emerging in the next days. In the mean time test test
test. If issues
If the bug #48583 can't be accepted through bugs.php.net, I think it makes
sense to discuss it here.
In short the question is:
Should display_errors and the other error-routing settings work or not?
I belive they are very important and should always work.
Just my 2cents.
Long story:
If the bug #48583 can't be accepted through bugs.php.net, I think it
makes
sense to discuss it here.
It's not a bug but chicken'n'egg' issue. Errors are displayed by default
(IIRC) so if the ini file does not get parsed an error is outputted which
IS
--Jani
I don't agree, absolutely.
details on your configuration? (compiler, configure
flags, )
johannes
solaris2.8/sparc 32bit (it's 32bit, not 64bit as I mentioned before):
$ make install
Installing PHP SAPI module: cgi
Installing PHP CGI binary: /export/home/jvlad/php/install/bin/
Installing PHP CLI binary
solaris2.8/sparc 32bit (it's 32bit, not 64bit as I mentioned before):
yes, I used 32bit on the niagara box, too.
$ uname -a
SunOS qu1 5.8 Generic_108528-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
I used a similar machine from our lab now and did some tests and
couldn't reproduce.
did you
On Wed, 2009-06-17 at 13:49 +0400, jvlad wrote:
solaris2.8/sparc 32bit (it's 32bit, not 64bit as I mentioned before):
yes, I used 32bit on the niagara box, too.
$ uname -a
SunOS qu1 5.8 Generic_108528-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
I used a similar machine from our lab now
Core was generated by
`/export/home/jvlad/php/php-5.3.0RC3/sapi/cli/php -n -dshort_open_tag=0
-dsaf'.
What's the full command line and the script being executed?
I'm not sure how to check it.
Best would be to reduce the script to the mimimum that's needed.
I don't know what script
Hi All,
Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/amd64,
NetBSD 3.1/x86, and OpenBSD 4.1/x86?
Under these platforms gcc hangs in
php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo produces
further errors in spl and date.
Under Solaris
Under windows php crashes in fastcgi...
Pardon? where?
Pardon, threre:
http://bugs.php.net/bug.php?id=48563
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/
amd64,
NetBSD 3.1/x86, and OpenBSD 4.1/x86?
Under these platforms gcc hangs in
php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo
produces
further errors in spl and date.
Under Solaris
Plan to share any of these errors with us? We don't have all platforms
available for testing.
Scott
/bin/sh
/home/jvlad/php/php-5.3.0RC3/libtool --silent --preserve-dup-deps
--mode=compile
gcc -I/home/jvlad/php/php-5.3.0RC3/ext/fileinfo/libmagic -Iext/fileinfo/
-I/home/jvlad/php/php
How does one do the equivalent of Makefile.frag for the windows build?
AFAIK only config.w32 files are used under Windows and they are used only
when buildconf.js creates configure.js in the root directory of the sources.
--
PHP Internals - PHP Runtime Development Mailing List
To
Recently I faced with one funny problem in PHP. Seems there is no way to
run
a sub-process using exec() (or backticks), and pass there specially
crafted environment without affecting all running threads. As soon as I
update the environment, all other threads see the change. It's
Hi all,
Recently I faced with one funny problem in PHP. Seems there is no way to run
a sub-process using shell_exec() (or backticks), and pass there specially
crafted environment without affecting all running threads. As soon as I
update the environment, all other threads see the change. It's
Rasmus Lerdorf wrote:
shire wrote:
I agree for the general case, in our development environment though this
might cause some pains. But we could always start there and see how it
goes. I agree that Xdebug isn't really a use case we always need to
optimize for.
Is it ever a case we need
Hi!
Attached is the patch implementing build ID. Please comment. If no
objections are raised I'm going to commit it tomorrow.
...
+ fprintf(stderr, Cannot load %s - it was build with configuration %s,
whereas running engine is %s\n,
Why not to call zend_error instead?
It would make more
Not much work - I think I can do it in 1 day.
Please don't forget to add human-readable error message when the IDs
don't
match.
Better to have different errors for different mismatching parts.
It's important because not all administrators are good with understanding
realted problems.
I meant readable :)
Do you mean this?
fprintf(stderr, %s requires Zend Engine API version %d.\n
The Zend Engine API version %d which is installed, is
outdated.\n\n,
new_extension-name,
First of all, php error_log may not get this message because it's thrown
into stderr.
It is
how much work will this be?
Not much work - I think I can do it in 1 day.
Please don't forget to add human-readable error message when the IDs don't
match.
Better to have different errors for different mismatching parts.
It's important because not all administrators are good with
On 11.01.2009 03:21, jvlad wrote:
Almost.
Try to compile your very-own-version of php, using configure argument
--disable-zend-memory-manager
There is no such configure option since ages.
seems you're flying too high.
RHEL5 still ships php5.1.6 and it has this option and it undefines
ZMM does never release memory to the system.
my appologies, never is a too strong word for that. I'd use almost
never.
Indeed ZMM does release segment to the OS if all the memory blocks in it are
freed.
I'd only add that with an average script, it won't happen.
jv
--
PHP Internals - PHP
seems you're flying too high.
RHEL5 still ships php5.1.6 and it has this option and it undefines
ZEND_USE_ZEND_ALLOC.
PHP 5.2.0 has been released more than 2 (two) years ago, which should be
enough for a distro to catch up, don't you think so?
Perhaps. But what they ship with RHEL5 is up to
Since I use a MySQL connection, Syslog and many classes, I wanted to let
the script run a while before restarting. So the scripts had lines like:
$i = 1000;
while( --$i )
{
while( run() ); // run returns false if there are no pending jobs
gc_collect_cycles();
// echo
So as prevoius speaker suggested, and I personaly got to conclusion in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
Will _you_ write such code? No. Will anybody from this list write such
code?
You may want to write
$a = $b?A:B:C
and how would php compiler
For those that do not understand very well the explanation of jvlad...
He's suggesting to change the class struct to be an scope struct, and
have a property that tells if it's a namespace or a class, and reuse
the implementation of class which already works very well.
The nested support
Adding support for functions, constants and even variables is actually
quite do-able with the solution I suggested (different separator between
namespace name and function/constant/variable name) and can be added
easily.
Adding support for functions, constants and even variables is actually
I share your thoughts and yes namespaces are needed and wanted, but what's
implemented at the moment is quite far from what I'd call a namespace. I
need and want to see there all language entities including variables,
constants, classes, interfaces, and functions. Want to see them all
Guilherme Blanco [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
For those that do not understand very well the explanation of jvlad...
He's suggesting to change the class struct to be an scope struct, and
have a property that tells if it's a namespace or a class, and reuse
Steph Fox [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
For those that do not understand very well the explanation of jvlad...
Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out
there. It has a lot to offer, but namespace support is very obviously
Hello all,
May I suggest something in this area?
I hope it will resolve some problems related to namespaces and classes
ambiguity.
Let's first take a look at the classes.
In-general they represent two things: scope and data.
Scope is a thing that can't be changed without compiler efforts and
Hi,
what's about sample below?
?php
class foo
{
public $aabb;
const bbaa = 'abba';
static public $baba;
function bar(){}
function bing(){}
}
class bar
{
const baab = foo::bbaa;
function bar(){}
}
class A
{
trait foo;
}
class B
{
trait foo {unset bing, bar as
Stefan Marr [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi,
jvlad schrieb:
in other words, why to introduce such a new thing as trait instead of
using classes and trait'ing them?
I've introduced it as a separate notion from classes to avoid
misconception and problems
I use graceful restart quite often.
Frankly, I have no idea why it may fail to work :)
Indeed, when you request a graceful restart, apache will start next set of
children processes and all existing processes will stop getting and
processing any new requests so they will exit as soon as they
98 matches
Mail list logo
