-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 20.07.2012 02:09, schrieb Stas Malyshev:
> 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.
>>
Hello Anatoly,
I've just downloaded 5.4.5 and initially it seemed to be working. But after
I clicked here and there and ... it started to crash again.
I suspect that it is all about accumulating memory errors because initially
it used to work but then it stopped. Also, in CLI mode,
it is more diffi
Hi!
> And just to clear, I agree with Sara that ! (both for l/d/b and the
> pointer types) should not be redefined to "parameter was passed". But it's
> my understanding that that's not what you're planning.
I didn't have yet a good generic way to handle l/d/b with 'default' - in
many cases f
On 20/07/12 09:38, Andrew Faulds wrote:
> I'm curious, how do I make my objects have scalar passing semantics, then?
> On Jul 20, 2012 12:35 AM, "Sara Golemon" wrote:
>
How about this?
class String {
protected $string='';
public function __construct($string){
$this->string =
Hey all,
So I've been thinking about this for a while. Here's what I've come up with:
1. We want to maintain loose typing, so implementing a different API on
string than on int types would be bad.
2. We want to retain backwards compatibility to some extent with the legacy
API.
3. We want the ab
Em Fri, 20 Jul 2012 02:07:31 +0200, Stas Malyshev
escreveu:
Default parameters and unpassed parameters enter the scene because it's
idiomatic to pass NULL to have the same effect as not passing that
parameter.
Actually, as it never worked with int parameters, I'd not really call it
idiomati
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, $src = 'source' ?>
>
I'm not sure I understand why. What
Hi!
> Default parameters and unpassed parameters enter the scene because it's
> idiomatic to pass NULL to have the same effect as not passing that
> parameter.
Actually, as it never worked with int parameters, I'd not really call it
idiomatic just yet.
I was just thinking - since we have bas
Em Fri, 20 Jul 2012 00:20:49 +0200, Sara Golemon
escreveu:
Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC. Rather,
introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two se
I'm curious, how do I make my objects have scalar passing semantics, then?
On Jul 20, 2012 12:35 AM, "Sara Golemon" wrote:
>
>
> On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds wrote:
>
>> I never said treat them as objects. I said give them methods. Not the
>> same thing.
>>
> Fair enough, noone
On Thu, Jul 19, 2012 at 2:42 PM, Andrew Faulds wrote:
> I never said treat them as objects. I said give them methods. Not the same
> thing.
>
Fair enough, noone is talking about giving them properties or formal class
definitions.
> And what do you mean by "technical debt"?
>
I mean that we'll nev
On Fri, Jul 20, 2012 at 12:20 AM, Sara Golemon wrote:
> Okay, well... the main pieces of feedback I'd give on it then is to not
> change the behavior of the '!' modifier. That's bad BC.
The behavior for pointer-params isn't changed. Only non-pointer params
will then accept the additional is_null
Okay, well... the main pieces of feedback I'd give on it then is to not
change the behavior of the '!' modifier. That's bad BC. Rather, introduce
a new modifier for checking if a parameter was passed. Secondly, make
these two separate patches as the new modifier is a separate feature from
the si
Hello!
The PHP Development Team announces the immediate availability of PHP
5.4.5 and PHP 5.3.15. The releases fixes a security issue in the stream
implementation and over 30 bugs.
All users are adviced to update to PHP 5.3.15 or PHP 5.4.5!
PHP 5.4.5:
Release Announcement: http://www.php.ne
Ah, thanks. My mobile internet is horribly slow: But somehow Gmail works
pretty fast (constant connection??). Hence not Googling first.
On Jul 19, 2012 10:44 PM, "Kalle Sommer Nielsen" wrote:
> 2012/7/19 Andrew Faulds :
> > Forgive my ignorance, what is APC?
>
> Alternative PHP Cache
>
> http://p
2012/7/19 Andrew Faulds :
> Forgive my ignorance, what is APC?
Alternative PHP Cache
http://pecl.php.net/apc
http://php.net/apc
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I never said treat them as objects. I said give them methods. Not the same
thing.
And what do you mean by "technical debt"?
On Jul 19, 2012 9:52 PM, "Sara Golemon" wrote:
>
>
> On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds wrote:
>
>> I think PHP could benefit from making arrays, strings, integ
Forgive my ignorance, what is APC?
On Jul 19, 2012 7:15 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 reall
Hi!
> This solves two problems:
>
> a) Integer parameters cannot currently be skipped using NULL. This
> issue comes up every now and then. E.g. see
> https://github.com/php/php-src/pull/133.
Again, I think param skipping RFC addresses this better, but having some
way to see if param was supplie
On Thu, Jul 19, 2012 at 11:23 PM, Sara Golemon wrote:
> Then I'm not sure what problem you're trying to solve either. :/
This solves two problems:
a) Integer parameters cannot currently be skipped using NULL. This
issue comes up every now and then. E.g. see
https://github.com/php/php-src/pull/13
Then I'm not sure what problem you're trying to solve either. :/
On Thu, Jul 19, 2012 at 12:08 PM, Gustavo Lopes wrote:
> Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon
> escreveu:
>
>
> For this type of situation, you could equally go with something like:
>>
>> zval *val;
>> if (zend_parse_p
On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds wrote:
> I think PHP could benefit from making arrays, strings, integers,
> floats, and possibly booleans, into "pseudo-objects". By this I mean
> that they are not really objects (they are still primitive types and
> keep their passing semantics), bu
On 7/19/12 1:17 AM, Ronald Chmara wrote:
With PHP 6, lets start with a:
Pure
Object
Oriented
PHP
OMG, did you seriously just recommend POOP? LOL, I'm gonna go die now.
-- Dante
D. Dante Lorenso
da...@lorenso.com
972-333-4139
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
Hi Marion,
not sure what's not working for you, the test
Zend/tests/traits/bug61998.phpt passes for me on windows master. Could you
supply a piece of code for that?
Regards
Anatoliy
Am Mi, 18.07.2012, 08:12 schrieb Marian Kostadinov:
> Hello Anatoliy,
> I've just tried latest and greatest from
On Thu, Jul 19, 2012 at 8:17 PM, Sara Golemon wrote:
> Did the voting close already? One day seems awfully short. :(
Laruence closed the vote because he wanted to add aliasing of
arbitrary expressions instead of just variables.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To
Em Thu, 19 Jul 2012 20:36:45 +0200, Sara Golemon
escreveu:
For this type of situation, you could equally go with something like:
zval *val;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "n", &val) ==
FAILURE)
{ RETURN_NULL(); }
Where the 'n' type looks for a numeric value: IS_LONG
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: You can't. You can can, however, make an
internal method to us
For this type of situation, you could equally go with something like:
zval *val;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "n", &val) == FAILURE)
{ RETURN_NULL(); }
Where the 'n' type looks for a numeric value: IS_LONG/IS_DOUBLE kept as is,
IS_STRING/IS_OBJECT (with toString() behavior
On Thu, Jul 19, 2012 at 11:16 AM, Ronald Chmara wrote:
> On Thu, Jul 19, 2012 at 11:09 AM, Kris Craig wrote:
> > I get that the first two acronyms are POOP and SHIT; however, the third
> one,
> > HARAH, is throwing me off. Is that a fecal reference in some other
> language
> > or something?
>
>
For all the reasons already stated, most explicitly because it make the
code ugly as sin, my vote is somewhere between "No", and "Hell No."
-1 on bracketless try/catch
On Thu, Jul 19, 2012 at 2:44 AM, Ivan Enderlin @ Hoa <
ivan.ender...@hoa-project.net> wrote:
> Hi internals,
>
> As you certain
Did the voting close already? One day seems awfully short. :(
On Wed, Jul 18, 2012 at 7:54 AM, Laruence 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.
>
> thanks
>
> --
> Laruence
On Thu, Jul 19, 2012 at 11:09 AM, Kris Craig wrote:
> I get that the first two acronyms are POOP and SHIT; however, the third one,
> HARAH, is throwing me off. Is that a fecal reference in some other language
> or something?
http://www.youswear.com/index.asp?language=Hebrew
I thought about maki
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 instead of wasting cycles on some of the
other discussions goin
On Thu, Jul 19, 2012 at 4:40 AM, Andrew Faulds wrote:
> Our syntax is very, very confusing for newbies. Also, procedural and OOP
> programming is unnatural and unintuitive. We should use the natural LISP
> braces syntax and make PHP functional, so it is much easier to write, e.g.:
>
> ((decl (main
On Thu, Jul 19, 2012 at 7:35 AM, Lonny Kapelushnik wrote:
> Hi,
>
> I found a problem in the PHP WIki. On IRC it was suggested that I open a
> bug report (#62611) and email internals.
>
> https://wiki.php.net/vcs/gitworkflow has wrong directions for 'Workflow
> for
> external contributors'.
>
> A
Hi!
> So we should better begin to see where are the technical bottlenecks
> and figure out a way to solve them instead of arguing about whether we
> should do it or not. Because we will have to do it, whether we like it
> or not.
No, that's exactly WRONG way to do things. We should first know if
wat
The pseudo- prefix means something. These scalar and array vars are
unchanged. The methods are implemented via an engine shortcut, not by
making them objects.
On Jul 19, 2012 6:24 PM, "Lester Caine" wrote:
> Pierre Joye wrote:
>>
>> should still work. All the string API metho
Pierre Joye wrote:
should still work. All the string API methods need to be available
on
>every pseudo-object regardless of the type. So I don't see any
"cleanup"
>here either.
I do, and again this is purely a theoretical discussion
PHP is all about backwards compatibility.
We only break things that need to be broken. The legacy
str*/str_*/string_*/array_* functions will still work.
On Jul 19, 2012 5:36 PM, "Lester Caine" wrote:
> Pierre Joye wrote:
>
>> should still work. All the string API methods need to be available on
Pierre Joye wrote:
should still work. All the string API methods need to be available on
>every pseudo-object regardless of the type. So I don't see any "cleanup"
>here either.
I do, and again this is purely a theoretical discussion right now.
However I find disturbing the resistance to such a p
HTML5 allow omitting head, body, html (they had no fundamental differences
in parsing IRL), and also quotes and some end tags. Makes for much, much
nicer HTML, e.g.:
hello
hi
item 1
item 2
...that's off-topic though. I don't think we should have more tolerance of
omitted braces in PH
We can have more consistent naming, at least.
I like this idea even more now, it means we could have a set of universal
operations:
$bool->negate(); // true -> false
$num->negate(); // 7 -> -7
$numericString->negate(); // "123" -> -123
$float->negate(); // 3.141592 -> -3.141592
$customVectorType-
On Thu, Jul 19, 2012 at 5:49 PM, Rasmus Lerdorf wrote:
> should still work. All the string API methods need to be available on
> every pseudo-object regardless of the type. So I don't see any "cleanup"
> here either.
I do, and again this is purely a theoretical discussion right now.
However I fi
There is no such thing as an optional closing tag or brace. There's
only lazy and sloppy coders, and parsers that encourage them.
--Larry Garfield
On 7/19/12 10:52 AM, Andrew Faulds wrote:
Always close , but never close :)
On Jul 19, 2012 4:44 PM, "Larry Garfield" wrote:
On 7/19/12 5:11 A
Always close , but never close :)
On Jul 19, 2012 4:44 PM, "Larry Garfield" wrote:
> On 7/19/12 5:11 AM, Peter Beverloo wrote:
>
> I have seen this problem happen, people losing time trying to figure out
>>> what is wrong only to find
>>> its a missing bracket.
>>> As Paul said, this is bug-pro
On 07/19/2012 12:25 AM, Pierre Joye wrote:
> hi Rasmus,
>
> On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf wrote:
>
>> This makes no sense to me either. How does it let us clean the APIs? Can
>> you give an example? I have one:
>>
>> $a = -5;
>> $b = "-5";
>>
>> echo $a->abs(); // Outputs 5
>>
I like this idea, but I think it should be visible by default, and hidden
by using a special namespace import like "use NOLEGACY" or something.
On Jul 19, 2012 3:21 PM, "Michael Morris" wrote:
> I want to clarify what I mean when I state that the existing API
> should move to a legacy namespace.
On Wed, Jul 18, 2012 at 11:43 PM, Galen Wright-Watson
wrote:
> I'd like to see some version of the null-coalescing ternary operator
> (recently brought up in a thread started by Rafael Dohms) make it into PHP.
> To help it along, may I have RFC karma so I can draft a proposal? My PHP
> wiki accoun
On 7/19/12 5:11 AM, Peter Beverloo wrote:
I have seen this problem happen, people losing time trying to figure out
what is wrong only to find
its a missing bracket.
As Paul said, this is bug-prone.
Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP sup
On 18/07/12 17:19, Leigh wrote:
I missed the discussion on this one, the RFC examples are very simple. Does
it support aliasing array indices?
I have missed the discussion two.
I can't vote but I don't feel confortable with this new notation.
Wouldn't be better to make the “=” operator availab
Hi,
I found a problem in the PHP WIki. On IRC it was suggested that I open a
bug report (#62611) and email internals.
https://wiki.php.net/vcs/gitworkflow has wrong directions for 'Workflow for
external contributors'.
After `git remote...` you need to call `git fetch upstream` and the
rebase nee
Probably not so much in PHP but I've had some real doozers in my time due this.
For example in C...
if (somethingsFailed)
DEBUG_MACRO("Something failed!");
var = 1;
And then someone un-defines DEBUG_MACRO.
Fun then ensues.
Melanie
On 19 Jul 2012, at 11:03, Charlie Somerville wrote:
I want to clarify what I mean when I state that the existing API
should move to a legacy namespace.
First, the only reason to do this is if you want to change the
behavior of functions to make them consistent. For example, Is it
haystack, needle or needle, haystack? Second, how namespaces resolve
Laruence,
On Wed, Jul 18, 2012 at 9:53 PM, Laruence wrote:
> Hi:
> I saw you two vote against for this RFC.
>
> could you explain why? then maybe I can improve it.
>
> thanks
The reason that I voted against it is simple. It's sugar to make it harder
to understand what the code is doin
Sebastian Krebs wrote:
Of course it's a matter of code style [1], but one can write the ugliest
code with every syntax. This argument about "bug-prone" often confuses me,
because I for myself never had such a problem. I also never knew someone,
who had a problem with bracket-less blocks (but must
2012/7/19 Rafael Dohms
> On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
> char...@charliesomerville.com> wrote:
>
> > This has code readability problem written all over it. When maintaining
> it
> > also has problems, like with the bracket-less if's.
> > You would need to add brackets if
This reminds me of
$var = something or die();
So if you do follow with braceless-try, I would have
try something() catch($e) do_something_with($e);
Or (a bit simpler, but assumes we have a new pseudovariable $e),
try something() or do_something_with($e)
I don't like the form with a semi
+1
There's a reason that web browser APIs have so much cruft (user-agent
string, yuck), and there's a reason for ECMAScript 5's "use strict" instead
of "use legacy". Old code should work without changing it. Otherwise a lot
of things break which take a lot of time to fix, and even worse, devs can
Daniel Macedo wrote:
What I was stating is that: IF you want to keep the old way of doing
things around instead of removing them, it should be "change
settings/tag/whatever so it work as the old way" and not "change it so
it works the new way", that was my only point.
Obviously you don't suppor
Peter Beverloo wrote:
Other bracket-less blocks allow authors to shoot themselves in the foot
equally so, yet PHP supports these as well. The actual problem here is an
inconsistency in the parser, which I'd consider to be a bug.
Having been caught out too many times now when adding an extra par
Right, because I've never got them the wrong way round, that is completely
logical, and this syntax makes it much harder.
On Jul 19, 2012 1:17 AM, "Rasmus Lerdorf" wrote:
> On 07/18/2012 05:10 PM, David Muir wrote:
> > On 19/07/12 04:49, Rasmus Lerdorf wrote:
> >> On 07/18/2012 01:02 AM, Pierre J
One consideration: Should be a general array/string/int/float/bool API. PHP
is weakly typed: therefore, say, reverse() would reverse a string OR an
array. negate() would invert a bool, negate an int/float. slice() would
slice a section of a string OR an array. max() would find maximum of an
array,
Our syntax is very, very confusing for newbies. Also, procedural and OOP
programming is unnatural and unintuitive. We should use the natural LISP
braces syntax and make PHP functional, so it is much easier to write, e.g.:
((decl (main (echo (add (reverse (array (1 2 3))) (string ('h 'e 'l 'l 'o
'\
Hi，
在 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();
>
>
There is no condition after `try`, it's really har
+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();
does not.
On Thu, Jul 19, 2012 at 12:11 PM, Peter Beverloo wrote:
> On Thu, Jul 19, 2
On Thu, Jul 19, 2012 at 11:06 AM, Rafael Dohms wrote:
> On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
> char...@charliesomerville.com> wrote:
>
> > This has code readability problem written all over it. When maintaining
> it
> > also has problems, like with the bracket-less if's.
> > You
On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville <
char...@charliesomerville.com> wrote:
> This has code readability problem written all over it. When maintaining it
> also has problems, like with the bracket-less if's.
> You would need to add brackets if you add an extra line here, as well as
On Thu, Jul 19, 2012 at 11:58 AM, Charlie Somerville <
char...@charliesomerville.com> wrote:
>
> On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
>
> > Why is your try block only going to contain 1 line, and that's
> > throwing an exception??
> >
> > try
> > throw new Exception('foobar'
> This has code readability problem written all over it. When maintaining it
> also has problems, like with the bracket-less if's.
> You would need to add brackets if you add an extra line here, as well as
> you might get unexpected behaviour of you forget to
> add brackets in that case.
>
>
Hi,
2012/7/19 Paul Dragoonis
> Why is your try block only going to contain 1 line, and that's
> throwing an exception??
>
> try
> throw new Exception('foobar');
> catch(Exception $e)
>
>
> Braces are a good thing, they give structure and stop people from
> mis-reading things and writing bugs, th
On Thu, Jul 19, 2012 at 10:58 AM, Charlie Somerville
wrote:
> On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
>
> Why is your try block only going to contain 1 line, and that's
> throwing an exception??
>
> try
> throw new Exception('foobar');
> catch(Exception $e)
>
> Because it's a c
On Thu, Jul 19, 2012 at 11:44 AM, Ivan Enderlin @ Hoa <
ivan.ender...@hoa-project.net> wrote:
> Hi internals,
>
> 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
On Thursday, 19 July 2012 at 7:49 PM, Paul Dragoonis wrote:
> Why is your try block only going to contain 1 line, and that's
> throwing an exception??
>
> try
> throw new Exception('foobar');
> catch(Exception $e)
>
>
Because it's a contrived example. He's not trying to write real code, he
On 19.07.2012, at 13:49, Paul Dragoonis wrote:
> 2) Try with only one line in it to throw an exception doesn't seem
> like a realistic situation.
It could be something like this:
try
$object->method();
catch (\Exception $e)
return false;
and ->method(), obviously, can have quite a long and co
Why is your try block only going to contain 1 line, and that's
throwing an exception??
try
throw new Exception('foobar');
catch(Exception $e)
Braces are a good thing, they give structure and stop people from
mis-reading things and writing bugs, the same can be said for the if()
situation.
1) Br
Hi internals,
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 sugar is not applied uniformly to all PHP language
c
Hi Nikita,
that's exactly the subject I've tripped over trying to fix (apparently
wrong) the issue #62477. The ticket is about LimitIterator accepting only
long for start and offset, but being able to accept an Iterator from
userland accepting floats for positions.
For instance, the snippet like
Now that we have Traits, lets bring in Aspects too!
http://en.wikipedia.org/wiki/Aspect-oriented_programming
Also, PHP is not necessarily evil by allowing non-OO code, but maybe we
could do better at the non-OO code side of things by adding prototyped
inheritance in a javascript-ish spirit to at l
Stas made a good point about need to start with new API, which then can be
followed by syntactic sugar.
So, we need some ideas to start with:
1. A lot of people told, that it would be a good idea to come with a written
standard regarding arguments order. I don't care what it will be, as long as
hi Rasmus,
On Wed, Jul 18, 2012 at 8:49 PM, Rasmus Lerdorf wrote:
> This makes no sense to me either. How does it let us clean the APIs? Can
> you give an example? I have one:
>
> $a = -5;
> $b = "-5";
>
> echo $a->abs(); // Outputs 5
> echo $b->abs(); // should still output 5
>
> What has bee
80 matches
Mail list logo
