A more better approach to OOPS implementation in PHP.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
OK sounds fine.
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 17, 2006 5:28 PM
> To: Andi Gutmans
> Cc: 'Zeev Suraski'; 'Marcus Boerger'; 'PHP internals'
> Subject: Re: [PHP-DEV] Unicode and fetch class
>
> We did talk about this before, on
Aren't we both normalizing and lowercasing?
Zeev
At 02:45 18/07/2006, Andrei Zmievski wrote:
We are actually normalizing, but only identifiers.
-Andrei
On Jul 17, 2006, at 4:08 PM, Andi Gutmans wrote:
Looks OK to me. Can we call it ZEND_FETCH_CLASS_NO_LOWERCASE
instead of
ZEND_FETCH_CLASS_N
We did talk about this before, on the php-unicode list if you
remember. The UTR#31 has a section about normalization:
http://www.unicode.org/reports/tr31/
I think we should see what kind of performance penalties identifier
normalization brings with it, if any. Once we have the numbers, it's
Is there a good reason for normalizing? I thought we are fine with expecting
developers to use standard form and not suffer performance penalties. I'm
not a Unicode expert so my question might be somewhat ignorant..
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
>
Yes, we are. But normalization (in our case) may involve case-folding
(for class/function names), so it's really a single operation. If you
are asking whether we should have 2 flags for it, I don't believe so.
-Andrei
On Jul 17, 2006, at 4:48 PM, Zeev Suraski wrote:
Aren't we both normali
We are actually normalizing, but only identifiers.
-Andrei
On Jul 17, 2006, at 4:08 PM, Andi Gutmans wrote:
Looks OK to me. Can we call it ZEND_FETCH_CLASS_NO_LOWERCASE
instead of
ZEND_FETCH_CLASS_NO_NORMALIZE. No biggy but I always think of
normalizing as
in taking a Unicode string and no
Hello Andi,
well when i first came up with the patch there was only lowercasing
involved. So you have to ask our unicode guru for the current state :-)
best regards
marcus
Tuesday, July 18, 2006, 1:08:52 AM, you wrote:
> Looks OK to me. Can we call it ZEND_FETCH_CLASS_NO_LOWERCASE instead of
Looks OK to me. Can we call it ZEND_FETCH_CLASS_NO_LOWERCASE instead of
ZEND_FETCH_CLASS_NO_NORMALIZE. No biggy but I always think of normalizing as
in taking a Unicode string and normalizing it. Or is that what you're
actually doing here? Asking because we agreed we won't normalize
automagically i
Had some feedback about a problem with the attached file, so here's also
link to the diff.
http://www.ctindustries.net/patches/xmlunicode.diff.txt
Rob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Looks good to me, although I'd prefer you returned an associated
array rather then an object.
On 17-Jul-06, at 6:03 AM, Michael Wallner wrote:
Lukas Smith wrote:
thats why i said that i would like to atleast be able to get the last
error without having to mess/check track_errors ini settin
Hello Sara,
Monday, July 17, 2006, 7:09:30 AM, you wrote:
>>> One minor thought I'd offer up is an option INI setting to disable
>>> creation of the opcode. This allows the #line directives to be used in
>>> dev/debug environments without causing an impact for production servers
>>> during ex
Agreed - it looks good, but should return an array instead of an object.
Zeev
At 00:33 18/07/2006, Ilia Alshanetsky wrote:
Looks good to me, although I'd prefer you returned an associated
array rather then an object.
On 17-Jul-06, at 6:03 AM, Michael Wallner wrote:
Lukas Smith wrote:
tha
Attached is a patch for my initial cut for unicode and XML (made against
the /ext directory).
I started with XMLReader since it was the smallest.
The code can probably be optimized a bit, but I want to make sure this
is how it should be because the changes made here will be the changes
needed f
Hello Andrei,
looks pretty fine to me, after your treatment, go ahead commit - Andi, Zeev?
best regards
marcus
Monday, July 17, 2006, 9:50:44 PM, you wrote:
> Index: Zend/zend_API.c
> ===
> RCS file: /repository/ZendEngine2/zend_
Hello Michael,
looks quite good now :-) If it were up to me i'd say commit.
best regards
marcus
Monday, July 17, 2006, 12:03:43 PM, you wrote:
> Lukas Smith wrote:
>> thats why i said that i would like to atleast be able to get the last
>> error without having to mess/check track_errors ini
While the php.ini system is under consideration... and with an eye to
the far future... what about an import directive to include another ini
file?
Not that it is exactly the same, but you have this in configure:
--with-config-file-scan-dir=PATH
Set the path where to scan for configuration
> On Mon, 2006-07-17 at 13:52 +0200, Ron Korving wrote:
> > What kind of extensions would you suggest people use?
> >
> > index.php51 ?
On Mon, 2006-07-17 at 15:58, Matthew C. Kavanagh wrote:
> Assuming it's possible, I would set which PHP version to associate with
> .php on a .htaccess or vhost
That would be the wet dream of any web hoster (including myself).
- Ron
""Matthew C. Kavanagh"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Assuming it's possible, I would set which PHP version to associate with
> .php on a .htaccess or vhost basis.
>
> On Mon, 2006-07-17 at 13
Assuming it's possible, I would set which PHP version to associate with
.php on a .htaccess or vhost basis.
On Mon, 2006-07-17 at 13:52 +0200, Ron Korving wrote:
> What kind of extensions would you suggest people use?
>
> index.php51 ?
>
> - Ron
--
PHP Internals - PHP Runtime Development Maili
Of course it would help if I attached the patch..
-Andrei
Index: Zend/zend_API.c
===
RCS file: /repository/ZendEngine2/zend_API.c,v
retrieving revision 1.378
diff -p -u -r1.378 zend_API.c
--- Zend/zend_API.c 13 Jul 2006 21:27:48
I fixed some bugs and reworked the patch. Please look it over, as I
intend to commit it in the next couple of days.
The next step would be fixing zend_u_str_case_fold() to do only case
folding and having all normalization go through
zend_normalize_identifier().
-Andrei
On Jul 15, 2006, at 1
One minor thought I'd offer up is an option INI setting to disable
creation of the opcode. This allows the #line directives to be used in
dev/debug environments without causing an impact for production servers
during execution. It's not a major performance hit, but it's something.
Why not le
I suppose this would have to be the case.
I did think about major, major_minor, major_minor_release and
major_minor_release_extra (for _dev).
But then that is a HUGE number of options. But, you DON'T have to use
them. The fallback is EXACTLY as it is at the moment.
If that is OK, then I'll add
On Mon, 17 Jul 2006 00:06:35 -0700
[EMAIL PROTECTED] ("Ildar N. Shaimordanov") wrote:
> I proposed my first PEAR package HTTP_Sync (as shown at
> http://pear.php.net/pepr/pepr-proposal-show.php?id=402). Now I would
> want to release it at PEAR. My PEAR-user account is
> http://pear.php.net/user/ru
I am working on Yahoo and now I want to be a regular contributor to the
development of PHP itself.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
What kind of extensions would you suggest people use?
index.php51 ?
- Ron
"Edin Kadribasic" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> Hi Richard,
>
> I think your ini changes should be put into PHP. I have a small feature
> request. Since we're modifying the way ini files
Hi Richard,
I think your ini changes should be put into PHP. I have a small feature
request. Since we're modifying the way ini files are picked up we might
as well add support for minor version numbers since PHP is not binary
compatible between minor version releases. That would allow people to
ru
Having used regmon, in conjunction with the source (still learning my
way around the source), PHP accesses the following registry keys :
HKLM\SOFTWARE\PHP\IniFilePath
HKLM\SOFTWARE\PHP\Per Directory Values
What naming convention would you expect to be used for version
specific settings. I would
Lukas Smith wrote:
thats why i said that i would like to atleast be able to get the last
error without having to mess/check track_errors ini setting. i think
this is an acceptable compromise to always store the last error, no?
this covers 100% of all use cases i ever had where i would mess with
On 17.07.2006 11:02, Christopher Jones wrote:
> In the past months we moved many extensions to PECL. However we keep
> their bugs management in bugs.php.net. I would like to move it to PECL
> and removed their entry in bugs.php.net. Even if an extension still
> exists in PHP 4.4.x, this branc
> In the past months we moved many extensions to PECL. However we keep
> their bugs management in bugs.php.net. I would like to move it to PECL
> and removed their entry in bugs.php.net. Even if an extension still
> exists in PHP 4.4.x, this branche is not going to get bug fixes except
> if they a
32 matches
Mail list logo
