not chose the easier path?
Or to put this differently: Of course the core contributors are at
liberty to call the next major version 6, but I think there is wisdom in
going straight to 7.
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com
, why not
chose the easier path?
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that decision - must come quickly. Yes, even
before there is a spec!
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
it as a whole.
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2010-03-12 18:36, Tomas Kuliavas skrev:
Keryx Web rašė:
2. If so, what will happen to array access in strings that are de
facto Unicode? Will the more clunky mb_substr() be the only option?
What will happen to array access in unicode strings, if code wants to
access them in bytes? Will some
=crockford-yuiconf2009-state
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of all
people who use your product. We are your customers ;-)
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to address. Without the keyword use it is not
a closure, as Mathieu has already pointed out.
FWIW, I moved the discussion to the PHP Doc list, as the discussion here
seemed to die out and fixing the manual would be the most obvious first
step.
--
Keryx Web (Lars Gunther)
http://keryx.se/
http
variables are part of the closure is very easy to explain.
The way you are using the word closure in your reply is consistent
with the way I'd like to see it used, though.
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
--
PHP
and I will take my questions
elsewhere.
Oh, yes, the question:
Wouldn't you agree that it is better for PHP to use the word closure as
it is being used in the JavaScript community?
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com
point me to a better place to ask these questions?
On 2009-07-15 11:23, Keryx Web wrote:
On 2009-07-15 00:06, Andrei Zmievski wrote:
I believe the latest discussion settled on rewriting ctype_* functions
to use ICU internally in HEAD, so that they work correctly on Unicode
strings.
-Andrei
asking these questions are not out of place. I
chose this list since I need authoritative answers and my questions are
about internals issues. I beg your forgiveness if I have contributed to
any unnecessary noise.
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http
in the future.)
B. Should not the the manual be telling people about these functions
being non-future proof?
--
Keryx Web (Lars Gunther)
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
1. http://interact.webstandards.org/
2. http://www.php.net/manual/en
Steph Fox skrev:
Would anyone still planning to vote please include a *brief* explanation
of why they're making the choices they're making?
OK. I'm in favour of number 3.
My main involvement with PHP is teaching it. I spend an endless amount
of time tracking down misplaced or omitted
Lukas Kahwe Smith skrev:
But if we put the burden of being the last planned PHP 5 release onto
5.3, we will have huge issues getting it out the door. So please let us
keep 5.4 on the table, but at the same time do everything we can to get
PHP 6 onto some sort of release schedule.
Let me see
Alain Williams skrev:
Nice in some ways, except that it is different from the way that type hinting
works in PHP5 classes - again: keep to one way of doing things.
': RetType' might be possible, but it is very different from where type hints
are given currently in PHP.
Stick with:
Alain Williams skrev:
Taking it a bit further, if the function returns a reference (eg to its
argument):
function int myfunction(int $param)
Alternative could be:
function int myfunction(int $param)
But I think that the first form is better.
From one whose job it is to
Andi Gutmans skrev:
I think if the syntax is confusing we can go for just a single quote as
part of the operator which doesn't make it look like just another plain
old string, e.g.:
$bar ='FOO
Sdjfslk
Sdfkj
FOO;
+1/2
Once again thinking as a teacher... Just a few weeks into my last course
Rasmus Lerdorf skrev:
PHP is first and foremost a Web scripting language. Everything we do
and every decision is based on that.
There is one aspect that has popped up in the discussion about array
syntax but not here where it is almost as applicable.
ECMAScript 4 will have introduce
Rasmus Lerdorf skrev:
It may not be the browser that misses the script tag. It may be the
developer.
To make things clear. My intention was not to question the value in
escaping data or even to give an opinion whatsoever about Sara's patch.
I was only replying to Alexey's notion that one
Stanislav Malyshev skrev:
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
What's 100% right? Any proposals (besides braces)?
Actually I did mention an alternative a while ago, and that would be to
learn from ECMAScript 4. This is from John Resigs
Hi!
I am trying to understand the internal workings of two PHP-additions to
the DOM-functionality.
1. When using the shortcut DOMElement::nodeValue on an element node,
where the standard says DOMElement::firstChild::nodeValue, is there any
difference whatsoever between DOMElement::nodeValue
Rob Richards skrev:
These would most certainly not make the standard. The first already
exists in the form of textContent in Level 3 specs.
The first one was not on my agenda. Sorry for my lack of clarity.
The second is a limited piece of functionality for creating content
within an
Rasmus Lerdorf skrev:
I think that is one of the strongest reasons not to implement something
actually. If there is a way to do something in a clear and concise
syntax, adding an alternate less clear syntax that isn't immediately
obvious to everyone simply obfuscates the language.
The other
Hi all!
Are there any information available about the specifics and progress of
date_format_locale?
Speaking as a non native English speaker this is a highly anticipated
function.
Three specific questions:
1. Is there an implementation in HEAD?
2. Is there any chance of a backport to PHP
Derick Rethans skrev:
On Wed, 19 Sep 2007, Keryx Web wrote:
3. Will it accept formatting according to date() or strftime() syntax?
date(), but with some additions of course. How, I still need to work
out.
Is that set in stone? Most non-english application developers are
probably more
Pierre skrev:
Only ext/mysql and ext/mysqli use it. PDO is somehow planed but I
have serious doubts about the motivations of mysql to ever support pdo
like they support other generic connectors (see .net...).
The first posts on the net from MySQL-people talked about mysqli first,
PDO second
Lukas Kahwe Smith skrev:
Stanislav Malyshev wrote:
10) Split off deprecation from E_STRICT into E_DEPRECATED
0. Why do we *need* it again?
Without it, we mix 2 different concepts, we also make it needlessly hard
for library maintainers to leverage E_STRICT. As a result library
Stanislav Malyshev skrev:
And they, btw, are not ashamed of calling it namespaces just because
it's not c++ ;)
Exactly. That was my main point. And, as I said,ECMAScript 4 will most
probably be the main other language for most ordinary PHP developers,
not Java and certainly not C.
Tijnema skrev:
Since JavaScript (or ECMAScript) doesn't have namespaces, people that
hear the name namespace for php will either don't know what it is, or
think that it's the same as the C implementation.
ECMAScript 3 aka JavaScript 1.x does not have NS.
ECMAScript 4 aka JavaScript 2 will
Daniel Jänecke skrev:
I don't get the point of it. IMO this will only add another level of
confusion to sourcecode; unless someone has a real good example (better
than those in the posted link) where this technique is required I cannot
see which benefit this feature adds.
1. Neither daniel
Zeev Suraski wrote:
Other than the theological views some people on this list have
(either very pro-BC or anti-BC), what did keeping BC cost us?
Hey that must be me he is talking about - as I am a real theologian!
So for a theologians 2c on Unicode:
1. Teaching unicode and PHP
As stated
Ilia Alshanetsky wrote:
Do you have a patch?
Also @Antony Dovgal in the let blocks thread
Short answer: No.
The reason I posted my suggestions on this list was that a while ago I
had a few ideas as to how PHP could be improved. A seasoned PHP
developer suggested that I'd take my
I do not know if this post made it to the list a while ago. No one
answered and i see I used the wrong account to send it. Please forgive
me if this is a redundant re-post.
This is a suggestion I think would not be too hard to implement:
Skip libc for all random functions. As I see it there
Well, then I guess we have no choice but to declare official PHP 4 end-of-life
to be on 8:08:08 pm too :) Now we only need to choose a suitable timezone :)
Well, for us using the 24 hr clock I'd say 8:08:08 am (ante meridiem) as
it otherwise will be 20:08:08 when we speak and write about
35 matches
Mail list logo
