2008/9/29 jvlad <[EMAIL PROTECTED]>
> > > > 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?
>
>
Hi,
I posted this problem to the suhosin forum because I thought that this
patch might be responsible, but I am not so sure now...(just because
someone, said so;)
http://forum.hardened-php.net/viewtopic.php?pid=1650
Would you mind reading it and pointing the finger at someone else?;)
Thanks
Dmitry Stogov wrote:
Hi Rasmus,
Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Hi Brian,
I think you patch does the things you like properly, but why do we need
such ability? I don't see a use-case.
In case of accepting this patch, we also need to care about duplicate
headers.
Some web services
On 30.09.2008, at 05:36, Daniel Convissor wrote:
Hi Greg:
On Sun, Sep 28, 2008 at 09:58:25PM -0500, Gregory Beaver wrote:
The second highest vote was :::, but there was strong objection to
this
as well from some.
Sounds like you have the tally or know where it is (or you have an
excelle
Le lundi 29 septembre 2008 à 13:48 -0500, Larry Garfield a écrit :
> On Mon, 29 Sep 2008 19:30:00 +0300, "Vesselin Kenashkov" <[EMAIL PROTECTED]>
> wrote:
>
> > My proposal is (if possible/reasonable/performance wise of course) to have
> > a
> > fatal error thrown when during the parse time the e
On Mon, Sep 29, 2008 at 8:36 PM, Daniel Convissor
<[EMAIL PROTECTED]> wrote:
> Hi Greg:
>
> On Sun, Sep 28, 2008 at 09:58:25PM -0500, Gregory Beaver wrote:
>>
>> The second highest vote was :::, but there was strong objection to this
>> as well from some.
>
> Sounds like you have the tally or know
Hi Greg:
On Sun, Sep 28, 2008 at 09:58:25PM -0500, Gregory Beaver wrote:
>
> The second highest vote was :::, but there was strong objection to this
> as well from some.
Sounds like you have the tally or know where it is (or you have an
excellent memory). Do you have a URI for it, please?
Reg
On Tue, Sep 23, 2008 at 11:47:30AM +0400, Dmitry Stogov wrote:
> Stanislav Malyshev wrote:
> >
> > 3. Functions will not be allowed inside namespaces. We arrived to
> > conclusion that they are much more trouble than they're worth, and
> > summarily we would be better off without them. Most of the
the bug is updated with my comments, i think it's a cgi not phar
issue. can u pls have a look soon?
thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hi!
On Mon, Sep 29, 2008 at 5:05 PM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> Christian poked me offlist about the rounding patch. While talking about
> that patch with Johannes I began to wonder if we have any interest in
> maintaining a page on the wiki (or a README in php-src) with conta
>>> 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 ne
On Mon, 29 Sep 2008 19:30:00 +0300, "Vesselin Kenashkov" <[EMAIL PROTECTED]>
wrote:
> My proposal is (if possible/reasonable/performance wise of course) to have
> a
> fatal error thrown when during the parse time the engine discovers
> duplicates like the one described above. What is the point t
On Mon, Sep 29, 2008 at 17:05, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> IIS we have the windows team (presumably on all CPU variations?). FreeBSD is
> covered by Yahoo.
It is?
I can't recall any extensive testing from Y! before any release.
Sure, they use FreeBSD but I don't think they even
On Mon, 2008-09-29 at 19:24 +0200, Janusz Lewandowski wrote:
> Monday 29 September 2008 18:35:45 Stefan Walk napisał(a):
> > On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote:
> > > So as prevoius speaker suggested, and I personaly got to conclusion in
> > > other thread that ":" is ideal.
> > > 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
On 9/29/08, Stefan Walk <[EMAIL PROTECTED]> wrote:
>
> > 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;
It's only a problem when you use fully qualified names inside a
ternary operation, and can
Monday 29 September 2008 18:35:45 Stefan Walk napisał(a):
> On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote:
> > 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?
Mike,
I have a few questions about the API and target use cases. What is the
best medium to ask these questions and document them? This thread
certainly is not the best place im sure of.
Thanks,
Ralph
Michael Wallner wrote:
Jani Taskinen wrote:
So pecl/http is actually ext/curl with OO
On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote:
> 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;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
David Zülke wrote:
> just curious, why is ext/soap internally duplicating this http stuff
> instead of using the http stream stuff directly? or did I misunderstand
> something?
good question. :)
As I remember php streams weren't able to do all necessary things which
were necessary for ext/soap,
+1 for : from me.
Ternary. Operator. Trouble.
Otherwise it'd get my vote too.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I thought that : was rejected because of the terniary operator? I'm not
going to search now for the discussion but for sure there were serious
objections against : , otherwise it would be natural to use it. How you
propose to handle the ambiguities like:
Parenthesis are a solution, but I have no
just curious, why is ext/soap internally duplicating this http stuff
instead of using the http stream stuff directly? or did I
misunderstand something?
Am 29.09.2008 um 10:11 schrieb Dmitry Stogov:
Hi Brian,
I think you patch does the things you like properly, but why do we
need
such
2008/9/29 Jordi Boggiano <[EMAIL PROTECTED]>
> On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning <[EMAIL PROTECTED]> wrote:
> > +1, I second this completely
> >
> > From someone who *was* using namespaces developing against the 5.3
> branch,
> > this is going to happen sooner or later. I found that :
Hi Rasmus,
Rasmus Lerdorf wrote:
> Dmitry Stogov wrote:
>> Hi Brian,
>>
>> I think you patch does the things you like properly, but why do we need
>> such ability? I don't see a use-case.
>>
>> In case of accepting this patch, we also need to care about duplicate
>> headers.
>
> Some web services
Hi,
Christian poked me offlist about the rounding patch. While talking
about that patch with Johannes I began to wonder if we have any
interest in maintaining a page on the wiki (or a README in php-src)
with contact information for each OS/CPU/Webserver combination.
I guess for Apache on
Hi,
Ok before we all go crazy with the NS separator debate, some reading
(which also links to a few interesting posts/sites):
http://marc.info/?l=php-internals&m=113313170231815&w=2
http://marc.info/?l=php-internals&m=113345477123705&w=2
http://marc.info/?l=php-internals&m=117742643931293&w=2
Dmitry Stogov wrote:
Hi Brian,
I think you patch does the things you like properly, but why do we need
such ability? I don't see a use-case.
In case of accepting this patch, we also need to care about duplicate
headers.
Some web services require custom headers for authentication or to bounce
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning <[EMAIL PROTECTED]> wrote:
> +1, I second this completely
>
> From someone who *was* using namespaces developing against the 5.3 branch,
> this is going to happen sooner or later. I found that :: just causes to many
> questions when used in namespaces.
>
> sure we can break things if there is a compelling reason
> to do so, i'm just totally missing the compelling part here ...
>
>
This is not going to happen. This thread is over.
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/
toString() should work as expected, because you first realize that this is a
class, so it is concatenation and toString() should be called.
As I understand namespaces are resoved in compile time, so when it comes to
executing code - byte code for MY_CONST.MyCLASS::staticMethod() and
MY_NAMESPACE.M
marius popa wrote:
>> 1. Break every single PHP script that is currently in existence.
> maybe an legacy mode can be included in ini
we want less of such legacy mode options, not more
plus this would have to be configured per application
and not just per server
>> 2. Break syntax highlighting (
hi Johannes.
On Mon, Sep 29, 2008 at 3:15 PM, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-29 at 14:32 +0200, David Zülke wrote:
>> Totally hating to bring this up again (and hijacking this thread), but
>> can we please enable ext/xsl by default in 5.3? :>
>
> Only possible when
On Mon, 2008-09-29 at 15:35 +0400, Alexey Zakhlestin wrote:
> It can be disabled during beta-phase.
> Currently, we should focus on finding bugs and fixing those — that's
> what alpha is about. It's easier to do this, if phar is enabled.
Exact. That's my idea, too. By enabling by default we get mo
On Mon, 2008-09-29 at 14:32 +0200, David Zülke wrote:
> Totally hating to bring this up again (and hijacking this thread), but
> can we please enable ext/xsl by default in 5.3? :>
Only possible when bundling libxslt -> no way.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
Jani Taskinen wrote:
> Seems like PHAR causes quite unexpected things, f.e.
> http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not
> exist. Please, can this crap be disabled by default (ALWAYS) and only
> those who actually need it can enable it?
Hi Jani,
Classic overreacting,
2008/9/29 Arvids Godjuks <[EMAIL PROTECTED]>:
> String concatenation woun't be affected, because you can't concatenate class
> definitions like in my example.
> To concatenate you should use variables or strings/numbers. So I don't see
> any complications with that.
>
> 2008/9/29 Stan Vassilev | FM
Totally hating to bring this up again (and hijacking this thread), but
can we please enable ext/xsl by default in 5.3? :>
- David
Am 29.09.2008 um 13:24 schrieb Marcus Boerger:
Hello Jani,
we're in alpha and fix all of those issues.
in contrast to 99.9% of our users it is very easy for
On Thu, Sep 18, 2008 at 9:25 PM, Jordan Moore <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 18, 2008 at 11:06 AM, Brian Moon <[EMAIL PROTECTED]> wrote:
>> mike wrote:
>>>
>>> Personally I love the $. It makes it so much easier to identify
>>> variables. It's a single character. Can't see the need honest
Currently, we should focus on finding bugs and fixing those — that's
what alpha is about. It's easier to do this, if phar is enabled.
Precisely. If phar hadn't been enabled by default we wouldn't know about
this missing check until someone hit it in production!
- Steph
--
PHP Internals - PH
On Mon, Sep 29, 2008 at 3:32 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> Top posting since you started it.. :)
>
> Yes, I do disable everything I don't need. You don't need to lecture me
> about that. I was just pointing out that this ext/phar/ seems to do things
> most enabled by default extens
Top posting since you started it.. :)
Yes, I do disable everything I don't need. You don't need to lecture me
about that. I was just pointing out that this ext/phar/ seems to do
things most enabled by default extensions don't do. Like affect the very
core of PHP. So enabling such by default is
Hello Jani,
we're in alpha and fix all of those issues.
in contrast to 99.9% of our users it is very easy for you to disable it.
But the majority will only get the extension when we enable by default. And
it is one of the big plans for 5.3 to finally support native packaging to
make a lot of
Seems like PHAR causes quite unexpected things, f.e.
http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not
exist. Please, can this crap be disabled by default (ALWAYS) and only
those who actually need it can enable it?
--Jani
--
PHP Internals - PHP Runtime Development Maili
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (67 total -- which includes 30 feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
===
Hi Brian,
I think you patch does the things you like properly, but why do we need
such ability? I don't see a use-case.
In case of accepting this patch, we also need to care about duplicate
headers.
Thanks. Dmitry.
Brian J. France wrote:
> After some more testing I needed to tweak the patch and
String concatenation woun't be affected, because you can't concatenate
class definitions like in my example.
To concatenate you should use variables or strings/numbers. So I don't see
any complications with that.
MyNameSpace.SomeClass::_getInstance()->SomeDBClass->Query();
You're forget
47 matches
Mail list logo
