Want to port it to support UChar*?
-A
On Aug 3, 2006, at 12:24 AM, Derick Rethans wrote:
On Wed, 2 Aug 2006, Andrei Zmievski wrote:
You'd have to ask Derick. He's the one who added it. :) Note that
zend_string_to_double() is not actually used anywhere.
I stole it from BSD, and yes... this
Rasmus Lerdorf wrote:
> Pierre wrote:
>> Hello,
>>
>> On 8/3/06, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
>>
>>> I'm not all that keen on a new keyword for this. How about using an
>>> interface to indicate strictness? Isn't this really what interfaces are
>>> all about?
>>
>> I don't like new k
If "use interfaces" means that i have to write an interface matching
every public method in my class if i want that strict mode, and
another interface for every inheriting class that adds method, then
that is not a solution. That means code duplication ...
Regards,
Stefan
--
PHP Internals - PHP
Pierre wrote:
Hello,
On 8/3/06, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
I'm not all that keen on a new keyword for this. How about using an
interface to indicate strictness? Isn't this really what interfaces are
all about?
I don't like new keywords either, but I don't see any alternative
Pierre wrote:
> What are you advocating then? Do you have an opinion? ;-)
No, at the moment I do not have an opinion on this.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals
Hello,
On 8/3/06, Sebastian Bergmann <[EMAIL PROTECTED]> wrote:
Pierre wrote:
> I don't like new keywords either, but I don't see any alternative. I
> also think that interfaces are what should be used. But it seems that
> we are wrong, interfaces do not solve this issue, I'm still unsure
> abou
Pierre wrote:
> I don't like new keywords either, but I don't see any alternative. I
> also think that interfaces are what should be used. But it seems that
> we are wrong, interfaces do not solve this issue, I'm still unsure
> about the reasons though.
Not that I am advocating this, but
clas
Hi Richard,
I reworked and committed part of your patch related to registry.
I am not sure that searching best php.ini by filename is really need.
Most SAPIs allow explicit specification of php.ini.
As I understood the main problem was on Windows, but version specific
registry keys fix it.
Than
Hello,
On 8/3/06, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
I'm not all that keen on a new keyword for this. How about using an
interface to indicate strictness? Isn't this really what interfaces are
all about?
I don't like new keywords either, but I don't see any alternative. I
also think
Pierre wrote:
Hello,
On 8/3/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> In this particular case I think it should be possible to mark
certain internal
> methods as strict and keep userspace methods loose.
But I would like to see atleast an e_strict warning of signatures are
violated to g
I think this is all going way too far. If one wants a "loose" class, you'll
just have to suppress errors? That just doesn't sound right. It's like
having a feature, but the system telling you "don't use it! it's bad!".
If anything, I think E_NOTICE would be much better than E_STRICT, which only
Christian Schneider wrote:
> But like you I prefer the E_STRICT version without modifying the
> language though. But I'm sharing Lukas' concern about the definition of
> E_STRICT: Is it to be changed to E_ERROR at some point? Otherwise
> E_NOTICE would be more appropriate IMHO.
Not that I am advo
On 03/08/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Thu, 3 Aug 2006, Richard Quadling wrote:
> The issue this brings is toggling E_STRICT on and off at RUNTIME
> required? (I suspect that would be a LOT of work).
It's only an issue for the first script that is opened... not for
includes.
Lukas Smith wrote:
> Hi,
>
> well it seems that the initial vision of E_STRICT to denote future
> deprecation is no longer valid. Then again it might have been a
> misunderstanding from the beginning as E_DEPRECATED would have been the
> more obvious name in that case.
I did try to point this out
Derick Rethans wrote:
On Thu, 3 Aug 2006, Lukas Smith wrote:
I still think that a flag on a per class basis would be the better
solution, but I guess I can accept this change.
I don't think it is better as it would require somebody (in one of the
teams) to modify their source files.
Err?
Derick Rethans wrote:
Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, so it is not a good solution.
The same was true for PPP.
But like you I prefer the E_STRICT version without modifying the
language though. But I'm sharing Lukas' concern about the definition o
On Thu, 3 Aug 2006, Richard Quadling wrote:
> On 03/08/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Thu, 3 Aug 2006, Richard Quadling wrote:
> >
> > > The issue this brings is toggling E_STRICT on and off at RUNTIME
> > > required? (I suspect that would be a LOT of work).
> >
> > It's only
Hi Marcus, all,
I finally started on these additions and noticed a couple things...
1) Using %.4e, for example, only gives 3 decimal places instead of 4 -- I
assume I can/should fix that?
2) I realized "precision" isn't supported with d/u/o/x etc., just
width+padding. Precision could be used fo
Hello,
On 8/3/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, so it is not a good solution.
I doubt this is a valid concerns. Our code is actually broken and now.
You want more strictness? Require 5.2+ for your appl
On Thu, 3 Aug 2006, Richard Quadling wrote:
> The issue this brings is toggling E_STRICT on and off at RUNTIME
> required? (I suspect that would be a LOT of work).
It's only an issue for the first script that is opened... not for
includes. As the parsing E_STRICT things work fine but only *a
On 03/08/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> Err? Code that already works, still works if we make the loose mode the
> default. Anyone who writes new classes can make use of a new strict flag
> however.
Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, s
On 8/3/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Thu, 3 Aug 2006, Lukas Smith wrote:
> I still think that a flag on a per class basis would be the better
> solution, but I guess I can accept this change.
I don't think it is better as it would require somebody (in one of the
teams) to mod
On Thu, 3 Aug 2006, Lukas Smith wrote:
> Derick Rethans wrote:
>
> > On Thu, 3 Aug 2006, Lukas Smith wrote:
> >
> > > I still think that a flag on a per class basis would be the better
> > > solution, but I guess I can accept this change.
> >
> > I don't think it is better as it would require s
On Thu, 3 Aug 2006, Lukas Smith wrote:
> I still think that a flag on a per class basis would be the better
> solution, but I guess I can accept this change.
I don't think it is better as it would require somebody (in one of the
teams) to modify their source files.
regards,
Derick
--
PHP Int
Hello!
The PHP Development Team would like to announce the immediate release of
PHP 4.4.3. This release combines small number of bug fixes and resolves
a number of security issues. All PHP users are encouraged to upgrade to
this release as soon as possible.
A separate release announcement is a
Hi,
well it seems that the initial vision of E_STRICT to denote future
deprecation is no longer valid. Then again it might have been a
misunderstanding from the beginning as E_DEPRECATED would have been the
more obvious name in that case.
I still think that a flag on a per class basis would
Hello,
On Thu, 03 Aug 2006 10:48:38 +0300
[EMAIL PROTECTED] (Zeev Suraski) wrote:
> Actually no, what Derick said is what I meant.
>
> I think emitting an E_STRICT notice on violation of a signature is a
> very reasonable compromise between the loose and strict worlds. It's
> not scientifica
At 10:40 03/08/2006, Pierre wrote:
Hello,
On 8/3/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> In this particular case I think it should be possible to mark
certain internal
> methods as strict and keep userspace methods loose.
But I would like to see atleast an e_strict warning of signatu
On Thu, 3 Aug 2006, Pierre wrote:
> Hello,
>
> On 8/3/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
>
> > > In this particular case I think it should be possible to mark certain
> > > internal
> > > methods as strict and keep userspace methods loose.
> >
> > But I would like to see atleast an e_
Hello,
On 8/3/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
> In this particular case I think it should be possible to mark certain internal
> methods as strict and keep userspace methods loose.
But I would like to see atleast an e_strict warning of signatures are
violated to give atleast the
On Wed, 2 Aug 2006, Rasmus Lerdorf wrote:
> Zeev Suraski wrote:
> > I believe the problem is that 10 years ago we introduced what can be
> > described as 'loose OO programming', and we're replacing it (instead of
> > augmenting it) with strict OO programming.
>
> Sure, and I agree that we should
On Wed, 2 Aug 2006, Andrei Zmievski wrote:
> You'd have to ask Derick. He's the one who added it. :) Note that
> zend_string_to_double() is not actually used anywhere.
I stole it from BSD, and yes... this is really needed because of all the
different architectures.
Derick
--
PHP Internals - P
At 01:06 03/08/2006, Marcus Boerger wrote:
Hello Richard,
Wednesday, August 2, 2006, 11:55:45 PM, you wrote:
> On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:
>> I believe the problem is that 10 years ago we introduced what can be
>> described as 'loose OO programming', and we're replacing
At 00:55 03/08/2006, Richard Lynch wrote:
On Wed, August 2, 2006 7:32 am, Zeev Suraski wrote:
> I believe the problem is that 10 years ago we introduced what can be
> described as 'loose OO programming', and we're replacing it (instead
> of augmenting it) with strict OO programming.
And there ar
34 matches
Mail list logo
