People, when you will start to learn that such approach is a mess?
First, use ' ' instead of " " and format your SQL better and you woun't have
any problems:
a). It's more readable without syntax highlighting
b). It's just faster.
c). It's a good style.
d). I think if that is easy to do, it would
Hello,
While I was working on getdate function, found different behavior with
respect to http://in.php.net/manual/en/function.getdate.php
This is observed only on linux 64bit.
Here is code
As per documentation weekday should be Sunday through Saturday but I
got "Unknown".
Here is the output:
arr
Hello,
What is the chance of support for constants in double-quoted strings
in PHP 5.3 or PHP 6.0?
This is something I have wanted for some time now.
Use cases:
Writing an SQL query that makes use of a status field
Syntax suggestions:
Constants would need to be contained within curly braces. e
Hi,
Thanks for your positive feedback about my idea and sorry for hijacking this
thread.
Although my C skills are limited to its syntax only I'll create an RFC, then
someone
else might give it a try an create a patch.
All the best,
Ionut
On Tue, Oct 28, 2008 at 4:23 PM, Kalle Sommer Nielsen
<[
Ilia, Derick, Marcus and all others with multiple assigned bug reports:
PLEASE update the assign status by either removing it and commenting you're the
wrong person / you're not going to touch the issue / don't care / whatever so
that others can take a look at the issues.
Now it's a huge list
On Tue, Oct 28, 2008 at 2:30 PM, Josh <[EMAIL PROTECTED]> wrote:
> What about just silently converting newline to '\n' and tab to '\t',
> etc. I mean if you cant put those characters in a string, who will
> notice? or better, just use a single-quoted string.
>
Random programmer here, but I really
What about just silently converting newline to '\n' and tab to '\t',
etc. I mean if you cant put those characters in a string, who will
notice? or better, just use a single-quoted string.
Regards,
Josh
On Wed, Oct 29, 2008 at 1:28 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Stefan,
>
>
On Tue, Oct 28, 2008 at 20:01, Kalle Sommer Nielsen <[EMAIL PROTECTED]> wrote:
> Yes patches for the actually extension is normally sent to internals
> and test patches are sent to QA people.
Speaking of "QA people", how about crediting those who are actually
working on QA and removing the names w
Stan,
You are so correct. I change my vote. Im assuming putting everything
into the php namespace would allow 'use php', correct?
In this case all that would be needed to get existing functionality
would be to add 'use php' to the top of every file.
Perhaps a small piece of logic could be added w
2008/10/28 marius popa <[EMAIL PROTECTED]>:
> On Tue, Oct 28, 2008 at 6:57 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
>> hi Marius,
>>
>> 2008/10/28 marius popa <[EMAIL PROTECTED]>:
>>> there is an small modification for interbase tests
>>> in 003.phpt (ext/interbase/tests/003.phpt)
>>> in the expe
there is an small modification for interbase tests
in 003.phpt (ext/interbase/tests/003.phpt)
in the expected output it should be
this way
diff -u ../../../../php5.3-200810201430/ext/interbase/tests/003.phpt 003.phpt
diff -u ../../../../php5.3-200810201430/ext/interbase/tests/003.phpt 003.phpt
---
On Tue, Oct 28, 2008 at 6:57 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> hi Marius,
>
> 2008/10/28 marius popa <[EMAIL PROTECTED]>:
>> there is an small modification for interbase tests
>> in 003.phpt (ext/interbase/tests/003.phpt)
>> in the expected output it should be
>> this way
>
> Thanks a lo
Hi!
What, if any, performance penalty should we expect with the proposed
namespace changes when executing existing code that does not use
namespaces? Do we need to change existing namespace-free code in order
If you don't use namespaces, none I guess (well, compiling would be a
little slow
hi Marius,
2008/10/28 marius popa <[EMAIL PROTECTED]>:
> there is an small modification for interbase tests
> in 003.phpt (ext/interbase/tests/003.phpt)
> in the expected output it should be
> this way
Thanks a lot for contrbution tests for interbase :)
You may like to post it on the php QA mail
marius popa wrote:
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue i think
core developers should be more diplomatic and offer the good solution not
close the eyes and wash the hands and go forward
Hello Greg,
thanks for finalizing this.
marcus
Sunday, October 26, 2008, 4:37:37 PM, you wrote:
> Hi all,
> Let me make this brief: there will be lots of complaining about the
> namespace separator.
> Stop. Now.
> It serves no possible useful purpose. If you want to discuss why this
> wa
Hello Stefan,
If the engine fails to lookup a class and detected a namespace separator
we could actually add this check as well and suggest it as a probable cause
of the error.
marcus
Tuesday, October 28, 2008, 1:49:00 PM, you wrote:
> Hi Johannes,
> Johannes Schlüter schrieb:
>>> to me it d
Hello marius,
typical slashdot php artical. 'PHP is the worst crap ever - god bless
perl' The issue in this case is a confused user. See other mails to
do it right and an archive of thousands of mails discussing the topic (and
no, I am not kidding about that amount). And I have more personal
Lars Strojny wrote:
>> I've not seen plenty of "Class::singleton()" myself, getInstance is an
>> accepted standard in all languages, including the PHP code I wrote,
>> and I've had experience with.
>
> That's my point, yes. pecl_http uses ::singleton() instead of
> getInstance().
Well, sure--that
2008/10/28 Stan Vassilev | FM <[EMAIL PROTECTED]>:
>> > class Test
>> {
>> public function hello($who)
>> {
>> echo 'Hello ' . $who;
>> }
>> }
>>
>> $closure = function()
>> {
>> static $instance;
>>
>> if(!$instance)
>> {
>> $instance = new Test;
>> }
>>
>> return($instance);
>> };
>>
>> $closure-
Johannes Schlüter wrote:
> I think it's fine to have settings for limitations on pconnects, but
> stuff like http.request.methods.allowed or http.only_exceptions should
http.request.methods.allowed is handled at RINIT.
http.only_exceptions is PHP_INI_ALL, though introducing it at all might
have b
I would say "no" for 5.3. But for 6 it would be fantastic to have all
array-related
operations supporting ArrayAccess interface, where possible.
+1 for this.
Hi,
cu, Lars
Just making sure but: I think the BC break should be fixed. It's breaking
actual code out there. The practice of passing
Hi Ionut
2008/10/28 Ionut Gabriel Stan <[EMAIL PROTECTED]>:
> While we're at this and considering the new lambdas that we now have in the
> language
> I must say I'd like some functions to support Traversables. Those would be:
>
> array_map(), array_reduce(), array_filter(), array_walk() and
> arr
Hi Ionut,
Am Dienstag, den 28.10.2008, 16:00 +0200 schrieb Ionut Gabriel Stan:
[...]
> While we're at this and considering the new lambdas that we now have
> in the language I must say I'd like some functions to support
> Traversables.
Nevertheless I agree that this would be a great feature, I wo
While we're at this and considering the new lambdas that we now have in
the language
I must say I'd like some functions to support Traversables. Those would be:
array_map(), array_reduce(), array_filter(), array_walk() and
array_walk_recursive()
Although I'd rather want a class (because the a
Hi Andrei,
Am Montag, den 27.10.2008, 11:34 -0700 schrieb Andrei Zmievski:
[...]
> I would say "no" for 5.3. But for 6 it would be fantastic to have all
> array-related
> operations supporting ArrayAccess interface, where possible.
+1 for this.
cu, Lars
--
Jabber: [EMAIL PROTECTED]
Webl
Hi Stan,
Am Dienstag, den 28.10.2008, 14:33 +0200 schrieb Stan Vassilev | FM:
[...]
> I've not seen plenty of "Class::singleton()" myself, getInstance is an
> accepted standard in all languages, including the PHP code I wrote,
> and I've had experience with.
That's my point, yes. pecl_http uses :
Dave Ingram wrote:
> marius popa wrote:
>
>> an semisolution would be an php.ini variable
>> like
>> NAMSPACE_SEPARATOR="::"
>> so if you have an issue with your classes can be reset to "\" or
>> whatever with ini_set
>>
>> i think it's easy to be done if i look at the patch that created the
>>
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "\" or
whatever with ini_set
You're always welcome to change the separator in the PHP source code,
compile that and use your fork as you please. The source code i
Hi Marius,
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue
"All the community" is not screaming at the namespace issue. "A minority of
the community" is, but most of that minority would scream wh
marius popa wrote:
> an semisolution would be an php.ini variable
> like
> NAMSPACE_SEPARATOR="::"
> so if you have an issue with your classes can be reset to "\" or
> whatever with ini_set
>
> i think it's easy to be done if i look at the patch that created the
> backslash separator issue
>
So
On 28.10.2008, at 13:41, marius popa wrote:
but when all the comunity screems at the namespace issue i think
core developers should be more diplomatic and offer the good
solution not
close the eyes and wash the hands and go forward
its always nice to ask for diplomacy after throwing around
On Tuesday 28 October 2008 13:41:24 marius popa wrote:
> an semisolution would be an php.ini variable
> like
> NAMSPACE_SEPARATOR="::"
> so if you have an issue with your classes can be reset to "\" or
> whatever with ini_set
Please make this list readonly or at least moderated for non-devs (yes,
2008/10/28 marius popa <[EMAIL PROTECTED]>:
> On Tue, Oct 28, 2008 at 11:17 AM, Steph Fox <[EMAIL PROTECTED]> wrote:
>> Hi Marius,
>>
>> Don't know i never saw something so ugly since c++ templates syntax
>> I find it funny that php is designed by committee and no one listen to
>> the community
>>
Hi Johannes,
Johannes Schlüter schrieb:
>> to me it does not seem to make sense to use tabs or linefeeds (or
>> whatever other strange escaped characters) in namespace'd names. So I'd
>> suggest generating a fatal error when somebody uses them.
>
> \n is no newline (yes "\n" is, \n not ...) -> no
We are going to ignore the inherit problems that calling
file_get_contents(__FILE__); would cause...
Also, I disagree with a PHP namespace. the looseness of the language
is one of its strong points. Some things should be made strict, I
agree, bit it start with a php namespace and where does it en
On Tue, Oct 28, 2008 at 11:17 AM, Steph Fox <[EMAIL PROTECTED]> wrote:
> Hi Marius,
>
> Don't know i never saw something so ugly since c++ templates syntax
> I find it funny that php is designed by committee and no one listen to
> the community
> ===
>
> You have written to this list a few times be
We are going to ignore the inherit problems that calling
file_get_contents(__FILE__); would cause...
Also, I disagree with a PHP namespace. the looseness of the language
is one of its strong points. Some things should be made strict, I
agree, bit it start with a php namespace and where does it end
I've not seen plenty of "Class::singleton()" myself, getInstance is an
accepted standard in all languages, including the PHP code I wrote, and I've
had experience with.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Hi Johannes,
Am Montag, den 27.10.2008, 19:59 +0100 schrieb Johannes Schlüter:
[...]
> I think it's fine to have settings for limitations on pconnects, but
> stuff like http.request.methods.allowed or http.only_exceptions should
> imo be set as object properties (or similar), not globally using in
Stan Vassilev | FM wrote:
Opinions about how disruptive a mandatory backslash for global symbols *in
namespaces* would be, are welcome. Keep in mind that making the backslash
optional will lead to code breakage (such as for above drop-in replacements,
class autoloading etc.) and slower perform
I like that way too
On Tue, Oct 28, 2008 at 9:02 PM, Karsten Dambekalns <[EMAIL PROTECTED]> wrote:
> Hi.
>
> Stan Vassilev | FM wrote:
>>
>> A yet another compromise is possible as the lesser evil:
>
> ...
>>
>> They key change is: not to make difference between internal and user
>> global functi
Hi.
Stan Vassilev | FM wrote:
A yet another compromise is possible as the lesser evil:
...
They key change is: not to make difference between internal and user
global functions, just fall back to global ones, so that there's no
additional confusion among drop-in replacements, user resources,
Hi Marius,
Don't know i never saw something so ugly since c++ templates syntax
I find it funny that php is designed by committee and no one listen to
the community
===
You have written to this list a few times before. Here's a brief summary of
your posts:
1) We should be moving to git not svn
History has shown
us that breaking code (e.g. PHP4 - PHP5) slows adoption of new
versions.
Bad example as PHP4 > 5 broke existing code. No existing code has namespaces
in it. Anyway:
A yet another compromise is possible as the lesser evil:
Resolution for classes:
namespace
On Mon, Oct 27, 2008 at 5:50 PM, Ólafur Waage <[EMAIL PROTECTED]> wrote:
> I found that he had one valid question that i would like to see answered.
>
>> is the below allowed ?
>>
>> $bar = new Module \ Foo \ Bar();
Don't know i never saw something so ugly since c++ templates syntax
I find it funny
I totally agree with Josh, same argument - resolving to global resources
should be by default, so we don't need to rewrite a lot of code, witch we
want to namespace. Namespaced functions will be called far less in code then
global ones.
2008/10/28 Josh <[EMAIL PROTECTED]>
> Hey,
>
> I think that
47 matches
Mail list logo
