Instead of adding yet-another feature, how about fixing the bugs in the
existing ones first? f.e. there is open bug related to closures, fixing
that might be good idea before adding yet another way to abuse them:
http://bugs.php.net/50230
And in total there are 33 scripting engine (includi
Religious programming is the problem.
On Tue, Jan 19, 2010 at 6:28 PM, Gwynne Raskind wrote:
> On Jan 19, 2010, at 5:54 PM, Alain Williams wrote:
$eep->oop()->ork()->ah()->ah();
the newcomer will have to spend significant time rummaging around the
source code to figure out wha
On Wed, Jan 20, 2010 at 11:35 AM, Christian Grobmeier
wrote:
>>> Why would this imply "dropping" the object?
>>>
>>> This:
>>> $foo = (new bar())->someSetter();
>>> Looks a lot better than this
>>> $foo = new bar();
>>> $foo->someSetter();
>>
>> The second version is much clearer. You kn
On Wed, Jan 20, 2010 at 01:05:14PM +0100, Christian Grobmeier wrote:
> On Wed, Jan 20, 2010 at 11:35 AM, Christian Grobmeier
> wrote:
> >>> Why would this imply "dropping" the object?
> >>>
> >>> This:
> >>> $foo = (new bar())->someSetter();
> >>> Looks a lot better than this
> >>> $foo = ne
>> I also think that:
>> $foo = (new bar())->someSetter();
>
> someSetter() could return $this, although unlikely. The result of the line
> above would be that the bar object is garbage collected after being created
> & method someSetter() invoked. To keep it one would have to do:
In very ra
On Tue, January 19, 2010 10:20 am, Eddie Drapkin wrote:
> On Tue, Jan 19, 2010 at 11:05 AM, Stanislav Malyshev
> wrote:
>> The second was next on my list, while the first seems to me kind of
>> exotic -
>> why create object only to call one method and immediately drop it?
>> Why this
>> method is
Hi,
I've updated each of the following bug reports
http://bugs.php.net/bug.php?id=50475 - DateTime::setISODate followed
by DateTime::setTime
http://bugs.php.net/bug.php?id=49059 - DateTime::diff() repeats
previous sub() operation
http://bugs.php.net/bug.php?id=49904 - DateTime::modify('last day
Dots and spaces in variable names are converted to underscores. For
example becomes $_POST["a_b"].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
reason, when building "linked data" / rdf based applications using PHP
it's most beneficial to
Dots and spaces in variable names are converted to underscores. For
example becomes $_POST["a_b"].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
I'm also using dots for this reason, so I feel your pain. What I ended up
doing is convertin
Stan Vassilev wrote:
Dots and spaces in variable names are converted to underscores. For
example becomes $_POST["a_b"].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
I'm also using dots for this reason, so I feel your pain. What I ended
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.
-Rasmus
Hi,
I'm not sure it needs to happen anywhere. Such symbol
Stan Vassilev 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.
-Rasmus
Hi,
I'm not sure it needs to happen
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() c
> 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() c
Stan Vassilev wrote:
>
> I hope PHP6 will remove this processing as register_globals will be
> completely removed at that point.
I'd be happy if it stayed like it is, for backwards compatibility. If
not, then there needs to be some reasonably straightforward way for an
app to work out how PHP has
I'd be happy if it stayed like it is, for backwards compatibility. If
not, then there needs to be some reasonably straightforward way for an
app to work out how PHP has messed up its input so that it can put it
back together (compare get_magic_quotes_gpc()).
In any case, it could be better docume
I have tried to contact the maintainers of PDO with this, but have yet
to get a response. Can I get this reviewed and if possible commited?
Fixes BUG # 50755:
http://bugs.php.net/bug.php?id=50755&edit=1
Compiled and tested with PHP SVN 5.2
Index: ext/pdo_dblib/dblib_stmt.c
===
Stanley Sufficool wrote:
I have tried to contact the maintainers of PDO with this, but have yet
to get a response. Can I get this reviewed and if possible commited?
Fixes BUG # 50755:
http://bugs.php.net/bug.php?id=50755&edit=1
Compiled and tested with PHP SVN 5.2
PDO development has it's own
18 matches
Mail list logo
