Just in case anyone lost track... it seems the consensus is to allow the
optional parameter syntax for class hints. The Nullable class hint doesn't
seem to be well supported among the purists so the optional param syntax,
while not optimal, is better than leaving it as it is now. One can always
rea
While you are correct that invalid offset in a string will produce an
error message. This error message is E_NOTICE, given that our default
INI error reporting level won't display those it's arguable that very
few people will see them and consequently do something about it.
> echo $a{strlen($a)
Derick Rethans wrote:
- Adding new language constructs in mini releases is IMO not the way to
go as it will make it possible impossible to run script that use this
new construct not even parse on PHP 5.0.x servers. Adding normal new
functions does not have this problem of course, as those scr
Derick Rethans wrote:
How can you *need* this, you can use substr() just fine.
Almost no peace of functionality in PHP in unique, some extensions
duplicate core/standard functionality and vice versa. Usually the "core"
offers a simpler access to a resource and full pledged extensions
gives the
"Andi Gutmans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Nah that patch won't do because it'll effect [] also.
> It's more complicated than that. I've tried separating them in the past
> and it was annoying (and didn't have time to finish it off).
>
> Andi
>
True... I should
Derick Rethans wrote:
On Fri, 29 Oct 2004, Greg Beaver wrote:
Ilia Alshanetsky wrote:
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.
Ex. $a = "123"; echo $a[-1]; // would print 3
I don't think we s
Nah that patch won't do because it'll effect [] also.
It's more complicated than that. I've tried separating them in the past and
it was annoying (and didn't have time to finish it off).
Andi
At 05:51 PM 10/29/2004 -0700, Sara Golemon wrote:
> - Adding new language constructs in mini releases is
> - Adding new language constructs in mini releases is IMO not the way to
> go as it will make it possible impossible to run script that use this
> new construct not even parse on PHP 5.0.x servers. Adding normal new
> functions does not have this problem of course, as those scripts are
> s
echo $a{strlen($a)-1}; ? is that really that bad.
I do worry that at present
$a = "a string";
$p = 0
while( $p < strlen($p) )
.. do stuff that could do $p-- or $p++
echo $a{$p};
}
at present that would produce a nice error if you went < 0.. easy to
spot.. - if -ve was supported it could d
On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Andi Gutmans wrote:
>
> > Yeah, I also thought the word "need" is a bit strong :) It's more like
> > "syntactic sugar which is nice-to-have"
>
> As I just told Ilia on IRC, I think we should not add this (now) for a
> coupl
On Fri, 2004-10-29 at 19:29, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Andi Gutmans wrote:
>
> > Yeah, I also thought the word "need" is a bit strong :) It's more like
> > "syntactic sugar which is nice-to-have"
>
> As I just told Ilia on IRC, I think we should not add this (now) for a
> coupl
On Fri, 2004-10-29 at 19:31, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Robert Cummings wrote:
>
> > On Fri, 2004-10-29 at 19:04, Derick Rethans wrote:
> >
> > > Yeah, [] is for arrays, {} for string indexes though I still think this
> > > should not be in, one can use substring for this. Someth
I think we should not follow this discussion on internals@ and instead
we should have a subcommittee to study whether or not the word need
was appropriate in the context of the substring operator, or whether
in fact, "would be nice to have, but might be able to continue living"
would've been a more
On Fri, 29 Oct 2004, Robert Cummings wrote:
> On Fri, 2004-10-29 at 19:04, Derick Rethans wrote:
>
> > Yeah, [] is for arrays, {} for string indexes though I still think this
> > should not be in, one can use substring for this. Something like a
> > "negative string index" is IMO too much magic.
>
On Fri, 29 Oct 2004, Andi Gutmans wrote:
> Yeah, I also thought the word "need" is a bit strong :) It's more like
> "syntactic sugar which is nice-to-have"
As I just told Ilia on IRC, I think we should not add this (now) for a
couple of reasons:
- Adding new language constructs in mini releases
On Fri, 2004-10-29 at 19:04, Derick Rethans wrote:
> On Fri, 29 Oct 2004, Sterling Hughes wrote:
>
> > why not add it with the {} operators then?
>
> Yeah, [] is for arrays, {} for string indexes though I still think this
> should not be in, one can use substring for this. Something like a
> "neg
* Thus wrote Christian Schneider:
> Please don't add another parameter syntax (especially with line-noi...
> err special characters) like [BaseClass]. This would make PHP more
> unreadable than it needs to be for a minor feature. To allow
> foo(BaseClass $objA = null) to also accept foo(null); h
At 01:05 AM 10/30/2004 +0200, Derick Rethans wrote:
On Fri, 29 Oct 2004, Greg Beaver wrote:
> Ilia Alshanetsky wrote:
> > I am wondering what are people's opinions on adding support for negative
> > string offsets that could be used to access data from the end of a
string.
> >
> > Ex. $a = "123";
On Fri, 29 Oct 2004, Greg Beaver wrote:
> Ilia Alshanetsky wrote:
> > I am wondering what are people's opinions on adding support for negative
> > string offsets that could be used to access data from the end of a string.
> >
> > Ex. $a = "123"; echo $a[-1]; // would print 3
> >
> > I don't think
On Fri, 29 Oct 2004, Sterling Hughes wrote:
> why not add it with the {} operators then?
Yeah, [] is for arrays, {} for string indexes though I still think this
should not be in, one can use substring for this. Something like a
"negative string index" is IMO too much magic.
Derick
--
Derick Re
On Fri, 29 Oct 2004, Curt Zirzow wrote:
> * Thus wrote Antony Dovgal:
> > On Fri, 29 Oct 2004 01:04:23 -0700
> > Sterling Hughes <[EMAIL PROTECTED]> wrote:
> >
> > > no curl does not need to respect php's safemode, adding such
> > > checks at this level is wrong. people who compile curl, can
We haven't yet separated the semantics of {} and []. It was always planned
but never done.
I'll put it on my TODO and hopefully will find some time to look into it.
Andi
At 04:13 PM 10/29/2004 -0400, Paul G wrote:
- Original Message -
From: "Ilia Alshanetsky" <[EMAIL PROTECTED]>
To: <[EMA
On Fri, 29 Oct 2004, Paul G wrote:
> and what happens in the (admittedly unlikely) case where something else on
> the same box depends on that feature being available in libcurl?
They can build two copies of cURL.
-adam
--
[EMAIL PROTECTED]
author of o'reilly's "upgrading to php 5" and "php co
I've been trying to build PHP-GTK on OSX and ran into something. The
GNU libtool can create shared libraries both with .so and .dylib
extensions, depending on whether they are compiled as modules or
libraries that can be linked against. If -module is specified for
libtool, it'll link an .so lib
- Original Message -
From: "Ilia Alshanetsky" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 29, 2004 3:07 PM
Subject: [PHP-DEV] Negative string offset support
> I am wondering what are people's opinions on adding support for negative
> string offsets that could be us
Sure, I have no operator preference.
Ilia
Sterling Hughes wrote:
why not add it with the {} operators then?
-sterling
On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
I am wondering what are people's opinions on adding support for negative
string offsets that could be
Right, I was about to say that too. If we only did it for the {} operator
it would encourage people to use that little-used operator thereby
removing a source of confusion and at the same time the BC issues are
minimal.
-Rasmus
On Fri, 29 Oct 2004, Sterling Hughes wrote:
> why not add it with t
Exactly what I thought when reading the original post :)
- Michael
> why not add it with the {} operators then?
>
> -sterling
>
>
> On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]>
> wrote:
>> I am wondering what are people's opinions on adding support for negative
>> stri
why not add it with the {} operators then?
-sterling
On Fri, 29 Oct 2004 15:07:05 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> I am wondering what are people's opinions on adding support for negative
> string offsets that could be used to access data from the end of a string.
>
> Ex. $a
Ilia Alshanetsky wrote:
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.
Ex. $a = "123"; echo $a[-1]; // would print 3
I don't think we should do this for arrays, since -1 and similar are
valid arr
I am wondering what are people's opinions on adding support for negative
string offsets that could be used to access data from the end of a string.
Ex. $a = "123"; echo $a[-1]; // would print 3
I don't think we should do this for arrays, since -1 and similar are
valid array keys, which means add
- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Adam Maccabee Trachtenberg" <[EMAIL PROTECTED]>
Cc: "Klaus Reimer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 29, 2004 12:55 PM
Subject: Re: [PHP-DEV] curl_init() is bypassing safe_mode & open_basedir
On Fri, 29 Oct 2004, Adam Maccabee Trachtenberg wrote:
> On Fri, 29 Oct 2004, Klaus Reimer wrote:
>
> > Sterling Hughes wrote:
> > > no curl does not need to respect php's safemode, adding such
> > > checks at this level is wrong. people who compile curl, can do so
> > > without local file a
* Thus wrote Antony Dovgal:
> On Fri, 29 Oct 2004 01:04:23 -0700
> Sterling Hughes <[EMAIL PROTECTED]> wrote:
>
> > no curl does not need to respect php's safemode, adding such
> > checks at this level is wrong. people who compile curl, can do so
> > without local file access, and this will
On Fri, 29 Oct 2004 11:13:33 +0200 (CEST), in php.internals
[EMAIL PROTECTED] (Derick Rethans) wrote:
>Myth: Safe mode makes a PHP installation safe.
>Wrong! It might make it a bit safer, but there is always a possibility
>to work around it.
On the other hand, I think it's a pity not to freshen u
On Fri, 29 Oct 2004, Klaus Reimer wrote:
> Sterling Hughes wrote:
> > no curl does not need to respect php's safemode, adding such
> > checks at this level is wrong. people who compile curl, can do so
> > without local file access, and this will solve their problem.
>
> What about people who
Derick Rethans wrote:
Myth: Safe mode makes a PHP installation safe.
I never said this.
webserver, not of a scripting language and therefore we shall not put
hacks in extensions because libraries do not adhere to safe mode.
If there IS a possibility to make safe-mode a little bit more secure why
On Fri, 29 Oct 2004, Klaus Reimer wrote:
> Safe-mode is a feature of PHP so PHP should make sure that this feature
> is working with all functions included in PHP if it's possible to secure
> the function (otherwise the user must disable it). And there is already
> a patch to do it, so it seems to
Sterling Hughes wrote:
no curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.
What about people who use precompiled packages like the Debian packages?
They do
On Fri, 29 Oct 2004 01:04:23 -0700
Sterling Hughes <[EMAIL PROTECTED]> wrote:
> no curl does not need to respect php's safemode, adding such
> checks at this level is wrong. people who compile curl, can do so
> without local file access, and this will solve their problem.
agree, curl doesn'
On Fri, 29 Oct 2004 10:51:49 +0400
Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Oct 2004 12:07:50 -0400
> Sean Coates <[EMAIL PROTECTED]> wrote:
>
> > Is this legitimate?
> > I took a (very) quick look at bugs, and didn't see it.
>
> you can find patches for all branches in attachment.
no curl does not need to respect php's safemode, adding such
checks at this level is wrong. people who compile curl, can do so
without local file access, and this will solve their problem.
On Fri, 29 Oct 2004 10:51:49 +0400, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Oct 2004 12:
42 matches
Mail list logo
