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
quot;trunk" and enforcing 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
rams, 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
e language, why
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://itpasto
hoo.com/yui/theater/video.php?v=eich-yuiconf2009-harmony
And retold by Doug C:
http://developer.yahoo.com/yui/theater/video.php?v=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
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
anyway.
We are the ones who will get confused, and we are the majority 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
not on PHP's implementation.
Also agreed PHP has anonymous non-closure functions as well, I hope.
This is what I am trying 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 d
out what 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://itpast
the features and set the language.
If I am out of line, please let me know 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://ker
indly 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
pe my 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/
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 semi-col
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:
fun
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 d
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
Andi Gutmans skrev:
I think the current core development team will definitely need help from all
the lurkers on this list.
Abstract:
From the view of someone whose *main* job with PHP is teaching it to
absolute beginners, with little or no previous programming experience,
and who are relati
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 *option
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 t
Rasmus Lerdorf skrev:
It may not be the browser that misses the
Alexey Zakhlestin skrev:
I think I understand what the use-case is…
If the browser doesn't know anything about
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 elem
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 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 fat
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
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 5?
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
maintainers
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 hav
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. Especially
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 suggestio
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 e
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 dan
Hi again!
Now that namespaces seem to be on their way into PHP 6 I wonder if
let-blocks, as in JavaScript 1.7+, ever has been considered for PHP, to
hide global variables from each other?
If so, can someone point me to the discussion?
For those that might have missed JS 1.7:
http://develope
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 i
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 this
38 matches
Mail list logo
