> 1.01 eq 1.1
Could you explain this one to me? In every versioning system I've ever
used, 1.1 would be greater than 1.01, not equal.
> On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev wrote:
>
> > Hi!
> >
> > >> For example, I was not the only one who found it odd that "1.0" is
> > >> conside
Hi!
> For starters, maybe we could use a few examples from the previous thread
> about this
> rfc: http://www.mail-archive.com/internals@lists.php.net/msg57855.html
> I really liked the one example from Jordi
> (http://www.mail-archive.com/internals@lists.php.net/msg57904.html)
This is exactly th
> 1.0.0 and 1.0 are different things.
I think the problem is, version numbers are different things to different
people - I guess the documentation maybe isn't clear enough on precisely
what version numbering scheme it's using. To most people, "1" and "1.0" are
the same thing, because they look lik
On Sat, Jul 21, 2012 at 1:02 AM, Stas Malyshev wrote:
> Hi!
>
> > Call for voting for "Allow use T_AS in closure use statement",
> > https://wiki.php.net/rfc/useas#voting
> >
> > any comment will be appreciated.
>
> I think it would be useful to add some explanation why this change is
> us
Hi!
> The number of values in a DB result set may be unpredictable, but the
> number of _elements_ in each value shouldn't be - and the list() will be
> on those elements:
>
> foreach($resultset as list($id, $name, $address, $phone))
> {
One doesn't see this pattern too much and the reason is
Hi,
My name is Rick.. I done some light work on documentation side of things,
but I had a question because I've been working a lot with the Symfony
framework lately. Some in the Symfony irc room seem to be under the
impression that short_open_tags is to be deprecated in php6. Is there any
weigh
On 2012-07-21 10:28, Stas Malyshev wrote:
Hi!
If I understand this correctly, this is like what Python let's you do
with tuples. It's handy for getting vector components, hostnames and
port numbers, etc. (I apologise for the Python comparison, it is just
the language where I usually encounter t
Hi!
> Top-posting, as not sure where to snip. :)
>
> I think either "??" "??:" as an operator makes sense, and would be
> readable and easy to learn, and resolve any BC concerns people have. I'd
> love to see this in, as the current behavior is basically useless for me
> I don't think I've once h
Hi!
>> I'm not sure I understand why. What's wrong with $src =
>> lowered($src);?
>
> That's just convenience. matter of readability.
IMHO assignment is always more readable than function with magic
unobvious effects. I'd rather always have assignments than scratch my
head each time reading the
Hi!
> Call for voting for "Allow use T_AS in closure use statement",
> https://wiki.php.net/rfc/useas#voting
>
> any comment will be appreciated.
I think it would be useful to add some explanation why this change is
useful, with specific code examples that it improves. Right now it seems
On 2012-07-16, Andrew Faulds wrote:
> An ugly, confusion-causing syntax.
I'm sorry, but how does this add _anything_ to the discussion?
Qualify your statement, please. What do you find "ugly" about the
syntax, and why? Where do you see confusion arising from the syntax -
what problems do you for
On 2012-07-16, Amaury Bouchard wrote:
> --f46d0446312cc5e06104c4f42161
> Content-Type: text/plain; charset=ISO-8859-1
>
> My point is not to add two ways to do the same thing.
> What I'm humbly suggesting to do is to keep the core idea of the
> existing RFC (make things easier when you have to wri
On 21/07/2012, at 10:22 AM, Hartmut Holzgraefe wrote:
> On 07/20/2012 11:07 PM, Stas Malyshev wrote:
>> 1.0.0 and 1.0 are different things. If you want to make a comparison
>> that takes into account only two components, you can just cut them both
>> to two components, then compare.
>
> it is ha
Yeah, that's what I realised as I wrote that. PHP functions don't really
use tuples etc. very much, unlike Python. That said, now we have short
array syntax, and if we add this, perhaps people will use it more.
Still, at the moment the usefulness of this is limited. Perhaps
destructuring assignmen
Hi!
> If I understand this correctly, this is like what Python let's you do
> with tuples. It's handy for getting vector components, hostnames and
> port numbers, etc. (I apologise for the Python comparison, it is just
> the language where I usually encounter this, and it makes heavy use of
> fore
Top-posting, as not sure where to snip. :)
I think either "??" "??:" as an operator makes sense, and would be
readable and easy to learn, and resolve any BC concerns people have. I'd
love to see this in, as the current behavior is basically useless for me
I don't think I've once had code where I c
Python isn't coding-style constrained, it just uses increases and decreases
whitespace as part of the block syntax. It has considerable flexibility,
but not PHP/Perl-level.
On Jul 20, 2012 3:33 PM, "Amaury Bouchard" wrote:
> 2012/7/20 Alex Aulbach
>
> > PS: And if without brackets should be forb
On 07/20/2012 11:07 PM, Stas Malyshev wrote:
> 1.0.0 and 1.0 are different things. If you want to make a comparison
> that takes into account only two components, you can just cut them both
> to two components, then compare.
it is hart to imagine a 1.0 followed by 1.0.0 in real world, but
the only
If I understand this correctly, this is like what Python let's you do with
tuples. It's handy for getting vector components, hostnames and port
numbers, etc. (I apologise for the Python comparison, it is just the
language where I usually encounter this, and it makes heavy use of
foreach-style loops
Hi!
>> For example, I was not the only one who found it odd that "1.0" is
>> considered less than "1.0.0" - wouldn't it make sense to "pad" the shortest
>> version-number with zeroes? e.g. "1.0" if compared against "1.0.0" would be
>> padded with zeroes at the end, e.g. as "1.0.0".
1.0.0 and 1.0
Well, in the spirit of PHP, let's make version_compare_fixed()!
On Jul 20, 2012 1:41 PM, "Rasmus Schultz" wrote:
> From the comments in the documentation, it seems others are having the same
> problem with version_compare() that I was running into:
>
> http://us2.php.net/version_compare
>
> Look
On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov wrote:
> Hi internals!
>
> In the last few days I've created a proof of concept implementation
> for generators in PHP. It's not yet complete, but the basic
> functionality is there:
> https://github.com/nikic/php-src/tree/addGeneratorsSupport
>
> The i
On Fri, Jul 20, 2012 at 1:09 PM, Rick WIdmer wrote:
> On 7/20/2012 7:51 AM, Léo Peltier wrote:
>>
>>
>> Enforcing coding style should be forbidden.
>
>
> YES!! I just thought that needed to be repeated!
>
>
>
> On Fri, Jul 20, 2012 at 3:51 PM, Léo Peltier
> wrote:
>>
>>
>> Clearly you don't wo
On 7/20/2012 7:51 AM, Léo Peltier wrote:
>
Enforcing coding style should be forbidden.
YES!! I just thought that needed to be repeated!
On Fri, Jul 20, 2012 at 3:51 PM, Léo Peltier
wrote:
Clearly you don't work in a team or contribute to Open Source projects.
That's what coding styles
Hi!
>since I proposed last year, and seems no argu here.
>
>so maybe we can just step into the voting phase?
I'd like to know how it works with references. I.e., you can do:
foreach($foo as &$bar)
What about the list, how would you use that?
Also, I'm not sure which use case we're so
Hi!
> support. At least as far as I can tell, people are really interested
> in having named parameters, but would rather not have parameter
> skipping as implemented.
Which people? So far I've got only one person objecting - namely Gustavo
- and he's OK with it with my changes as far as I can se
Hi!
>> I've run into problems with brace-less blocks many, many times over
>> the years. Clearly, enough other people have as well that any serious
>> coding standard includes a clause requiring that all blocks use
>> braces. I see no reason to add another context in which braces could
>> be omitt
On Thu, Jul 19, 2012 at 2:14 PM, Rasmus Lerdorf wrote:
> The goal of this message is to encourage and motivate a few people to
> give me a hand with tracking down APC bugs. There are still a few
> outstanding bugs that is slowing PHP 5.4 adoption and it would be really
> nice to plow through these
On Thu, Jul 19, 2012 at 2:49 PM, Sara Golemon wrote:
> Same as you would in PHP code. Make an IS_STRING pointing at a global
> function, or IS_ARRAY pointing at a class method, or an IS_OBJECT supporting
> __invoke(). If you're asking how you can call a C function directly via
> this callback: Y
Matthew Weier O'Phinney wrote:
I've run into problems with brace-less blocks many, many times over
the years. Clearly, enough other people have as well that any serious
coding standard includes a clause requiring that all blocks use
braces. I see no reason to add another context in which braces c
On Fri, Jul 20, 2012 at 3:51 PM, Léo Peltier wrote:
>
> Enforcing coding style should be forbidden.
>
Clearly you don't work in a team or contribute to Open Source projects.
That's what coding styles are for, keeping code looking the same to make
readability easier for not-you developers.
--
On 2012-07-19, "Ivan Enderlin @ Hoa" wrote:
> As you certainly know, brackets defining blocks in PHP are optional if
> blocks contain a single instruction. Thus:
>
> if($condition) {
> echo 'foobar';
> }
>
> is strictly equivalent to:
>
> if($condition)
> echo 'foobar';
>
> But this syntactic sug
2012/7/20 Alex Aulbach
> PS: And if without brackets should be forbidden.
>
If I wanted a coding style-constrained language, I would use Python.
It is absolutely related to how the PHP project approaches things.
As a project we have always valued backwards compatibility and migration path.
That focus and approach is one of the reasons why PHP is so pervasive. It is
sometimes more fun to break (fix) everything but the reality is that while
On 20/07/12 15:32, Alex Aulbach wrote:
Hi Ivan,
try
throw new Exception('foobar');
catch(Exception $e)
var_dump($e->getMessage());
If you use try/catch that much, that you begin to think about the
syntax, you have an architecture- or design-problem.
Not sure about that. First, it was an exampl
> If you use try/catch that much, that you begin to think about the
> syntax, you have an architecture- or design-problem.
"Easier to ask for forgiveness than permission."
That's one thing I like about python: exceptions everywhere. Much cleaner than
having to use empty/isset/*_exists all the ti
Hi Ivan,
> try
> throw new Exception('foobar');
> catch(Exception $e)
> var_dump($e->getMessage());
If you use try/catch that much, that you begin to think about the
syntax, you have an architecture- or design-problem.
PS: And if without brackets should be forbidden.
--
Alex Aulbach
--
PHP I
According to Rasmus' recent talk, a large part of PHP success came from its
focus on web ecosystem, on what hosting ISPs are effectively needing.
http://talks.php.net/show/supepi/6 (but it's better when you hear Rasmus
telling it)
2012/7/20 Andrew Faulds
> Whilst I feel some sympathy for you, I
Andrew Faulds wrote:
Whilst I feel some sympathy for you, I must ask if it is really the PHP project
to blame if your hosts use old PHP versions?
Personally I'm fixing the problem and moving everything to my own machines, but
my point is not the personal one ... when ISP's do get around to upd
>From the comments in the documentation, it seems others are having the same
problem with version_compare() that I was running into:
http://us2.php.net/version_compare
Look at all those code-samples and "extensions" to the function - I found
it very odd that the documentation does not explain how
Whilst I feel some sympathy for you, I must ask if it is really the PHP
project to blame if your hosts use old PHP versions?
On Jul 20, 2012 12:50 PM, "Lester Caine" wrote:
> Daniel Macedo wrote:
>
>> >One little change in PHP5.3.10 or so wiped out a whole block of mine, and
>>> >the fix involved
Andrew Faulds wrote:
Exactly. Much of my focus is making PHP more consistent and logical, and hence
easier to learn. It would be nice if PHP was as easy as Python, someday. (for
example)
Python easy? I'm HAVING to fix python code as well these days, if it was any
good I might be tempted to mov
Daniel Macedo wrote:
>One little change in PHP5.3.10 or so wiped out a whole block of mine, and
>the fix involved a re-writing all the because the ISP would not switch back on short tag.
Did you really go through all code manually to change the short tags?
You should be smarter than that:
https:
Exactly. Much of my focus is making PHP more consistent and logical, and
hence easier to learn. It would be nice if PHP was as easy as Python,
someday. (for example)
On Jul 20, 2012 10:57 AM, "Rafael Dohms" wrote:
> On Fri, Jul 20, 2012 at 10:33 AM, Lester Caine wrote:
>
> >
> > And still seems
On 07/20/2012 11:37 AM, Ivan P @ Hoa wrote:
> On 20/07/12 11:28, Lester Caine wrote:
>> Ivan Enderlin @ Hoa wrote:
>>> Finally, I would like to clarify my proposal: I just wanted to
>>> discuss about
>>> making try/catch braces optional and not criticize PHP syntax…
I don't see how making somethin
On Thu, Jul 19, 2012 at 1:39 PM, Lester Caine wrote:
> One little change in PHP5.3.10 or so wiped out a whole block of mine, and
> the fix involved a re-writing all the because the ISP would not switch back on short tag.
Did you really go through all code manually to change the short tags?
You
On Fri, 13 Jul 2012, Stas Malyshev wrote:
> > Has the requirement for a truly clean unicode version of PHP
> > actually gone away?
>
> The requirement hasn't, but nobody is willing to lead the task. And
> it's not an easy one. IMHO variable names are by far the least
> important part of it - I
On Fri, Jul 20, 2012 at 10:33 AM, Lester Caine wrote:
>
> And still seems to be the best way even to 'investigate' this? I still
> have not had any explanation of what is wrong with ArrayObject? Certainly
> any changes need to be mirrored identically in that anyway?
>
> Also perhaps I am just too
On 20.07.2012, at 12:33, Ivan Enderlin @ Hoa wrote:
> Making braces optional for try/catch does:
> + not break backward compatibility;
> + add consistency in the PHP syntax;
> ± offer a new way to write buggy programs but no more than with other control
> structures (think about goto ;-)).
>
>
Hello internals!
After reading the discussion for some time and thinking through what has
been written, I came to the conclusion that something like legacy namespace
witch is enabled by default is required. Why? Because some projects are big
and you usually migrate them in chunks. So that way you
On 20/07/12 11:28, Lester Caine wrote:
Ivan Enderlin @ Hoa wrote:
Finally, I would like to clarify my proposal: I just wanted to
discuss about
making try/catch braces optional and not criticize PHP syntax…
The problem here is rather, could we make brackets compulsory
everywhere? No because o
Ivan Enderlin @ Hoa wrote:
Finally, I would like to clarify my proposal: I just wanted to discuss about
making try/catch braces optional and not criticize PHP syntax…
The problem here is rather, could we make brackets compulsory everywhere? No
because of BC problems, but this might be the pref
Anthony, the whole concept is interesting. Can you probably write that as RFC.
I believe that will make it easier to read/understand it.
Right now, I have only one question:
On 20.07.2012, at 4:33, Anthony Ferrara wrote:
> The benefit here, is that user types can implement the same "core" inter
On 20.07.2012, at 4:09, Stas Malyshev wrote:
> Hi!
>
>> 2. It would be really useful to have 2 versions of each function: one
>> which mutates the variable and one which returns the new variable.
>>
>> Example:
>>
>> > 'source', $src == 'SoUrCe' $result = lower($srd); // $result ==
>> true,
On Thu, Jul 19, 2012 at 8:14 PM, Rasmus Lerdorf wrote:
> The goal of this message is to encourage and motivate a few people to
> give me a hand with tracking down APC bugs. There are still a few
> outstanding bugs that is slowing PHP 5.4 adoption and it would be really
> nice to plow through these
Sara Golemon wrote:
I'm not saying
that any of this is difficult to do, I'm asking if it actually gains us
anything which justifies doubling the number of implementations which deal
with string, array, and scalar operation.
Given that you can accomplish this with a PECL extension, my answer is "
Hi all,
After a day and a quite lot of (hot) answers, we can state that making
try/catch braces optional has a weak probability to appear in PHP. But…
This discussion shows a leak of consistency in the PHP syntax regarding
braces. Language constructions (restricted to control structures) such
I don't think we should add it purely for consistency, because then we'd
have to allow nonsense like:
switch x;
case 1;
endcase;
endswitch;
or...
try;
x;
catch e;
endtry;
Sure, consistency is good, but this would allow sloppy code.
On Jul 20, 2012 8:36 AM, "Amaury Bouchard" wrote:
> 2012/7/19
As you suggested initially. Don't make them objects. You can leave them
scalars and still give them methods all from an extension. Not via typical
APIs, granted, but the engine hooks are all in there.
On Thu, Jul 19, 2012 at 4:38 PM, Andrew Faulds wrote:
> I'm curious, how do I make my objects
Hi:
since I proposed last year, and seems no argu here.
so maybe we can just step into the voting phase?
thanks
On Wed, Jul 18, 2012 at 10:55 PM, Laruence wrote:
> On Wed, Jul 18, 2012 at 10:49 PM, Laruence wrote:
>> Hi:
>> this is not a new RFC, I proposed it before, but due to
2012/7/19 Reeze
> 在 2012年7月19日星期四，下午6:45，Rune Kaagaard 写道：
>
> > +1 for the consistency of it. It's surprising that:
> >
> > if ($foo)
> > return $bar;
> > else
> > return 42;
> >
> > works and:
> >
> > try
> > maybe_dangerous();
> > catch(Dynamite $e)
> > handle_error();
> >
> >
>
> Ther
On Fri, Jul 20, 2012 at 2:07 AM, Stas Malyshev wrote:
> I was just thinking - since we have basically no code relying on this,
> why introduce rather artificial concept of "null means no parameter"
> (which I'm sure won't work in all cases and won't be expected in all
> cases) if we can have perfe
62 matches
Mail list logo
