Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 2/27/2012 6:58 AM, jpauli wrote: PHP through mod_php on Linux should compile without ZTS. configure script searches for apxs binary and tries to invoque apxs -q MPM to figure out what MPM has been compiled in Apache for the TS flag to be defined or not (thus, activating PHP ZTS, or not). Right... Mainly on Linux, Apache should have been installed with prefork MPM ans apxs -q should return that, then configure should not define PHP_BUILD_THREAD_SAFE. No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux distros have moved away from it... Sorry but 2.2 defaults to prefork. The new 2.4 platform has introduced loadable MPM, like any other module , thus we cant detect through apxs which MPM is used anymore. For this, we would need to play with httpd -M Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). The only mod_php loadable under any circumstance is TS enabled. Yes, but ZTS has a performance/memory penalty due to globals locks. I would much prefer having a nonZTS PHP together with a non threaded MPM Julien.P If you want php/linux single-child, fastcgi is the only rational approach. I dont know anything about windows, sorry Always threaded. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Aren't you people getting tired of saying that arguments like it's not the PHP way or that does not fit the PHP paradigm are invalid. Are you even aware, that language is not only about the features, but is also about the paradigm, syntax, philosophy and methods of how it achieves it's goals? It's not as simple as nah, lets add feature X, it looks weird and alien, but who cares as long as it's cool!. On the terminology - strict is strict, weak is weak. Writing a statement at the start of the thread and adding a few new words will make no difference. Because half the people will just skip it, or didn't read carefully because it's not interesting and so on. Some people on the list just assume that we are perfect beings and read every line of what's written on the list (hell, I skim the text and read only the important things. I have ~15 threads active in my mailbox (only the internals, not counting other mail) and reading each of it carefully will just take too long). Besides that - a scripting language is much easier to learn, use it and learn it. Things like strict typing, strict type hinting and so on are not as trivial to understand and learn unless you start with a strict typed compiled language. When you deal with the script language and loose variable typing you get used to being able to convert types on the fly. And imagine the shock when you start using some strict typed library and now you have to convert all your variables explicitly. And now the code looks just like C/C++/Java/Delphi code - type conversion statements all over the place. I sure don't want such code. And not because it is hard to combine (or impossible) weak and strict type hinting - that just does not suit a scripting language created with loose/weak typing in the first place. And adding such things will not improve the code - it will mess it up big time. I don't know about you, but I have seen and worked with folks who did some really weird things in PHP. An instrument like strict type hinting will just give them the ability to write code that is plain stupid. It will be just like OOP for the sake of OOP. Too many people do not understand the philosophy behind the PHP and they build over complex things and complain that they had to become inventive to be able to do implement something from the C++/Java/Python/Ruby world. And they complain that PHP is a bad language, but still eat the cactus. I wonder why? I really liked what the O'Raily wrote here: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html I know, some things are a little over the top, but in general it describes the best PHP feature - it's easy to work with, it's easy to make something without using any frameworks, libraries and just do the work you need for the WEB. And I think it should stay that way. And I personally like it that way. And it's because of that I don't want to migrate to Ryby or Python. Adding strict type hinting will ruin it because I know for a fact that there are plenty of programmers who will turn their API's into strict typed all over the place. And I will have to select my data from the database and go through the records and explicitly convert all my data to the correct types so I can use that wonderful library whose author is a fond of strict typing. I see such things with OOP right now in many places - they ask you for an object, but I know it just really needs a string with the data to do the work. Many people migrate to PHP from different languages, and mostly those are strictly typed compile languages (I actually had teached PHP for 2 years at the private school of web technologies - I saw many people learning PHP after Java, C++, Delphi, even assembler). It's not the problem that will become a problem in a year or two - it will become so in 5-7 years. Just like register_globals, magic_quotes and things like that gave their evil effects in time. So please, take your time to think this through. The technical aspect is only part of the puzzle. As they say The road to hell is paved with good intentions. And adding strict and weak type hinting together is just plainly a very bad idea. It may be good for library and framework writers (but not all of them agree on that), but to the people using them it will be a headache. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On Tue, Feb 28, 2012 at 6:05 AM, Anthony Ferrara ircmax...@gmail.comwrote:
Ok, I've made a proof-of-concept patch here:
https://gist.github.com/1929587
Note that there are still a few memory leaks in there that would need
to be cleaned up, but I just wanted to make a really quick POC before
cleaning anything up to make it worthy of addition...
One could use zend_get_type_by_const() for help :)
Another patch would need to be made for the __castFrom($value)
implementation, but I think we'll split that off into another
topic/RFC since that's quite a bit more work than this is...
What are your thoughts?
Anyway... I like but the changes would really need some documentation.
And before that, we would need several RFC (one per concept seems to be a
good idea).
It adds 2 new magic methods: __castTo($type) and __assign($value):
__castTo($type) is called by the cast_object handler, and the get
handler. The cast_object handler will pass in the requested type as a
string (NULL, boolean, integer, double, string, array, object,
resource, callable). Note that it does not check the return type (yet
at least). The get handler will pass in native as $type. So that's
used by combination operators (+=, +=, etc).
__assign($value) is called by the set handler. This gets called
anytime the object is assigned to. To allow for conditional
assignment, if you return false from the handler, the value overwrites
the zval (to allow for destructing of the object and not overriding
assignment, if you want)...
So, with this script:
?php
class Foo {
public $value = 1;
}
class Bar {
public $value = 1;
public function __castTo($type) {
return $this-value;
}
public function __assign($value) {
$this-value = $value;
return $value != 10;
}
}
$a = new Foo;
$b = new Bar;
$a++;
var_dump($a); // int(1) - Normal type casting rules apply here.
$b++;
var_dump($b); // object, value = 2, increment captured
$a = new Foo;
$b = new Bar;
$a = 3;
$b = 3;
var_dump($a); // int(3) - Normal rules apply
var_dump($b); // object, value = 3, assignment captured
$a = new Foo;
$b = new Bar;
$a = 10;
$b = 10;
var_dump($a); // int(10) - Normal rules apply
var_dump($b); // int(10) - False was returned, so normal assignment happens
Now, for some casting:
$a = new Foo;
$b = new Bar;
$a-value = 100;
$b-value = 100;
var_dump((int) $a); // int(1) - Normal type casting rules apply
var_dump((int) $b); // int(100) - Cast was captured
$a = new Foo;
$b = new Bar;
$a-value = 2;
$b-value = 2;
var_dump(substr(test, $a)); // string(1) t
var_dump(substr(test, $b)); // string(1) te
Anthony
Sorry for repeating, but why not RFC that ?
Julien.P
On Mon, Feb 27, 2012 at 3:24 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Rich,
I appreciate the candid and honest nature of your reply, while
maintaining civility. This list needs more of that. Further replies
inline:
On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch c...@l-i-e.com wrote:
On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
I have to say that no matter how much a luv my OOP, turning every
built-in type into an Object is just a Bad Idea...
It's a form of bloat on RAM and CPU with minimal added value, imho.
Re-read what I had written. I never said to turn every built-in type
into an object. In fact, what I was talking about was keeping and
preserving the base types as-is. All that I was proposing was adding
the ability to cast from and to the primitives. That way you could
silently convert back and forth as needed (transparently when
possible).
I apologize that my brevity has been misconstrued.
You are certainly free, even with the tools available in PHP, to
wrap an object around integers, strings, and so on.
There may even be occasions where I think that would be a Good Idea
(tm).
Well, you can kind of do it now. You can't directly operate on those
objects. You need to first manually cast them back to the native
type. Take a look at SplFixedArray (
http://www.php.net/manual/en/class.splfixedarray.php ). It has a pair
of methods, a static fromArray(), and a instance toArray(). What I'm
talking about is adding the ability to push these conversions down to
the engine level.
What I object to is building such a facility into core PHP, because:
1) You can already do it in userland, and I believe that's where it
belongs.
Actually, almost exactly the opposite. You can't do it in userland,
but you can in a PECL extension (via cast_object(), get() and set()).
The first part of this proposal is basically just exposing those
methods (almost 1:1, only consolidating cast_object and get into a
single method with a parameter defining the difference).
2) It unnecessarily [see 1] complicates core PHP, whose major
strengths that drive its success includes its simplicity.
Actually, the first part
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
One could use zend_get_type_by_const() for help :)
I wasn't aware of that function, thanks! I based it off of gettype (
http://lxr.php.net/opengrok/xref/PHP_5_4/ext/standard/type.c#26 ).
I'll update the patch tonight.
And before that, we would need several RFC (one per concept seems to be a
good idea).
Well, considering they are tied together (at least __assign is useless
without the __castTo), wouldn't the two of them fall into the same
RFC?
And I'm planning on writing out an RFC for it. I just wanted to get
some comments and flush out the concept before writing an official
patch and RFC. That's why I made a POC patch, to investigate the
ramifications and prove it could be done before finalizing and
proposing exactly how it should work...
Thanks,
Anthony
On Tue, Feb 28, 2012 at 5:54 AM, jpauli jpa...@php.net wrote:
On Tue, Feb 28, 2012 at 6:05 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Ok, I've made a proof-of-concept patch here:
https://gist.github.com/1929587
Note that there are still a few memory leaks in there that would need
to be cleaned up, but I just wanted to make a really quick POC before
cleaning anything up to make it worthy of addition...
One could use zend_get_type_by_const() for help :)
Another patch would need to be made for the __castFrom($value)
implementation, but I think we'll split that off into another
topic/RFC since that's quite a bit more work than this is...
What are your thoughts?
Anyway... I like but the changes would really need some documentation.
And before that, we would need several RFC (one per concept seems to be a
good idea).
It adds 2 new magic methods: __castTo($type) and __assign($value):
__castTo($type) is called by the cast_object handler, and the get
handler. The cast_object handler will pass in the requested type as a
string (NULL, boolean, integer, double, string, array, object,
resource, callable). Note that it does not check the return type (yet
at least). The get handler will pass in native as $type. So that's
used by combination operators (+=, +=, etc).
__assign($value) is called by the set handler. This gets called
anytime the object is assigned to. To allow for conditional
assignment, if you return false from the handler, the value overwrites
the zval (to allow for destructing of the object and not overriding
assignment, if you want)...
So, with this script:
?php
class Foo {
public $value = 1;
}
class Bar {
public $value = 1;
public function __castTo($type) {
return $this-value;
}
public function __assign($value) {
$this-value = $value;
return $value != 10;
}
}
$a = new Foo;
$b = new Bar;
$a++;
var_dump($a); // int(1) - Normal type casting rules apply here.
$b++;
var_dump($b); // object, value = 2, increment captured
$a = new Foo;
$b = new Bar;
$a = 3;
$b = 3;
var_dump($a); // int(3) - Normal rules apply
var_dump($b); // object, value = 3, assignment captured
$a = new Foo;
$b = new Bar;
$a = 10;
$b = 10;
var_dump($a); // int(10) - Normal rules apply
var_dump($b); // int(10) - False was returned, so normal assignment
happens
Now, for some casting:
$a = new Foo;
$b = new Bar;
$a-value = 100;
$b-value = 100;
var_dump((int) $a); // int(1) - Normal type casting rules apply
var_dump((int) $b); // int(100) - Cast was captured
$a = new Foo;
$b = new Bar;
$a-value = 2;
$b-value = 2;
var_dump(substr(test, $a)); // string(1) t
var_dump(substr(test, $b)); // string(1) te
Anthony
Sorry for repeating, but why not RFC that ?
Julien.P
On Mon, Feb 27, 2012 at 3:24 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Rich,
I appreciate the candid and honest nature of your reply, while
maintaining civility. This list needs more of that. Further replies
inline:
On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch c...@l-i-e.com wrote:
On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
I have to say that no matter how much a luv my OOP, turning every
built-in type into an Object is just a Bad Idea...
It's a form of bloat on RAM and CPU with minimal added value, imho.
Re-read what I had written. I never said to turn every built-in type
into an object. In fact, what I was talking about was keeping and
preserving the base types as-is. All that I was proposing was adding
the ability to cast from and to the primitives. That way you could
silently convert back and forth as needed (transparently when
possible).
I apologize that my brevity has been misconstrued.
You are certainly free, even with the tools available in PHP, to
wrap an object around integers, strings, and so on.
There may even be occasions where I think that would be a Good Idea
(tm).
Well, you can kind of do it now. You can't directly operate on those
objects. You need to first manually cast them back to the native
type. Take a look at SplFixedArray (
[PHP-DEV] Possibility to add finally to try/catch?
This is another feature that we know we can live without but those familiar with languages that have 'finally' like Java or Python know that it is very neat feature to have in some situations. Basically the code inside 'finally' is guaranteed to run even if there is a 'return' inside try or catch blocks in which case the value to be returned is remembered tempraraly, the code inside finally block executes and then remembered value is returned. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
+1000
This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.
Basically the code inside 'finally' is guaranteed to run even if there is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.
+1000
On Tue, Feb 28, 2012 at 2:22 PM, Kiall Mac Innes ki...@managedit.ie wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.
Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
PHP needs a lot more memory than, say, serving static files. If you used PHP with the worker threaded MPM, and it worked (I haven't heard many stories of people doing this under Linux), wouldn't you just have to dial back the number of threads to pretty much the number of processes you would have allowed under the prefork MPM? The overhead of a process is pretty tiny next to the overhead of a PHP framework. Aren't you therefore just paying a performance and stability price (threadsafe is slower than non-threadsafe, your extensions may or may not play nice...) for not a lot of benefit under Linux when PHP runs under the worker threaded MPM? The best configuration I'm aware of is to run Apache with the worker threaded MPM, and run PHP in a fastcgi pool, so that you can have hundreds of threads serving static and cached content in a hurry, and a smaller pool of more expensive PHP processes. I'm interested to hear if anyone feels there is a superior model for single-server PHP hosting under Linux. (I realize that static files could be pushed out to CDNs and the like but our clients much prefer to have a single straightforward hosting bill to pay, thus the single-server thing for most cases.) On Tue, Feb 28, 2012 at 4:13 AM, jpauli jpa...@php.net wrote: On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 2/27/2012 6:58 AM, jpauli wrote: PHP through mod_php on Linux should compile without ZTS. configure script searches for apxs binary and tries to invoque apxs -q MPM to figure out what MPM has been compiled in Apache for the TS flag to be defined or not (thus, activating PHP ZTS, or not). Right... Mainly on Linux, Apache should have been installed with prefork MPM ans apxs -q should return that, then configure should not define PHP_BUILD_THREAD_SAFE. No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux distros have moved away from it... Sorry but 2.2 defaults to prefork. The new 2.4 platform has introduced loadable MPM, like any other module , thus we cant detect through apxs which MPM is used anymore. For this, we would need to play with httpd -M Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). The only mod_php loadable under any circumstance is TS enabled. Yes, but ZTS has a performance/memory penalty due to globals locks. I would much prefer having a nonZTS PHP together with a non threaded MPM Julien.P If you want php/linux single-child, fastcgi is the only rational approach. I dont know anything about windows, sorry Always threaded. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hello everyone, Let's stop the religious war between strongly and weekly typed languages. In software, there is no silver bullet. Both approaches have their benefits and their disadvantages, so trying to prove that one is better to the other leads to nowhere. Having said that, I don't think that PHP will any time soon become a strongly typed language. However, as there are indeed benefits to strongly typed languages, I see no reason to just close the door. I think it's high time that we separated the PHP *platform* from the PHP *language*. That will eventually lead to the creation of strongly typed languages that could be executed on the PHP platform. Just my two cents :-) Lazare INEPOLOGLOU Ingénieur Logiciel 2012/2/28 Arvids Godjuks arvids.godj...@gmail.com Aren't you people getting tired of saying that arguments like it's not the PHP way or that does not fit the PHP paradigm are invalid. Are you even aware, that language is not only about the features, but is also about the paradigm, syntax, philosophy and methods of how it achieves it's goals? It's not as simple as nah, lets add feature X, it looks weird and alien, but who cares as long as it's cool!. On the terminology - strict is strict, weak is weak. Writing a statement at the start of the thread and adding a few new words will make no difference. Because half the people will just skip it, or didn't read carefully because it's not interesting and so on. Some people on the list just assume that we are perfect beings and read every line of what's written on the list (hell, I skim the text and read only the important things. I have ~15 threads active in my mailbox (only the internals, not counting other mail) and reading each of it carefully will just take too long). Besides that - a scripting language is much easier to learn, use it and learn it. Things like strict typing, strict type hinting and so on are not as trivial to understand and learn unless you start with a strict typed compiled language. When you deal with the script language and loose variable typing you get used to being able to convert types on the fly. And imagine the shock when you start using some strict typed library and now you have to convert all your variables explicitly. And now the code looks just like C/C++/Java/Delphi code - type conversion statements all over the place. I sure don't want such code. And not because it is hard to combine (or impossible) weak and strict type hinting - that just does not suit a scripting language created with loose/weak typing in the first place. And adding such things will not improve the code - it will mess it up big time. I don't know about you, but I have seen and worked with folks who did some really weird things in PHP. An instrument like strict type hinting will just give them the ability to write code that is plain stupid. It will be just like OOP for the sake of OOP. Too many people do not understand the philosophy behind the PHP and they build over complex things and complain that they had to become inventive to be able to do implement something from the C++/Java/Python/Ruby world. And they complain that PHP is a bad language, but still eat the cactus. I wonder why? I really liked what the O'Raily wrote here: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html I know, some things are a little over the top, but in general it describes the best PHP feature - it's easy to work with, it's easy to make something without using any frameworks, libraries and just do the work you need for the WEB. And I think it should stay that way. And I personally like it that way. And it's because of that I don't want to migrate to Ryby or Python. Adding strict type hinting will ruin it because I know for a fact that there are plenty of programmers who will turn their API's into strict typed all over the place. And I will have to select my data from the database and go through the records and explicitly convert all my data to the correct types so I can use that wonderful library whose author is a fond of strict typing. I see such things with OOP right now in many places - they ask you for an object, but I know it just really needs a string with the data to do the work. Many people migrate to PHP from different languages, and mostly those are strictly typed compile languages (I actually had teached PHP for 2 years at the private school of web technologies - I saw many people learning PHP after Java, C++, Delphi, even assembler). It's not the problem that will become a problem in a year or two - it will become so in 5-7 years. Just like register_globals, magic_quotes and things like that gave their evil effects in time. So please, take your time to think this through. The technical aspect is only part of the puzzle. As they say The road to hell is paved with good intentions. And adding strict and weak type hinting together is just plainly a very bad
Re: [PHP-DEV] Possibility to add finally to try/catch?
Hi, Dmitri
Great that someone's mentioning it.
I thought about that several times but did not put it in here.
This is a must-have for me. Really useful if you're working with external
resources (streams, database connection etc).
I used a destructor until now for stuff like that but there are some
situations where a destructor won't be called.
http://stackoverflow.com/questions/2385047/when-will-destruct-not-be-called-in-php
Bye
Simon
2012/2/28 Paul Dragoonis dragoo...@gmail.com
Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.
+1000
On Tue, Feb 28, 2012 at 2:22 PM, Kiall Mac Innes ki...@managedit.ie
wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or
Python
know that
it is very neat feature to have in some situations.
Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the
code
inside finally block executes and then remembered value is returned.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux distros have moved away from it... Ubuntu starts out with the worker threaded MPM. However when you install the standard PHP package it switches Apache to the prefork MPM. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
On Tue, Feb 28, 2012 at 3:36 PM, Simon Schick simonsimc...@googlemail.comwrote: Hi, Dmitri Great that someone's mentioning it. I thought about that several times but did not put it in here. This is a must-have for me. Really useful if you're working with external resources (streams, database connection etc). I used a destructor until now for stuff like that but there are some situations where a destructor won't be called. http://stackoverflow.com/questions/2385047/when-will-destruct-not-be-called-in-php Bye Simon https://bugs.php.net/bug.php?id=36779 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Possibility to add finally to try/catch?
In many cases this can be done by refactoring to a method:
public function main()
{
$in = fopen('whatever');
$this-whereTheStuffWent($in);
fclose($in);
}
protected function whereTheStuffWent($in)
{
try {
// Do stuff that might throw an exception
} catch (Exception $e)
{
// Log it or something
}
}
The while loop case in https://bugs.php.net/bug.php?id=36779 could be
dealt with by returning a result from whereTheStuffWent and breaking
out if it's set. Not too bad. finally { } might be a little more
convenient than this I suppose:
$finished = $this-whereTheStuffWent($in);
fclose($in);
if ($finished)
{
break;
}
On Tue, Feb 28, 2012 at 9:25 AM, Paul Dragoonis dragoo...@gmail.com wrote:
Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.
+1000
On Tue, Feb 28, 2012 at 2:22 PM, Kiall Mac Innes ki...@managedit.ie wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.
Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = 456
foo($a);
As proposed, works, no error as discussed above.
$a = Hello World;
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.
So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)
On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologlou linep...@gmail.com wrote:
Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their benefits
and their disadvantages, so trying to prove that one is better to the other
leads to nowhere.
Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to strongly
typed languages, I see no reason to just close the door. I think it's high
time that we separated the PHP *platform* from the PHP *language*. That
will eventually lead to the creation of strongly typed languages that could
be executed on the PHP platform.
Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Aren't you people getting tired of saying that arguments like it's
not the PHP way or that does not fit the PHP paradigm are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!.
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).
Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Tue, Feb 28, 2012 at 3:37 PM, Tom Boutell t...@punkave.com wrote: On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux distros have moved away from it... Ubuntu starts out with the worker threaded MPM. However when you install the standard PHP package it switches Apache to the prefork MPM. Actually, the true story for performance is to kill Apache and let Lighttpd or NginX do the job, with a pool of fcgi/fpm PHP processes About having a ZTS mod_php inside a Worker-based Apache : I know Brian Moon having tried that on a production host some time ago. He shares experiences here : http://doughboy.wordpress.com/2008/02/13/apache-worker-and-php/ Hope this helps, even if it is not a recommended architecture ;) Julien.P -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hey, Michael
This is by far the best possible way I read in the whole conversation.
I like the way of backwards-compatibility, error-reporting and so on.
This is would be very useful and would not disturb someone's
framework-combination.
This should be written down in a new RFC.
For all who want the strict types, you can write an error handler and
convert all you get into an exception :D
But then you'll end up with code-snippets like this (extracted from
Magento):
try {
$value = unserialize($optionValue);
} catch (Exception $e) {
$value = $optionValue;
}
Sorry but I had to mention it somewhere ;) This is by far the worst and
most complex code-snippet I've seen ever. It relies on the hidden feature
that the error-handler converts all errors into an exception - but only in
DEV mode :D Therefore it works for all developers but on in the live-mode :D
Bye
Simon
2012/2/28 Michael Morris dmgx.mich...@gmail.com
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = 456
foo($a);
As proposed, works, no error as discussed above.
$a = Hello World;
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.
So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)
On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologlou linep...@gmail.com
wrote:
Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their
benefits
and their disadvantages, so trying to prove that one is better to the
other
leads to nowhere.
Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to
strongly
typed languages, I see no reason to just close the door. I think it's
high
time that we separated the PHP *platform* from the PHP *language*. That
will eventually lead to the creation of strongly typed languages that
could
be executed on the PHP platform.
Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Aren't you people getting tired of saying that arguments like it's
not the PHP way or that does not fit the PHP paradigm are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!.
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).
Besides that - a scripting
Re: [PHP-DEV] Possibility to add finally to try/catch?
https://bugs.php.net/bug.php?id=36779 Not to say that finally shouldn't be added, but I don't think this lock inside a loop is a particularly compelling example... Either that loop is going to wait a whole lot for an exclusive lock at every iteration, or the locks aren't exclusive and could be more easily built up in an array and disposed of after the loop. Of course, for now, we have GOTO which might be of use in these situations. :-) Though I'm not sure you could effectively manage the (constrained to make wanton usage difficult) GOTO statements and targets if you need this a lot. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
On Tue, February 28, 2012 8:22 am, Kiall Mac Innes wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
+ if ($fh) fclose($fh); //many PHP file errors NULL out the $fh
+ }
- } finally {
- fclose($fh);
- }
Another non-compelling example...
Still not saying finally is a bad idea.
Just want a compelling use case before I would vote...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On Mon, February 27, 2012 5:21 pm, Ángel González wrote: On 27/02/12 19:22, Richard Lynch wrote: I'm not so sure about that. In a well-written web application, you would typically convert them on the first layer, when receiving from the web. On next usages, your int variables are usually ints already. Afraid not. It turns out that PHP, on 32-bit hardware, converting large BIGINT using (int) $ID ends up as a negative number, and then when you pass it in to the database if a string query, you get a negative ID, not at all what was intended. (Been there, done that, got burned) At least, that's been my experience with some versions of PHP and some database drivers. So at least the database IDs have to remain as strings, if you are using BIGINT. You could, of course, only convert the values known to be in range of PHPs positive integers, and leave the others as strings. This is just a simple example of how the super strict typing simply doesn't work out too well in PHP. That's a good example from experience. Although if you want to keep ids as strings, you can simply keep them as a string type. I was thinking on input coming from a web browser, btw. In a pagination of billions of items, it could come from the browser... Of course, you'd need something like a relativistic paginator such as: First | -1,000,000 | -100,000 | -10,000 | -1,000 | -100 | -10 | current | +10 | +100 | +1,000 | +10,000 | +100,000 | + 1,000,000 | Last Of course, you need to show 10 per page for this to be navigable to any item. I had to write such a beast once, though the range was only in the 100K, not billions... And it took some user-training, but it was an internal tool, so that was okay. Even the CEO who didn't know how to work email (literally) managed to figure it out eventually. You can get to billions with only 6 more links, however. :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Mon, February 27, 2012 6:46 pm, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). Can you expand explain this, with an eye to resolving 61172? Are you saying Apache 2.4 'httpd -M' might not return the mpm? If I'm reading this correctly: apxs runs at PHP compile time and reads mpm from httpd.conf Apache is started, probably with that mpm, and then a different mpm is loaded and apache is re-started, maybe even with graceful, for real fun. mod_php has no knowledge of the new mpm, because the mpm choice was compiled in at apxs time. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Function type hints are ok, but I can't imagine a reason why would you
really use the locked variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)
2012/2/28 Michael Morris dmgx.mich...@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = 456
foo($a);
As proposed, works, no error as discussed above.
$a = Hello World;
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.
So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)
On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologlou linep...@gmail.com
wrote:
Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their benefits
and their disadvantages, so trying to prove that one is better to the other
leads to nowhere.
Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to strongly
typed languages, I see no reason to just close the door. I think it's high
time that we separated the PHP *platform* from the PHP *language*. That
will eventually lead to the creation of strongly typed languages that could
be executed on the PHP platform.
Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Re: [PHP-DEV] Possibility to add finally to try/catch?
It's quite hard to think of a compelling example. Usually you just
write the code and realize that Yea, a 'finally' statement would make
a lot of sense here.
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
brainier these days, the last two to me where wtf? does anyone use
that? Where I need them at all?!. It was like that for 3-4 years.
Until I got the code witch actually made an active use of these two
and I understood the purpose.
Same goes to finally. I remember using in JavaScript a few times, helped a lot.
And it just makes sense to add to complete the try {} catch {} finally
{} template.
My 2 cents.
2012/2/28 Richard Lynch c...@l-i-e.com:
On Tue, February 28, 2012 8:22 am, Kiall Mac Innes wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
+ if ($fh) fclose($fh); //many PHP file errors NULL out the $fh
+ }
- } finally {
- fclose($fh);
- }
Another non-compelling example...
Still not saying finally is a bad idea.
Just want a compelling use case before I would vote...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
I did check out the article on using worker thread MPM with PHP on Linux. The basic argument is that since threads can reclaim memory used and then freed by other PHP requests, while processes don't return memory to the OS until they finally exit, there is more memory available. However I doubt that this can be the case when the server is at peak utilization. When things are maxed out you will still have, say, 20 threads hitting PHP scripts that happen to be expensive in terms of memory (let's say 50mb), and that will be roughly all the memory you have to play with in your 1GB system. So you're just as stuck as if you had 20 dedicated fastcgi processes, all maxed out at 50mb already by some previous request. The only win here is that in the average case, you can handle more requests. But you usually can't predict in advance when the worst case will come along. So if you permit that to happen you are risking a slowdown or a meltdown (: For stability a fastcgi pool of the size you know you can handle based on studying your past memory stats still seems to be the way to go. On Tue, Feb 28, 2012 at 10:41 AM, jpauli jpa...@php.net wrote: Actually, the true story for performance is to kill Apache and let Lighttpd or NginX do the job, with a pool of fcgi/fpm PHP processes I'd like to ask you whether it really makes much difference to use Lighttpd or NginX as opposed to Apache with the worker thread MPM, but at that point we are officially way off topic (: I think that in terms of general architecture, and in terms of what to do with PHP, those three options are basically the same option. I haven't studied FPM yet as I haven't felt a need for its advertised advantages over the traditional FastCGI support in the CGI SAPI yet. I will check out the apache worker and PHP article, thanks. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
Completely agree - finally comes into its own in more complex code, the
kind of code that is quite hard to distill into a few line compelling
example.
Yes, You could abstract the try/catch into a new (and un-needed) function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch. But - This really is no
substitute for a native language construct
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
$log-add(Log::ERROR, Something went wrong, $e);
throw $e;
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 4:12 PM, Arvids Godjuks arvids.godj...@gmail.comwrote:
It's quite hard to think of a compelling example. Usually you just
write the code and realize that Yea, a 'finally' statement would make
a lot of sense here.
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
brainier these days, the last two to me where wtf? does anyone use
that? Where I need them at all?!. It was like that for 3-4 years.
Until I got the code witch actually made an active use of these two
and I understood the purpose.
Same goes to finally. I remember using in JavaScript a few times, helped a
lot.
And it just makes sense to add to complete the try {} catch {} finally
{} template.
My 2 cents.
2012/2/28 Richard Lynch c...@l-i-e.com:
On Tue, February 28, 2012 8:22 am, Kiall Mac Innes wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
+ if ($fh) fclose($fh); //many PHP file errors NULL out the $fh
+ }
- } finally {
- fclose($fh);
- }
Another non-compelling example...
Still not saying finally is a bad idea.
Just want a compelling use case before I would vote...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes ki...@managedit.ie wrote:
Yes, You could abstract the try/catch into a new (and un-needed) function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.
'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block
- does it?
I would hope not, since that means something this block of code did
not anticipate at all - another sort of exceptional situation
altogether and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.
Assuming I'm right and 'finally' runs only for normal completion and
for exceptions actually caught by the catch { } block attached to the
same try { }, then my refactoring still behaves exactly like
'finally'.
I am not convinced the function is unnecessary, either. Decomposition
is usually a good idea (:
substitute for a native language construct
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
$log-add(Log::ERROR, Something went wrong, $e);
throw $e;
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 4:12 PM, Arvids Godjuks
arvids.godj...@gmail.comwrote:
It's quite hard to think of a compelling example. Usually you just
write the code and realize that Yea, a 'finally' statement would make
a lot of sense here.
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
brainier these days, the last two to me where wtf? does anyone use
that? Where I need them at all?!. It was like that for 3-4 years.
Until I got the code witch actually made an active use of these two
and I understood the purpose.
Same goes to finally. I remember using in JavaScript a few times, helped a
lot.
And it just makes sense to add to complete the try {} catch {} finally
{} template.
My 2 cents.
2012/2/28 Richard Lynch c...@l-i-e.com:
On Tue, February 28, 2012 8:22 am, Kiall Mac Innes wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
+ if ($fh) fclose($fh); //many PHP file errors NULL out the $fh
+ }
- } finally {
- fclose($fh);
- }
Another non-compelling example...
Still not saying finally is a bad idea.
Just want a compelling use case before I would vote...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/27/2012 6:46 PM, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). Can you expand explain this, with an eye to resolving 61172? Are you saying Apache 2.4 'httpd -M' might not return the mpm? The mpm is now a loadable module, not compiled in. The recommended default mpm is now event, the recommended .rpm proposes shipping event/worker/prefork, all as modules. The user is *free* to switch mpm's at any point by simply editing their httpd.conf file, so what was a non-threaded server becomes a threaded one. httpd -l will not return what you want, httpd -M will, but is not the right solution... # bin/httpd -l Compiled in modules: core.c mod_so.c http_core.c # bin/httpd -M Loaded Modules: core_module (static) so_module (static) http_module (static) ... version_module (shared) mpm_event_module (shared) unixd_module (shared) ... The httpd -V command was always the correct way to test for threaded'ness, which would allow supporting an mpm which was not known to you. Again, it will only reflect the currently loaded module (and fail if no MPM is loaded); # bin/httpd -V Server version: Apache/2.4.1 (Unix) Server built: Feb 28 2012 10:37:32 Server's Module Magic Number: 20120211:0 Server loaded: APR 1.4.5, APR-UTIL 1.3.12 Compiled using: APR 1.4.5, APR-UTIL 1.3.12 Architecture: 64-bit Server MPM: event threaded: yes (fixed thread count) forked: yes (variable process count) ... Editing httpd.conf... s/event/prefork/ results in ... Server MPM: prefork threaded: no forked: yes (variable process count) In 2.2 the default MPM became worker. In 2.4 the default MPM is now event, so prefork hasn't been the default in some 7 years. The only sensible build for mod_php is ZTS, which will load and operate whichever mpm is loaded by the user. The only sensible single thread environment is cgi (enhanced, of course, with fastcgi!) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
On Tue, Feb 28, 2012 at 4:48 PM, Tom Boutell t...@punkave.com wrote:
On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes ki...@managedit.ie
wrote:
Yes, You could abstract the try/catch into a new (and un-needed) function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.
'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block
- does it?
I would hope not, since that means something this block of code did
not anticipate at all - another sort of exceptional situation
altogether and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.
I would indeed expect the finally to run regardless of what happens in the
catch block.
$ python
def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print division by zero!
... raise Exception('division by zero')
... else:
... print result is, result
... finally:
... print executing finally clause
...
divide(2, 1)
result is 2
executing finally clause
divide(2, 0)
division by zero!
executing finally clause == The interesting part
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 6, in divide
Exception: division by zero
divide(2, 1)
executing finally clause
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'
Re: [PHP-DEV] Possibility to add finally to try/catch?
OK, consider my point successfully buried in counterexamples (:
On Tue, Feb 28, 2012 at 12:02 PM, Kiall Mac Innes ki...@managedit.ie wrote:
An an equivalent snippet of ruby..
$ irb
irb(main):001:0 def divide(x, y)
irb(main):002:1 begin
irb(main):003:2* result = x / y
irb(main):004:2 puts result is, result
irb(main):005:2 rescue ZeroDivisionError
irb(main):006:2 puts division by zero!
irb(main):007:2 raise Exception('division by zero')
irb(main):008:2 ensure
irb(main):009:2* puts executing finally clause
irb(main):010:2 end
irb(main):011:1 end
= nil
irb(main):012:0
irb(main):013:0*
irb(main):014:0* divide(2, 1)
result is
2
executing finally clause
= nil
irb(main):015:0
irb(main):016:0* divide(2, 0)
division by zero!
executing finally clause == The interesting part
NoMethodError: undefined method `Exception' for main:Object
from (irb):7:in `divide'
from (irb):16
from :0
irb(main):017:0
irb(main):018:0* divide(2, 1)
executing finally clause
NoMethodError: undefined method `/' for 2:String
from (irb):3:in `divide'
from (irb):18
from :0
Thanks,
Kiall
On Tue, Feb 28, 2012 at 4:54 PM, Kiall Mac Innes ki...@managedit.ie wrote:
On Tue, Feb 28, 2012 at 4:48 PM, Tom Boutell t...@punkave.com wrote:
On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes ki...@managedit.ie
wrote:
Yes, You could abstract the try/catch into a new (and un-needed)
function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.
'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block
- does it?
I would hope not, since that means something this block of code did
not anticipate at all - another sort of exceptional situation
altogether and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.
I would indeed expect the finally to run regardless of what happens in the
catch block.
$ python
def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print division by zero!
... raise Exception('division by zero')
... else:
... print result is, result
... finally:
... print executing finally clause
...
divide(2, 1)
result is 2
executing finally clause
divide(2, 0)
division by zero!
executing finally clause == The interesting part
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 6, in divide
Exception: division by zero
divide(2, 1)
executing finally clause
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
Hi! This is another feature that we know we can live without but those familiar with languages that have 'finally' like Java or Python know that it is very neat feature to have in some situations. Last time we looked into it we couldn't make a clean implementation of it that worked well. If anybody has good ideas about how to do it, please provide a patch. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
An an equivalent snippet of ruby..
$ irb
irb(main):001:0 def divide(x, y)
irb(main):002:1 begin
irb(main):003:2* result = x / y
irb(main):004:2 puts result is, result
irb(main):005:2 rescue ZeroDivisionError
irb(main):006:2 puts division by zero!
irb(main):007:2 raise Exception('division by zero')
irb(main):008:2 ensure
irb(main):009:2* puts executing finally clause
irb(main):010:2 end
irb(main):011:1 end
= nil
irb(main):012:0
irb(main):013:0*
irb(main):014:0* divide(2, 1)
result is
2
executing finally clause
= nil
irb(main):015:0
irb(main):016:0* divide(2, 0)
division by zero!
executing finally clause == The interesting part
NoMethodError: undefined method `Exception' for main:Object
from (irb):7:in `divide'
from (irb):16
from :0
irb(main):017:0
irb(main):018:0* divide(2, 1)
executing finally clause
NoMethodError: undefined method `/' for 2:String
from (irb):3:in `divide'
from (irb):18
from :0
Thanks,
Kiall
On Tue, Feb 28, 2012 at 4:54 PM, Kiall Mac Innes ki...@managedit.ie wrote:
On Tue, Feb 28, 2012 at 4:48 PM, Tom Boutell t...@punkave.com wrote:
On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes ki...@managedit.ie
wrote:
Yes, You could abstract the try/catch into a new (and un-needed)
function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.
'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block
- does it?
I would hope not, since that means something this block of code did
not anticipate at all - another sort of exceptional situation
altogether and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.
I would indeed expect the finally to run regardless of what happens in the
catch block.
$ python
def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print division by zero!
... raise Exception('division by zero')
... else:
... print result is, result
... finally:
... print executing finally clause
...
divide(2, 1)
result is 2
executing finally clause
divide(2, 0)
division by zero!
executing finally clause == The interesting part
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 6, in divide
Exception: division by zero
divide(2, 1)
executing finally clause
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'
Re: [PHP-DEV] Possibility to add finally to try/catch?
On Tue, Feb 28, 2012 at 5:36 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Last time we looked into it we couldn't make a clean implementation of it that worked well. If anybody has good ideas about how to do it, please provide a patch. Right - I don't claim, even for a moment, to have the slightly clue how easy/hard the implementation would be. But - I don't think that should stop the discussion, or even consensus gathering, of whether or not the feature should be implemented. If the consensus is that the feature is useful and will likely be accepted if formally proposed etc - that may encourage someone to spend the time on finding a clean and acceptable implementation! Anyway - Just my 2c. Kiall (P.S. Yes - I know there was an error in my ruby example.. Luckily I caused an exception while trying to raise an exception.. so no harm!)
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
Hi! so prefork hasn't been the default in some 7 years. The only sensible build for mod_php is ZTS, which will load and operate whichever mpm is loaded by the user. The only sensible single thread environment is cgi (enhanced, of course, with fastcgi!) Please note that TS build is slower and has higher memory requirements (due to TS locks and TS data structures) so having it as only build may not be optimal. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers. A
string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a E_STRICT
or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part of the
php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point why I
want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer whereas
the documentation says that this function expects a string (or an error if
it should be an object or array).
Bye
Simon
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Function type hints are ok, but I can't imagine a reason why would you
really use the locked variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)
2012/2/28 Michael Morris dmgx.mich...@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = 456
foo($a);
As proposed, works, no error as discussed above.
$a = Hello World;
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/28/2012 12:26 PM, Stas Malyshev wrote: so prefork hasn't been the default in some 7 years. The only sensible build for mod_php is ZTS, which will load and operate whichever mpm is loaded by the user. The only sensible single thread environment is cgi (enhanced, of course, with fastcgi!) Please note that TS build is slower and has higher memory requirements (due to TS locks and TS data structures) so having it as only build may not be optimal. Of course, which is why a cgi build is /also/ useful. But I just don't see performance complaints, they are almost always reliability or configuration issues. If you are running that close to the edge that the 15% performance penalty kills your box, you were well past time to scale to more boxes or to review the PHP code itself for performance issues. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
I'll go ahead and create an RFC for this if nobody has any objections. Then we could link to that instead of a bug ticket. --Kris On Tue, Feb 28, 2012 at 10:09 AM, Kiall Mac Innes ki...@managedit.iewrote: On Tue, Feb 28, 2012 at 5:36 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Last time we looked into it we couldn't make a clean implementation of it that worked well. If anybody has good ideas about how to do it, please provide a patch. Right - I don't claim, even for a moment, to have the slightly clue how easy/hard the implementation would be. But - I don't think that should stop the discussion, or even consensus gathering, of whether or not the feature should be implemented. If the consensus is that the feature is useful and will likely be accepted if formally proposed etc - that may encourage someone to spend the time on finding a clean and acceptable implementation! Anyway - Just my 2c. Kiall (P.S. Yes - I know there was an error in my ruby example.. Luckily I caused an exception while trying to raise an exception.. so no harm!)
Re: [PHP-DEV] Scalar type hinting
There are indeed valid arguments for and against hinting. It seems to me
that having it optional as people have suggested would be the best of both
worlds approach, since it would allow the developer to choose for
themselves. I guess that means I'm on the pro-choice side of this debate
lol (seriously, all kidding aside, I've seen debates over abortion that
weren't as heated as this!).
--Kris
On Tue, Feb 28, 2012 at 10:35 AM, Simon Schick
simonsimc...@googlemail.comwrote:
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers. A
string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a E_STRICT
or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part of the
php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point why I
want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer whereas
the documentation says that this function expects a string (or an error if
it should be an object or array).
Bye
Simon
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Function type hints are ok, but I can't imagine a reason why would you
really use the locked variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)
2012/2/28 Michael Morris dmgx.mich...@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar,
RE: [PHP-DEV] Scalar type hinting
OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) In addition, if someone potentially new expresses support for Strict Typing, please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want Strict Typing (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Scalar type hinting
Thank you. Now I'm going to go work up a detailed RFC for what I posted earlier with some additional clarification as to when errors should and shouldn't be thrown. On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) In addition, if someone potentially new expresses support for Strict Typing, please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want Strict Typing (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
@Michael Would you be willing to delay that? Rather than create a bunch of new RFC's, I was thinking it might be better if all interested parties came together on some other communication medium and worked on a single, collaborative RFC instead. --Kris On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris dmgx.mich...@gmail.comwrote: Thank you. Now I'm going to go work up a detailed RFC for what I posted earlier with some additional clarification as to when errors should and shouldn't be thrown. On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) In addition, if someone potentially new expresses support for Strict Typing, please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want Strict Typing (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Can I make a suggestion? Instead of an rfc, can we collate the existing discussion into an easier to digest format (historical as well). Summarize the conversations and existing rfcs with the discussion around them (including the pros/cons and problems). That way we have a point of reference and comparison with which to base the rfc on, and a way to judge and rate the rfc... Anthony On Feb 28, 2012 3:09 PM, Kris Craig kris.cr...@gmail.com wrote: @Michael Would you be willing to delay that? Rather than create a bunch of new RFC's, I was thinking it might be better if all interested parties came together on some other communication medium and worked on a single, collaborative RFC instead. --Kris On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris dmgx.mich...@gmail.com wrote: Thank you. Now I'm going to go work up a detailed RFC for what I posted earlier with some additional clarification as to when errors should and shouldn't be thrown. On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) In addition, if someone potentially new expresses support for Strict Typing, please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want Strict Typing (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.comwrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) Where is the term strict typing coming from? I've not seen this used to describe any type system (doesn't mean it's not been used, but I'd really like to see the usage so I can understand the label.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) Doesn't weak typing mean that the language implicitly converts types for use according to a set of rules? The opposite of this being strong typing, which means the language does not perform implicit conversions. - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) And, curious about the No Scalar Typing? Sorry for the questions. Thanks, Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
[PHP-DEV] [VOTE] APXS LoadModule Option in configure
Hi all, It looks like we've reached a consensus on this, so absent any objections, I went ahead and moved this to the voting phase. If you're eligible to vote on RFC's, please navigate to the RFC and cast your vote now: https://wiki.php.net/rfc/apxs-loadmodule In case you weren't following the previous thread, this is a very low-impact RFC that will add a new, optional switch to the configure script. This switch, if specified, would tell APXS (which already has this functionality built-in) not to write the LoadModule line to httpd.conf when make install is performed. This is a feature that has been requested for some time and would allow people with manually-built PHP installs to isolate their mod_php hooks in a separate php.conf file without having to manually edit httpd.conf whenever a new build is performed. If this optional switch is not specified, the configure script will behave exactly as it does now. As such, this RFC will *not* alter configure's existing behavior unless you explicitly include this new switch. Please let me know if you have any last-minute questions. Otherwise, happy voting! Thanks! --Kris
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 02/28/2012 08:51 AM, William A. Rowe Jr. wrote: On 2/27/2012 6:46 PM, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). Can you expand explain this, with an eye to resolving 61172? Are you saying Apache 2.4 'httpd -M' might not return the mpm? The mpm is now a loadable module, not compiled in. The recommended default mpm is now event, the recommended .rpm proposes shipping event/worker/prefork, all as modules. The user is *free* to switch mpm's at any point by simply editing their httpd.conf file, so what was a non-threaded server becomes a threaded one. httpd -l will not return what you want, httpd -M will, but is not the right solution... # bin/httpd -l Compiled in modules: core.c mod_so.c http_core.c # bin/httpd -M Loaded Modules: core_module (static) so_module (static) http_module (static) ... version_module (shared) mpm_event_module (shared) unixd_module (shared) ... The httpd -V command was always the correct way to test for threaded'ness, which would allow supporting an mpm which was not known to you. Again, it will only reflect the currently loaded module (and fail if no MPM is loaded); # bin/httpd -V Server version: Apache/2.4.1 (Unix) Server built: Feb 28 2012 10:37:32 Server's Module Magic Number: 20120211:0 Server loaded: APR 1.4.5, APR-UTIL 1.3.12 Compiled using: APR 1.4.5, APR-UTIL 1.3.12 Architecture: 64-bit Server MPM: event threaded: yes (fixed thread count) forked: yes (variable process count) ... Editing httpd.conf... s/event/prefork/ results in ... Server MPM: prefork threaded: no forked: yes (variable process count) In 2.2 the default MPM became worker. In 2.4 the default MPM is now event, so prefork hasn't been the default in some 7 years. The only sensible build for mod_php is ZTS, which will load and operate whichever mpm is loaded by the user. The only sensible single thread environment is cgi (enhanced, of course, with fastcgi!) Thanks for clarifying that there is nothing unexpected (to me) happening and for suggesting using -V. It seems that the PHP installer could do one of two things: 1. Build PHP for the currently installed Apache MPM, using httpd -V to identify whether to enable PHP's ZTS mode or not. PHP documentation and/or 'configure' messages should state the MPM shouldn't later be changed to threaded if it was originally prefork. A proviso about ZTS overhead and limitations could be noted. 2. Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure' There are some variations of the above, depending on the target audience(s) and scope of perceived problem. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
+1 what Anthony said. I think it would be prudent, as some have already suggested, for those of us who are interested in this topic to move it to a more discreet location so as to reduce some of the noise all around. I'll take a look at Google docs and see if that will suit our purposes. If anyone else has any ideas on this, please share them! =) --Kris On Tue, Feb 28, 2012 at 12:18 PM, Adam Richardson simples...@gmail.comwrote: On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) Where is the term strict typing coming from? I've not seen this used to describe any type system (doesn't mean it's not been used, but I'd really like to see the usage so I can understand the label.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) Doesn't weak typing mean that the language implicitly converts types for use according to a set of rules? The opposite of this being strong typing, which means the language does not perform implicit conversions. - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) And, curious about the No Scalar Typing? Sorry for the questions. Thanks, Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
RE: [PHP-DEV] Scalar type hinting
Inline. Quoted portion edited extensively for brevity.
-Original Message-
From: Michael Morris [mailto:dmgx.mich...@gmail.com]
$a = 123;
function foo ( int $i ) {}
foo($a); // OK
foo(123); // NOTICE, because 123 is a constant
$a = 456;
foo($a); // OK, because conversion is lossless
-1. Should be no notice in either of the last two cases. Raising the notice
when a constant is used is inconsistent and confusing. I also doubt that this
sort of implementation is even possible without some pretty massive internal
changes. Not worth it IMO.
int $a = 123; // type locked to integer
$a = 456; // E_NOTICE
$a = Hello World; // E_NOTICE
I'm very dubious on hinting variables. This would require storing additional
data with the variable, which (as far as I can see) would break binary
compatibility (same problem as taint). I don't see much of a use for this most
of the time, with the notable exception of member variables (sometimes type
locking a class member would be really nice.)
Also, there should be no notice in case 2 (same argument as before with
functions)
Notice on case 3 is fine
unset($a);
$a = Hello World; // OK, because of unset
int $a; // E_NOTICE, $a had a value which can't convert without loss of data.
This just seems silly to me. Trying to declare int $a after $a is already
present and set is a nonsense construct. I think E_RECOVERABLE_ERROR should be
raised on this and $a should be set to null regardless of convertibility (the
more likely intent and meaning of that line of code) in case the error handler
decides to continue execution.
scalar $a;
-1, I don't think we need this any more than we need an explicit mixed type.
Saying this function needs a number or it can't work is one thing. There is a
sound logical foundation for that. A scalar could be anything though. You're
still going to have to check types to decide what you really have and alter
code paths as appropriate.
And if we don't want to unset $a but rather restore $a to behaving like a
scalar, that is how it would be done.
-1, same argument as int $a; when $a is already set. This is a nonsensical
construction. You are using a variable declaration like a typecast and reusing
a variable. This is sloppy and confusing to reduce code in a badly structured
edge case. If you really honestly must untype a local variable, you can always
do this instead:
$tmp = $a;
unset($a);
$a = $tmp;
BUT, if there is any reason why you would actually need to untype a variable,
then there are much bigger problems. This shouldn't be handled in the core
language.
So, in closing this ramble, if I right a db library whose functions are
datatyped
you might see more notices, but the code will work and notices are usually
suppressed
by default (yes, I know about the RFC to change that)
If using types causes a large number of unnecessary notices that's a spec
problem. The core devs aren't going to accept that.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar type hinting
From: Adam Richardson [mailto:simples...@gmail.com] On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.commailto:johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) Where is the term strict typing coming from? I've not seen this used to describe any type system (doesn't mean it's not been used, but I'd really like to see the usage so I can understand the label.) Adam, When you say you want Strict or Strong typing, this (case 1) is what the opponents of stronger typing think you are asking for, which is why I've defined it this way. There have been a tiny handful of individuals that really are asking for this, but most people don't really want this level of strictness. Also, this level of strictness is fundamentally at odds with the nature of PHP, and it's just never going to happen. The level of typing in this first case is littered with problems. I won't get into it all, but you can read prior discussions in the archives to see it. Look for the passionate arguments made by typing opponents that talk about massive changes, destroying the language, and Go use JSP. Scattered in there are some occasional explanations of the actual core issues, all of which refer to this level of typing. (Incidentally, even C++ is not this strict, so this really isn't what you want, I'm sure of it. If this is what you want, then this isn't the thread for you, because this is *not* what will be advocated or discussed here.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) Doesn't weak typing mean that the language implicitly converts types for use according to a set of rules? The opposite of this being strong typing, which means the language does not perform implicit conversions. Weak here really means weaker than the Strong above, but stronger than none. Right now PHP has no typing whatsoever. weak typing WOULD be typing, but it is flexible, optional, and aggressively uses implicit conversions. For comparison, by these definitions C++ is halfway between weak typing and strong typing (by virtue of operator overloads, overloaded functions, and cast operators.) This Weak typing will give you what you want, and it can work. Most importantly, it is *not* the thing that goes bump in the night for most strong typing opponents, which means it is probably possible to gather sufficient support for this. This discussion is focused on developing a rock solid proposal for weak typing. - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) And, curious about the No Scalar Typing? This is PHP right now. The language has no provision whatsoever for scalar types. Function parameters can be hinted as an array or as a specific class/interface, but otherwise they are assumed to be absolutely anything. I know that for people with a lot of experience in a strongly typed language this sounds like what they would normally call Weak Typing, but it's a 3rd level. Weak Typing under these definitions is a lot stronger than what you would call weak, but it's much weaker than what strong typing opponents would call strong. It's going to take some time to get used to the semantics, but if you want any typing enhancements you're going to have to speak the language of the people you want to convince. The communication disconnect here has been sinking this proposal for a decade. John Crenshaw Priacta, Inc.
RE: [PHP-DEV] Scalar type hinting
Yeah, I proposed this the other day. We need to go through the hundreds of historical emails on the subject and consolidate all the information into a central document outlining all the information that has been developed over the years. Lots of benefits to this. If multiple people want to participate in this process we can probably partition it by date ranges. John Crenshaw Priacta, Inc. -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, February 28, 2012 3:15 PM To: Kris Craig Cc: internals@lists.php.net; Arvids Godjuks; Michael Morris; Lazare Inepologlou Subject: Re: [PHP-DEV] Scalar type hinting Can I make a suggestion? Instead of an rfc, can we collate the existing discussion into an easier to digest format (historical as well). Summarize the conversations and existing rfcs with the discussion around them (including the pros/cons and problems). That way we have a point of reference and comparison with which to base the rfc on, and a way to judge and rate the rfc... Anthony On Feb 28, 2012 3:09 PM, Kris Craig kris.cr...@gmail.com wrote: @Michael Would you be willing to delay that? Rather than create a bunch of new RFC's, I was thinking it might be better if all interested parties came together on some other communication medium and worked on a single, collaborative RFC instead. --Kris On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris dmgx.mich...@gmail.com wrote: Thank you. Now I'm going to go work up a detailed RFC for what I posted earlier with some additional clarification as to when errors should and shouldn't be thrown. On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) In addition, if someone potentially new expresses support for Strict Typing, please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want Strict Typing (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Newbie: issues developing a new extension
Dear all,
I'm asking your help because I'm not able to solve an issue probably related to
some foolish mistake I have not yet discovered.
I'm trying to develop an experimental extension to interface LIXA library
(http:/lixa.sourceforge.net/).
I have created the basic stuff (config.m4, lixa.c, php_lixa.h and so on).
If I use this sequence from the ext/lixa directory:
/opt/php/bin/phpize
./configure --help
I can see the lixa extension is available:
[...]
Optional Packages:
--with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
--with-libdir=NAME Look for libraries in .../NAME rather than .../lib
--with-php-config=PATH Path to php-config php-config
--with-lixa=FILE Include LIXA support. File is the path to lixa-config
[...]
and I can compile with:
./configure --with-lixa=/opt/lixa/bin/lixa-config
--with-php-config=/opt/php/bin/php-config
the build process runs as expected and the extension is available after an
addition to php.ini (extension=[...]/ext/lixa/modules/lixa.so).
If I use this sequence from the PHP root directory:
./buildconf --force
as described here:
talks.somabo.de/200510_zend_conf_php_extension_development.pdf
I cannot see lixa as an available option of my configure:
./configure --help|grep lixa
is empty.
If I try to build PHP anyway, I obtain:
tiian@mojan:~/src/swig/php5.4-201202241630$ ./configure
--with-lixa=/opt/lixa/bin/lixa-config
configure: WARNING: unrecognized options: --with-lixa
that's a reasonable result because lixa extension does not appear in
configure help.
It seems the global configure does not recognize my extension.
Here's the config.m4 I have built in the last trials:
dnl config.m4 start
PHP_ARG_WITH(lixa, for LIXA support,
[ --with-lixa=FILE Include LIXA support. File is the path to
lixa-config program])
if test $PHP_LIXA != no; then
LIXA_CONFIG=$PHP_LIXA
dnl --with-lixa - SWIG is a pre-requisite
AC_CHECK_PROGS(SWIG, [swig], [])
if test -z $SWIG
then
AC_MSG_ERROR([cannot find swig program])
fi
dnl use lixa-config to determine LIXA include dir
AC_MSG_CHECKING([for LIXA using $LIXA_CONFIG])
LIXA_INCLUDE=$($LIXA_CONFIG --include-dir)
if test -r $LIXA_INCLUDE/tx.h
then
AC_MSG_RESULT(found tx.h in $LIXA_INCLUDE)
LIXA_DIR=$($PHP_LIXA --prefix)
fi
if test -z $LIXA_DIR
then
AC_MSG_RESULT([not found])
AC_MSG_ERROR([Please specify a valid lixa-config utility
program or reinstall the LIXA distribution])
fi
dnl # --with-lixa - add include path
PHP_ADD_INCLUDE($($LIXA_CONFIG --include-dir))
AC_MSG_CHECKING([if LIXA is compiled with PostgreSQL support])
tmp=$($LIXA_CONFIG --include-dir-postgresql 2/dev/null)
if test $? -eq 0
then
PHP_ADD_INCLUDE($tmp)
HAVE_LIXA_POSTGRESQL=1
AC_DEFINE([HAVE_LIXA_POSTGRESQL], [1], [Define to 1 if LIXA is
compiled with PostgreSQL support])
AC_MSG_RESULT([yes])
else
HAVE_LIXA_POSTGRESQL=0
AC_MSG_RESULT([no])
fi
AC_MSG_CHECKING([if LIXA is compiled with MySQL support])
tmp=$($LIXA_CONFIG --include-dir-mysql 2/dev/null)
if test $? -eq 0
then
PHP_ADD_INCLUDE($tmp)
HAVE_LIXA_MYSQL=1
AC_DEFINE([HAVE_LIXA_MYSQL], [1], [Define to 1 if LIXA is
compiled with MySQL support])
AC_MSG_RESULT([yes])
else
HAVE_LIXA_MYSQL=0
AC_MSG_RESULT([no])
fi
dnl # --with-lixa - dynamically generate lixa.i interface file for SWIG
LIXA_INTERFACE=lixa.i
AC_MSG_NOTICE([Producing file $LIXA_INTERFACE dynamically...])
echo %module lixa $LIXA_INTERFACE
echo %{ $LIXA_INTERFACE
echo #include \tx.h\ $LIXA_INTERFACE
if test $HAVE_LIXA_POSTGRESQL -eq 1
then
echo #include \lixapq.h\ $LIXA_INTERFACE
fi
if test $HAVE_LIXA_MYSQL -eq 1
then
echo #include \lixamy.h\ $LIXA_INTERFACE
fi
echo %} $LIXA_INTERFACE
echo %include \tx.h\ $LIXA_INTERFACE
if test $HAVE_LIXA_POSTGRESQL -eq 1
then
echo %include \lixapq.h\ $LIXA_INTERFACE
fi
if test $HAVE_LIXA_MYSQL -eq 1
then
echo %include \lixamy.h\ $LIXA_INTERFACE
fi
dnl # --with-lixa - building LIXA interface using SWIG
AC_MSG_CHECKING([if LIXA wrapper can be created with SWIG])
$SWIG -php -I$LIXA_INCLUDE -o lixa.c $LIXA_INTERFACE
if test $? -eq 0
then
AC_MSG_RESULT([yes])
else
AC_MSG_ERROR([unable to create
Re: [PHP-DEV] Scalar type hinting
I could setup a repo on Github for this if anyone thinks that would be helpful? --Kris On Tue, Feb 28, 2012 at 1:05 PM, John Crenshaw johncrens...@priacta.comwrote: Yeah, I proposed this the other day. We need to go through the hundreds of historical emails on the subject and consolidate all the information into a central document outlining all the information that has been developed over the years. Lots of benefits to this. If multiple people want to participate in this process we can probably partition it by date ranges. John Crenshaw Priacta, Inc. -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, February 28, 2012 3:15 PM To: Kris Craig Cc: internals@lists.php.net; Arvids Godjuks; Michael Morris; Lazare Inepologlou Subject: Re: [PHP-DEV] Scalar type hinting Can I make a suggestion? Instead of an rfc, can we collate the existing discussion into an easier to digest format (historical as well). Summarize the conversations and existing rfcs with the discussion around them (including the pros/cons and problems). That way we have a point of reference and comparison with which to base the rfc on, and a way to judge and rate the rfc... Anthony On Feb 28, 2012 3:09 PM, Kris Craig kris.cr...@gmail.com wrote: @Michael Would you be willing to delay that? Rather than create a bunch of new RFC's, I was thinking it might be better if all interested parties came together on some other communication medium and worked on a single, collaborative RFC instead. --Kris On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris dmgx.mich...@gmail.com wrote: Thank you. Now I'm going to go work up a detailed RFC for what I posted earlier with some additional clarification as to when errors should and shouldn't be thrown. On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) In addition, if someone potentially new expresses support for Strict Typing, please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want Strict Typing (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar type hinting
From: Kris Craig [mailto:kris.cr...@gmail.com] I could setup a repo on Github for this if anyone thinks that would be helpful? --Kris I was figuring wiki for that information, but that would limit participants to those with editing permissions. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On Mon, February 27, 2012 11:05 pm, Anthony Ferrara wrote:
?php
class Foo {
public $value = 1;
}
class Bar {
public $value = 1;
public function __castTo($type) {
return $this-value;
}
public function __assign($value) {
$this-value = $value;
return $value != 10;
}
}
$a = new Foo;
$b = new Bar;
$a++;
So, here's the thing...
This obviously trivial example makes perfect sense, until you realize
that some moron (and PHP has lots of them) will sooner or later make
++ do something completely weird, and I'm going to have to edit their
code-base and will have to dig through umpteen class files to figure
out what the heck ++ means...
I can see a lot of legitimate serious coders using this wisely.
Unfortunately, I can see a million scripters using it very un-wisely.
I can even see people overloading the plus operator for an object
wrapped around an array in multiple different ways, then pulling in
different libraries that seem quite useful, and the only way I can
figure out what + means is to dig through even more files and figure
out which bastard child this object comes from, that was passed into
some random function that uses + on it.
And then god knows what happens when you do:
$foo = new Foo(); //from library A
$bar = new Bar(); //from library B
$foobar = $foo + $bar;
//Will this last statement even make sense, even though both Foo and
Bar override the + operator, just in entirely different ways...
How can you even guarantee that $foo, presumably taking precedence,
won't attempt to access a non-existent property of Bar, generating an
ignored E_NOTICE on most hosts, and introduce a subtle bug that nobody
notices for months, even years, in a seldom-used function?
Consider the trivial example where Foo uses array_sum() and Bar uses
count() comes up with a number. It's a totally meaningless number in
any real-world scenario. How would one detect this bug, really, in
some mish-mash of libraries from PEAR/PECL/homebrew-MVC/Framework.
I'm sure you can define the rules in a page or so for precedence in
type-casting and what happens when.
But I really am not interested in figuring out the rules for + when
I've been using it the same way since 2nd grade, with modest changes
over the years that follow the spirit of +
Your proposal lets one re-define + to mean whatever one wants, and
while you might not abuse that, somebody else will...
You might as well install runkit on everybody's server and let them
have at it. :-)
PHP was founded on the KISS principle, so that newbies can, in fact,
write sub-optimal but working code quickly to get a website up, and to
keep newbie fingers out of mashing gears.
This is way over-the-top from that principle.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 02/28/2012 02:44 PM, Christopher Jones wrote: Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure' Why punish everyone by default because of Apache? Does not make sense to me. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: I think this is the main reason for differentiating between strong (or whatever word is appropriate) and weak. The developer may very well want their script to blow-up in such a case. I believe I actually get it now... You want 3 layers: $a = 1; //current kosher unchanged weak int $a = 1; // some E_x error level strong int $a = 1; // some E_y error level where E_y E_x Is that a correct summation? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
@Richard That's fairly close to what I'm thinking, yes. But there seems to be a diverse range of ideas bouncing around right now, so at present it's all in flux. --Kris On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch c...@l-i-e.com wrote: On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: I think this is the main reason for differentiating between strong (or whatever word is appropriate) and weak. The developer may very well want their script to blow-up in such a case. I believe I actually get it now... You want 3 layers: $a = 1; //current kosher unchanged weak int $a = 1; // some E_x error level strong int $a = 1; // some E_y error level where E_y E_x Is that a correct summation? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
I'm not sure I'd take it quite that far. I've done benchmarking of NTS and ZTS builds and the difference really isn't anything I would consider worth worrying about in most cases. It's fairly minor. --Kris On Tue, Feb 28, 2012 at 1:41 PM, Sebastian Bergmann sebast...@php.netwrote: On 02/28/2012 02:44 PM, Christopher Jones wrote: Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure' Why punish everyone by default because of Apache? Does not make sense to me. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
Am 28.02.2012 22:41, schrieb Sebastian Bergmann: On 02/28/2012 02:44 PM, Christopher Jones wrote: Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure' Why punish everyone by default because of Apache? Does not make sense to me. even for apache it is a bad default i bet the are more mod_php setups taht fast-cgi/cgi signature.asc Description: OpenPGP digital signature
RE: [PHP-DEV] Scalar type hinting
No, In the example given there's an error on int $a = 1. There should be no error because this juggles fine. John Crenshaw Priacta, inc. -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 4:47 PM To: Richard Lynch Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting @Richard That's fairly close to what I'm thinking, yes. But there seems to be a diverse range of ideas bouncing around right now, so at present it's all in flux. --Kris On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch c...@l-i-e.com wrote: On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: I think this is the main reason for differentiating between strong (or whatever word is appropriate) and weak. The developer may very well want their script to blow-up in such a case. I believe I actually get it now... You want 3 layers: $a = 1; //current kosher unchanged weak int $a = 1; // some E_x error level strong int $a = 1; // some E_y error level where E_y E_x Is that a correct summation? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=F S9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Err sorry yes John is correct. I wasn't paying close enough attention. Here's *my* vision of how that progression would look: $a = 1; // Current kosher unchanged. weak int $a = 1; // Converts to 1. No error thrown. strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). $a = blah; // Current kosher unchanged. weak int $a = blah; // Throws E_x error level. strong int $a = blah; // Throws E_y error level. Where E_y E_x. --Kris On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw johncrens...@priacta.comwrote: No, In the example given there's an error on int $a = 1. There should be no error because this juggles fine. John Crenshaw Priacta, inc. -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 4:47 PM To: Richard Lynch Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting @Richard That's fairly close to what I'm thinking, yes. But there seems to be a diverse range of ideas bouncing around right now, so at present it's all in flux. --Kris On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch c...@l-i-e.com wrote: On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: I think this is the main reason for differentiating between strong (or whatever word is appropriate) and weak. The developer may very well want their script to blow-up in such a case. I believe I actually get it now... You want 3 layers: $a = 1; //current kosher unchanged weak int $a = 1; // some E_x error level strong int $a = 1; // some E_y error level where E_y E_x Is that a correct summation? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=F S9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Newbie: issues developing a new extension
On 02/28/2012 01:25 PM, Christian Ferrari wrote: Dear all, I'm asking your help because I'm not able to solve an issue probably related to some foolish mistake I have not yet discovered. I'm trying to develop an experimental extension to interface LIXA library (http:/lixa.sourceforge.net/). I have created the basic stuff (config.m4, lixa.c, php_lixa.h and so on). If I use this sequence from the ext/lixa directory: /opt/php/bin/phpize ./configure --help I can see the lixa extension is available: [...] Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-libdir=NAME Look for libraries in .../NAME rather than .../lib --with-php-config=PATH Path to php-config php-config --with-lixa=FILEInclude LIXA support. File is the path to lixa-config [...] and I can compile with: ./configure --with-lixa=/opt/lixa/bin/lixa-config --with-php-config=/opt/php/bin/php-config the build process runs as expected and the extension is available after an addition to php.ini (extension=[...]/ext/lixa/modules/lixa.so). Great, you are done. Why do you want to go any further than this? You built your extension and it is available from PHP exactly like any pecl extension. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Tue, Feb 28, 2012 at 3:58 PM, John Crenshaw johncrens...@priacta.comwrote: *From:* Adam Richardson [mailto:simples...@gmail.com] On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrens...@priacta.com wrote: OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect (strict typing means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms: - Strict Typing means the super strict old C style typing *with no implicit conversions*. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.) ** ** Where is the term strict typing coming from? I've not seen this used to describe any type system (doesn't mean it's not been used, but I'd really like to see the usage so I can understand the label.) ** ** Adam, When you say you want “Strict” or “Strong” typing, this (case 1) is what the opponents of stronger typing think you are asking for, which is why I’ve defined it this way. There have been a tiny handful of individuals that really are asking for this, but most people don’t really want this level of strictness. Also, this level of strictness is fundamentally at odds with the nature of PHP, and it’s just never going to happen. The level of typing in this first case is littered with problems. I won’t get into it all, but you can read prior discussions in the archives to see it. Look for the passionate arguments made by typing opponents that talk about “massive changes”, “destroying the language”, and “Go use JSP”. Scattered in there are some occasional explanations of the actual core issues, all of which refer to this level of typing. (Incidentally, even C++ is not this strict, so this really isn’t what you want, I’m sure of it. If this is what you want, then this isn’t the thread for you, because this is **not** what will be advocated or discussed here.) OK, if this is the case, I'd suggest we use the words Weak and Strong, and then speak to whether a proposal seeks to strengthen or weaken the existing type system. That way we utilize the terminology the labels that the existing programming language discourse community uses. Those performing research on the topics will be able to find the terms used. http://en.wikipedia.org/wiki/Type_system http://www.amazon.com/Programming-Language-Pragmatics-Third-Michael/dp/0123745144/ - Weak Typing means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, 2) == 345.) (If you think you want strict typing, this is probably what you mean.) ** ** Doesn't weak typing mean that the language implicitly converts types for use according to a set of rules? The opposite of this being strong typing, which means the language does not perform implicit conversions. ** ** “Weak” here really means weaker than the “Strong” above, but stronger than “none”. Right now PHP has no typing whatsoever. “weak typing” WOULD be typing, but it is flexible, optional, and aggressively uses implicit conversions. For comparison, by these definitions C++ is halfway between “weak typing” and “strong typing” (by virtue of operator overloads, overloaded functions, and cast operators.) I'm not sure this is the case. PHP is typically categorized as a dynamically typed language, meaning variables don't hold types, BUT, values do: http://en.wikipedia.org/wiki/Type_system#Dynamic_typing Additionally, PHP performs conversions of values implicitly in many instances, so it's typically referred to as weakly typed (as opposed to strongly typed, although, as you point out, there is a continuum.) Hence, the === operator compares the values without performing the implicit type conversions PHP performs on values. http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems ** ** This “Weak typing” will give you what you want, and it can work. Most importantly, it is **not** the thing that goes bump in the night for most strong typing opponents, which means it is probably possible to gather sufficient support for this. This discussion is focused on developing a rock solid proposal for “weak typing”. - No Scalar Typing should be used to indicate the current system (where there is no provision for hinting at scalar types.) And, curious about the No Scalar Typing? ** ** This is PHP right now. The language has no provision whatsoever for scalar types. Function parameters can be hinted as an array or as a specific class/interface, but otherwise they are assumed to be absolutely anything. I
Re: [PHP-DEV] Newbie: issues developing a new extension
On Tue, Feb 28, 2012 at 10:00 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/28/2012 01:25 PM, Christian Ferrari wrote: Dear all, I'm asking your help because I'm not able to solve an issue probably related to some foolish mistake I have not yet discovered. I'm trying to develop an experimental extension to interface LIXA library (http:/lixa.sourceforge.net/). I have created the basic stuff (config.m4, lixa.c, php_lixa.h and so on). If I use this sequence from the ext/lixa directory: /opt/php/bin/phpize ./configure --help I can see the lixa extension is available: [...] Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-libdir=NAME Look for libraries in .../NAME rather than .../lib --with-php-config=PATH Path to php-config php-config --with-lixa=FILEInclude LIXA support. File is the path to lixa-config [...] and I can compile with: ./configure --with-lixa=/opt/lixa/bin/lixa-config --with-php-config=/opt/php/bin/php-config the build process runs as expected and the extension is available after an addition to php.ini (extension=[...]/ext/lixa/modules/lixa.so). Great, you are done. Why do you want to go any further than this? You built your extension and it is available from PHP exactly like any pecl extension. and if you're using apache, reboot it and check your phpinfo() page for your extension. if you're connected up via the command line you can run php -m to see if your modules exists. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 2:08 pm, Johannes Schlüter wrote: On Mon, 2012-02-27 at 21:05 +0100, Gustavo Lopes wrote: On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter johan...@schlueters.de wrote: On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote: I'd have to come up with some OTHER scenario not involving fatal error, such as: strict $db = new DB(); The example is wrong. The new operator will always return an instance of the given class (or there will be an exception). [...] This is not true. The new operator can return NULL. In fact, the intl extension uses this extensively: ok, internal stuff can do everything it wants. But it shouldn't. Doing that is really bad and I wasn't aware of that case. :-) And since it's bad another example should be used :-) At the risk of quoting the docs to a guy who probably wrote a bunch of it... http://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new doesn't really SAY you can't return NULL in the event of an Exception or raising an error... Maybe it's a documentation error to not explicitly state what the return value is when one raises an error and/or throws the Exception. But it may not even make sense to create an Object of that type, or could be incredibly difficult to create if there are enough extends, interface and whatnot... So shouldn't is an un-documented statement, at this time, and more a Best Practice perhaps. :-) To me, however, returning NULL seems like a reasonable action when the spec is followed and an Exception is thrown or an error is raised. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Additionally, return type hinting could strengthen the use of interfaces.
That could problems with implementing interfaces (or an API) from having
to do checking to ensure a method in a class implementing an interface
is behaving as it should (returning the right stuff).
On 2/28/2012 12:35 PM, Simon Schick wrote:
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers. A
string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a E_STRICT
or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part of the
php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point why I
want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer whereas
the documentation says that this function expects a string (or an error if
it should be an object or array).
Bye
Simon
2012/2/28 Arvids Godjuksarvids.godj...@gmail.com
Function type hints are ok, but I can't imagine a reason why would you
really use the locked variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)
2012/2/28 Michael Morrisdmgx.mich...@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the *option*
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo(123)
We are still ok, since the conversion of 123 to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, 123 is an
explicit string value.
$a = 456;
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = 456;
will raise an E_Notice and so will
$a = Hello World;
If we want $a to go back to being a scalar one might try...
unset($a);
$a = Hello World;
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = 456
foo($a);
As proposed, works, no error as discussed above.
$a = Hello
Re: [PHP-DEV] Scalar type hinting
On Tue, February 28, 2012 3:31 am, Arvids Godjuks wrote: I really liked what the O'Raily wrote here: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html Please note that the author was a bass player in a band wanting to sell CDs online when the five (5) choices were the same brick-and-mortar major label distributors who wouldn't take his CD as he wasn't on a major label. He examined the options, and PHP was the only one that didn't make his head spin. His act of creating a single page to sell his CD online went viral, and he accidentally built a multi-million dollar company because of that. Since he'd never set out to make the money, just to help his friends (and they told 2 friends, and they told 2 friends...) he always tracked success not by not, nor gross, but by dollars paid out to artists[1] He eventually sold the company to a trust fund that goes to charity when he dies, and lives very comfortably off the interest, since he lost interest in running the company when it just got too routine.[2] If he had seen this strict/weak/strong stuff in PHP, that online CD store for the indie artists would probably not have existed for quite a long time, if ever. He's actually been online a long time, and is worth learning from, even if he never actually became a Real Programmer (tm), in his own words. PS You can find many conversations between him and me on the old, old, old PHP list before the split of the lists into -general etc. [1] http://www.cdbaby.com/About [2] http://sivers.org/trust -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones wrote: Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure' Why punish everyone by default because of Apache? Does not make sense to me. What is so difficult to grok about 1. setting up php-cgi to use fastcgi as the httpd default. 2. having parallel non-zts and zts installs of php (notably with only non-zts cli and cgi sapi's) with two different lib paths. Multiply by two again if you have parallel i686 and x86_64 installs. All of these are packager's questions anyways, as so few users do this for themself, most hosters aren't rebuilding php either. PHP would be a much nicer, friendly and more civilized development list if it borrowed only one phrase from the Perl community; TMTOWTDI. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
I think that's a bit of a stretch, to say the least. The same argument could be made that PHP 5's introduction of stronger OO implementation would have scared this person away. The fact is, we don't know that either of them would have. For one thing, I doubt he monitored the PHP Internals list; if he had, that in and of itself would have been enough to scare him away lol. If strict typing was the norm, then yeah it probably would have scared him off. But adding optional typing, which is what we've been discussing here? I seriously doubt it. --Kris On Tue, Feb 28, 2012 at 2:26 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, February 28, 2012 3:31 am, Arvids Godjuks wrote: I really liked what the O'Raily wrote here: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html Please note that the author was a bass player in a band wanting to sell CDs online when the five (5) choices were the same brick-and-mortar major label distributors who wouldn't take his CD as he wasn't on a major label. He examined the options, and PHP was the only one that didn't make his head spin. His act of creating a single page to sell his CD online went viral, and he accidentally built a multi-million dollar company because of that. Since he'd never set out to make the money, just to help his friends (and they told 2 friends, and they told 2 friends...) he always tracked success not by not, nor gross, but by dollars paid out to artists[1] He eventually sold the company to a trust fund that goes to charity when he dies, and lives very comfortably off the interest, since he lost interest in running the company when it just got too routine.[2] If he had seen this strict/weak/strong stuff in PHP, that online CD store for the indie artists would probably not have existed for quite a long time, if ever. He's actually been online a long time, and is worth learning from, even if he never actually became a Real Programmer (tm), in his own words. PS You can find many conversations between him and me on the old, old, old PHP list before the split of the lists into -general etc. [1] http://www.cdbaby.com/About [2] http://sivers.org/trust -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
I don't think the strong/weak stuff is necessary at all. Either a programmer cares about datatype or they don't and the vast, vast majority won't. Declaring a variable's datatype should have the effect of locking that variable's datatype down and not allowing it to switch types with the sole exception of NULL. Trying to declare a degree of strength to the typing is severe overkill. I recognize that I suggested this in my first proposal, but at this point I'm opposed to it. On Tue, Feb 28, 2012 at 5:39 PM, Kris Craig kris.cr...@gmail.com wrote: I think that's a bit of a stretch, to say the least. The same argument could be made that PHP 5's introduction of stronger OO implementation would have scared this person away. The fact is, we don't know that either of them would have. For one thing, I doubt he monitored the PHP Internals list; if he had, that in and of itself would have been enough to scare him away lol. If strict typing was the norm, then yeah it probably would have scared him off. But adding optional typing, which is what we've been discussing here? I seriously doubt it. --Kris On Tue, Feb 28, 2012 at 2:26 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, February 28, 2012 3:31 am, Arvids Godjuks wrote: I really liked what the O'Raily wrote here: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html Please note that the author was a bass player in a band wanting to sell CDs online when the five (5) choices were the same brick-and-mortar major label distributors who wouldn't take his CD as he wasn't on a major label. He examined the options, and PHP was the only one that didn't make his head spin. His act of creating a single page to sell his CD online went viral, and he accidentally built a multi-million dollar company because of that. Since he'd never set out to make the money, just to help his friends (and they told 2 friends, and they told 2 friends...) he always tracked success not by not, nor gross, but by dollars paid out to artists[1] He eventually sold the company to a trust fund that goes to charity when he dies, and lives very comfortably off the interest, since he lost interest in running the company when it just got too routine.[2] If he had seen this strict/weak/strong stuff in PHP, that online CD store for the indie artists would probably not have existed for quite a long time, if ever. He's actually been online a long time, and is worth learning from, even if he never actually became a Real Programmer (tm), in his own words. PS You can find many conversations between him and me on the old, old, old PHP list before the split of the lists into -general etc. [1] http://www.cdbaby.com/About [2] http://sivers.org/trust -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
I can honestly see a use for it, much as there's a use for having both include and require. It may not be a critical distinction, but it sounds like some people at least would enjoy the added flexibility. If we did only go with one, I would want it to be the strong one. But again, I think both is the best approach as it helps to bridge many of these diverging viewpoints on the subject. --Kris On Tue, Feb 28, 2012 at 2:48 PM, Michael Morris dmgx.mich...@gmail.comwrote: I don't think the strong/weak stuff is necessary at all. Either a programmer cares about datatype or they don't and the vast, vast majority won't. Declaring a variable's datatype should have the effect of locking that variable's datatype down and not allowing it to switch types with the sole exception of NULL. Trying to declare a degree of strength to the typing is severe overkill. I recognize that I suggested this in my first proposal, but at this point I'm opposed to it. On Tue, Feb 28, 2012 at 5:39 PM, Kris Craig kris.cr...@gmail.com wrote: I think that's a bit of a stretch, to say the least. The same argument could be made that PHP 5's introduction of stronger OO implementation would have scared this person away. The fact is, we don't know that either of them would have. For one thing, I doubt he monitored the PHP Internals list; if he had, that in and of itself would have been enough to scare him away lol. If strict typing was the norm, then yeah it probably would have scared him off. But adding optional typing, which is what we've been discussing here? I seriously doubt it. --Kris On Tue, Feb 28, 2012 at 2:26 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, February 28, 2012 3:31 am, Arvids Godjuks wrote: I really liked what the O'Raily wrote here: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html Please note that the author was a bass player in a band wanting to sell CDs online when the five (5) choices were the same brick-and-mortar major label distributors who wouldn't take his CD as he wasn't on a major label. He examined the options, and PHP was the only one that didn't make his head spin. His act of creating a single page to sell his CD online went viral, and he accidentally built a multi-million dollar company because of that. Since he'd never set out to make the money, just to help his friends (and they told 2 friends, and they told 2 friends...) he always tracked success not by not, nor gross, but by dollars paid out to artists[1] He eventually sold the company to a trust fund that goes to charity when he dies, and lives very comfortably off the interest, since he lost interest in running the company when it just got too routine.[2] If he had seen this strict/weak/strong stuff in PHP, that online CD store for the indie artists would probably not have existed for quite a long time, if ever. He's actually been online a long time, and is worth learning from, even if he never actually became a Real Programmer (tm), in his own words. PS You can find many conversations between him and me on the old, old, old PHP list before the split of the lists into -general etc. [1] http://www.cdbaby.com/About [2] http://sivers.org/trust -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hi, Simon.
Actually I also advocated for notices/warnings on conversion with data loss.
What just has to be done - the rule table when notices/warnings are thrown.
What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:
$a = 1;
echo gettype($a); // integer
$a = (int)1;
echo gettype($a); // integer
$a = (string)1;
echo gettype($a); // string
And so on. This part is in the language, just has different syntax.
So no-no-no from me on this:
int $a = 1;
int $a = 1;
It just duplicates the functionality. And I don't like the strict int
$a = 1; I have already explained why it's not a good idea from the
technical standpoint.
So what I want is this:
function int test(int $a, int $b)
{
return $a * $b;
}
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.
-- Forwarded message --
From: Simon Schick simonsimc...@googlemail.com
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks arvids.godj...@gmail.com
Копия: Michael Morris dmgx.mich...@gmail.com, internals@lists.php.net
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICT or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
A userland solution is possible making use of destructors to run anonymous functions (see How can I get around the lack of a finally block in PHP?http://stackoverflow.com/a/9244733/90527). However, there are a number of issues with this approach (some are outlined in the link), and language-level support would be preferable. As for implementation, would it be possible to hook into whatever PHP has in the way of frame disposal? That approach would have one of the same issues as the userland solution (finally blocks won't run until the current scope is exited), but is at least a partial solution. Would it be possible to implement partial block scope? The idea being to add some sort of guard when entering a block with an attached finally, so that when the block is exited, the finally runs. Please excuse my ignorance if none of this is viable; I'll do my homework now.
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 02/28/2012 02:29 PM, William A. Rowe Jr. wrote: On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones wrote: Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure' Why punish everyone by default because of Apache? Does not make sense to me. What is so difficult to grok about 1. setting up php-cgi to use fastcgi as the httpd default. 2. having parallel non-zts and zts installs of php (notably with only non-zts cli and cgi sapi's) with two different lib paths. Multiply by two again if you have parallel i686 and x86_64 installs. All of these are packager's questions anyways, as so few users do this for themself, most hosters aren't rebuilding php either. PHP would be a much nicer, friendly and more civilized development list if it borrowed only one phrase from the Perl community; TMTOWTDI. These are useful suggestions for a future bigger picture direction about sensible defaults, usability (or lack of), php-fpm, etc. This is a problem looking for an owner. In the narrow confines of https://bugs.php.net/bug.php?id=61172 the packager has deliberately chosen to install mod_php. Like Sebastian, I prefer that PHP configures itself for the currently installed Apache MPM. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Much of what you put forward here is why I don't want there to be a
weak/strong divide. We can do weak. Strong not so much. Current
syntax allows
$a = (int) 3;
echo gettype($a); // integer
$a = 'Hello';
echo gettype($a); // string.
Under the new syntax this happens.
int $a = 3;
echo gettype($a); // integer
$a = 'Hello';
E_WARNING raised
echo gettype($a); // integer
In other words, once the variable's type is declared, it WILL NOT
CHANGE. If one doesn't want that behavior, don't declare a type, and
things will work as they always have.
On Tue, Feb 28, 2012 at 5:56 PM, Arvids Godjuks
arvids.godj...@gmail.com wrote:
Hi, Simon.
Actually I also advocated for notices/warnings on conversion with data loss.
What just has to be done - the rule table when notices/warnings are thrown.
What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:
$a = 1;
echo gettype($a); // integer
$a = (int)1;
echo gettype($a); // integer
$a = (string)1;
echo gettype($a); // string
And so on. This part is in the language, just has different syntax.
So no-no-no from me on this:
int $a = 1;
int $a = 1;
It just duplicates the functionality. And I don't like the strict int
$a = 1; I have already explained why it's not a good idea from the
technical standpoint.
So what I want is this:
function int test(int $a, int $b)
{
return $a * $b;
}
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type hint
now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.
-- Forwarded message --
From: Simon Schick simonsimc...@googlemail.com
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks arvids.godj...@gmail.com
Копия: Michael Morris dmgx.mich...@gmail.com, internals@lists.php.net
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICT or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
One thing I've been noticing, and I think we should be careful of in this
discussion, is making broad and this is what most people want
statements. I've heard a number of people make some variation of that
claim now to support at-times radically different approaches. So, unless
most people want *everything*, including the things that directly
contradict one another, then I think it's safe to say that some of us are
giving in to the temptation to use hyperbole. It's understandable and I've
probably done it myself on more than one occasion. But I think we have to
be careful not to make such claims unless we actually have data to back
them up.
None of us can *credibly* state that one approach or another is supported
by most people or most developers, etc. Unless somebody can product a
scientific poll on the subject, there is no clear majority consensus on
this. If there was, we wouldn't still be having this discussion after so
many years.
So please, let's all be careful not to make baseless claims about most
(insert plural noun here) supporting one idea or another. All it does is
add needless confusion and clutter to an already complex issue.
--Kris
On Tue, Feb 28, 2012 at 2:56 PM, Arvids Godjuks arvids.godj...@gmail.comwrote:
Hi, Simon.
Actually I also advocated for notices/warnings on conversion with data
loss.
What just has to be done - the rule table when notices/warnings are thrown.
What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:
$a = 1;
echo gettype($a); // integer
$a = (int)1;
echo gettype($a); // integer
$a = (string)1;
echo gettype($a); // string
And so on. This part is in the language, just has different syntax.
So no-no-no from me on this:
int $a = 1;
int $a = 1;
It just duplicates the functionality. And I don't like the strict int
$a = 1; I have already explained why it's not a good idea from the
technical standpoint.
So what I want is this:
function int test(int $a, int $b)
{
return $a * $b;
}
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type hint
now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.
-- Forwarded message --
From: Simon Schick simonsimc...@googlemail.com
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks arvids.godj...@gmail.com
Копия: Michael Morris dmgx.mich...@gmail.com, internals@lists.php.net
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICT or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
@Rick Though I'm not sure I'd agree with the overly broad it is no longer PHP hyperbole, I think the basic point that it would be a significant departure from the current model has merit. So ok, you've convinced me. That example should not throw any errors. I'm officially no longer on the fence with that. =) --Kris On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.comwrote: On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Agreed. If conversion can occur without data loss (that is, if the value being assigned is == the value that actually IS assigned) then no error should occur. So int $a = 1; // no error. 1 == 1 so who cares? int $a = 'House'; // error 0 != 'House', so this is a problem. Again, errors should only raise if the final value != source value. On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer vch...@developersdesk.com wrote: On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
+1 on that. However, I believe the coder should also have the option of determining whether this should be recoverable or not, just like they have a choice with regard to using include or require (one fails gracefully, the other terminates execution). That's where I think strong/weak could be very useful. Here's how I would do it: weak int $a = House; // Throws E_WARNING strong int $a = House; // Throws E_RECOVERABLE_ERROR In both cases, the error can be caught, which would mirror the flexibility in languages like C#. However, if the weak one isn't caught, the warning is thrown but the script proceeds as normal. If the strong one isn't caught, the script will terminate as if it was an E_ERROR. I think this would be the most sensible approach in terms of balancing simplicity and flexibility. --Kris On Tue, Feb 28, 2012 at 3:08 PM, Michael Morris dmgx.mich...@gmail.comwrote: Agreed. If conversion can occur without data loss (that is, if the value being assigned is == the value that actually IS assigned) then no error should occur. So int $a = 1; // no error. 1 == 1 so who cares? int $a = 'House'; // error 0 != 'House', so this is a problem. Again, errors should only raise if the final value != source value. On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer vch...@developersdesk.com wrote: On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
Hi! As for implementation, would it be possible to hook into whatever PHP has in the way of frame disposal? That approach would have one of the same issues as the userland solution (finally blocks won't run until the current scope is exited), but is at least a partial solution. Would it be No, partial solution is a no go. The solution should work like finally is expected to work - finally block executed after the control leaves try/catch/finally construct in any way. There are non-trivial things to solve there - like how to correctly pass control if we have multiple nested blocks or nested blocks inside finally, etc. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
It's better to have it blow up in all cases then. Avoiding the break is trivial
int $a = (int) 3;
And this example illustrates cleanly the difference between this
proposal and casting by itself. Introducing this creates a new level
of typing, for a total of two. Your proposal creates 3, which is 1
too many.
On Tue, Feb 28, 2012 at 6:36 PM, Kris Craig kris.cr...@gmail.com wrote:
But again, that same argument could be used to eliminate the require()
function, which is something that I and many other developers use quite
frequently.
There are cases where I would want my script to blow-up and stop executing,
such as if an included script could not be loaded (hence require); or,
given the right circumstances, when my script is relying on a variable that,
as a result of some unanticipated behavior, receives an incompatible value
for its type.
After all, just look at how many PHP scripts out there already do this
manually; i.e. terminating the script (with die() or some other means) if
the variable doesn't pass a bulky and convoluted sanity check. All that
code could be eliminated by simply having the strong type, since that would
now be done for you at the lower level. There are other cases where this
sort of conflict would be undesirable but the coder might still want the
script to proceed anyway, hence the need for the weak type. There are
valid, real-world use cases for both.
--Kris
On Tue, Feb 28, 2012 at 3:30 PM, Michael Morris dmgx.mich...@gmail.com
wrote:
I don't see a point in two error levels. Either the coder cares or
they don't. Further, there are mechanisms already in place.
int $a = 'House'; // Warning.
@ int $a = 'House'; // No warning because the suppression operator was
used.
If you need something more than a warning you can code it. Let's use a
real world example
@int $id = $_POST['id'];
if ($id != $_POST['id']) {
throw MyValidationException();
}
In the language as it stands we have
$id = (int) $_POST['id'];
if ($id != $_POST['id']) {
throw MyValidationException();
}
So we have the means to make things secure. The one thing, the only
thing this is really going to give, is to prevent $a from changing
type.
To be honest, this isn't useful with solo programmers. Where it will
be useful is with teams and API enforcement.
This whole strong/weak keywording is a Very Bad Idea(TM) IMHO. Weak
can already be done with casting.
On Tue, Feb 28, 2012 at 6:17 PM, Kris Craig kris.cr...@gmail.com wrote:
+1 on that.
However, I believe the coder should also have the option of determining
whether this should be recoverable or not, just like they have a choice
with
regard to using include or require (one fails gracefully, the other
terminates execution).
That's where I think strong/weak could be very useful. Here's how I
would
do it:
weak int $a = House; // Throws E_WARNING
strong int $a = House; // Throws E_RECOVERABLE_ERROR
In both cases, the error can be caught, which would mirror the
flexibility
in languages like C#. However, if the weak one isn't caught, the
warning is
thrown but the script proceeds as normal. If the strong one isn't
caught,
the script will terminate as if it was an E_ERROR.
I think this would be the most sensible approach in terms of balancing
simplicity and flexibility.
--Kris
On Tue, Feb 28, 2012 at 3:08 PM, Michael Morris dmgx.mich...@gmail.com
wrote:
Agreed. If conversion can occur without data loss (that is, if the
value being assigned is == the value that actually IS assigned) then
no error should occur.
So
int $a = 1; // no error. 1 == 1 so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.
Again, errors should only raise if the final value != source value.
On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer
vch...@developersdesk.com
wrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an
error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Why is that 1 too many, exactly?
Like I said, I would be ok with just having it behave as strong without the
distinction, though that might be a harder sell for some people. On the
other hand, having it just behave as weak without the option to blow it up
would also be a harder sell for some people, myself included. That's why,
from a pragmatic standpoint at least, having both levels makes the most
sense without really having any glaring drawbacks, aside from the fact that
some people might see it as superfluous.
--Kris
On Tue, Feb 28, 2012 at 3:41 PM, Michael Morris dmgx.mich...@gmail.comwrote:
It's better to have it blow up in all cases then. Avoiding the break is
trivial
int $a = (int) 3;
And this example illustrates cleanly the difference between this
proposal and casting by itself. Introducing this creates a new level
of typing, for a total of two. Your proposal creates 3, which is 1
too many.
On Tue, Feb 28, 2012 at 6:36 PM, Kris Craig kris.cr...@gmail.com wrote:
But again, that same argument could be used to eliminate the require()
function, which is something that I and many other developers use quite
frequently.
There are cases where I would want my script to blow-up and stop
executing,
such as if an included script could not be loaded (hence require); or,
given the right circumstances, when my script is relying on a variable
that,
as a result of some unanticipated behavior, receives an incompatible
value
for its type.
After all, just look at how many PHP scripts out there already do this
manually; i.e. terminating the script (with die() or some other means) if
the variable doesn't pass a bulky and convoluted sanity check. All that
code could be eliminated by simply having the strong type, since that
would
now be done for you at the lower level. There are other cases where this
sort of conflict would be undesirable but the coder might still want the
script to proceed anyway, hence the need for the weak type. There are
valid, real-world use cases for both.
--Kris
On Tue, Feb 28, 2012 at 3:30 PM, Michael Morris dmgx.mich...@gmail.com
wrote:
I don't see a point in two error levels. Either the coder cares or
they don't. Further, there are mechanisms already in place.
int $a = 'House'; // Warning.
@ int $a = 'House'; // No warning because the suppression operator was
used.
If you need something more than a warning you can code it. Let's use a
real world example
@int $id = $_POST['id'];
if ($id != $_POST['id']) {
throw MyValidationException();
}
In the language as it stands we have
$id = (int) $_POST['id'];
if ($id != $_POST['id']) {
throw MyValidationException();
}
So we have the means to make things secure. The one thing, the only
thing this is really going to give, is to prevent $a from changing
type.
To be honest, this isn't useful with solo programmers. Where it will
be useful is with teams and API enforcement.
This whole strong/weak keywording is a Very Bad Idea(TM) IMHO. Weak
can already be done with casting.
On Tue, Feb 28, 2012 at 6:17 PM, Kris Craig kris.cr...@gmail.com
wrote:
+1 on that.
However, I believe the coder should also have the option of
determining
whether this should be recoverable or not, just like they have a
choice
with
regard to using include or require (one fails gracefully, the
other
terminates execution).
That's where I think strong/weak could be very useful. Here's how I
would
do it:
weak int $a = House; // Throws E_WARNING
strong int $a = House; // Throws E_RECOVERABLE_ERROR
In both cases, the error can be caught, which would mirror the
flexibility
in languages like C#. However, if the weak one isn't caught, the
warning is
thrown but the script proceeds as normal. If the strong one isn't
caught,
the script will terminate as if it was an E_ERROR.
I think this would be the most sensible approach in terms of balancing
simplicity and flexibility.
--Kris
On Tue, Feb 28, 2012 at 3:08 PM, Michael Morris
dmgx.mich...@gmail.com
wrote:
Agreed. If conversion can occur without data loss (that is, if the
value being assigned is == the value that actually IS assigned) then
no error should occur.
So
int $a = 1; // no error. 1 == 1 so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.
Again, errors should only raise if the final value != source value.
On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer
vch...@developersdesk.com
wrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an
error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Re: [PHP-DEV] Scalar type hinting
On Wed, Feb 29, 2012 at 7:08 AM, Michael Morris dmgx.mich...@gmail.com wrote: Agreed. If conversion can occur without data loss (that is, if the value being assigned is == the value that actually IS assigned) then no error should occur. So int $a = 1; // no error. 1 == 1 so who cares? int $a = 'House'; // error 0 != 'House', so this is a problem. Actually, 0 == 'House' ;-) Again, errors should only raise if the final value != source value. On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer vch...@developersdesk.com wrote: On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
Richard,
This is not overloading addition. Not by a long shot.
This is overloading casting to primitives (which happens in the case
of addition, but a bunch of others). It turns out that the addition
operator calls object-get in C to get the primitive value of the
object if it exists. That's where this works. So:
This obviously trivial example makes perfect sense, until you realize
that some moron (and PHP has lots of them) will sooner or later make
++ do something completely weird, and I'm going to have to edit their
code-base and will have to dig through umpteen class files to figure
out what the heck ++ means...
Yes, the example is trivial. And yes, it can be abused. But I think
you're blowing it WAY out of proportion. ++ still means what it
always has meant. It's the *exact* same as normal (addition is still
happening).
The only change is where the addition gets its value, and where that
value is stored.
And it's not really digging through umpteen classes to figure out what
the cast is. To be honest, you could say the exact same thing about
polymorphism. And the indirection there is actually seen as a *good*
thing. So I'm not sure what argument you're trying to make aside from
that you don't like it...
And then god knows what happens when you do:
$foo = new Foo(); //from library A
$bar = new Bar(); //from library B
$foobar = $foo + $bar;
//Will this last statement even make sense, even though both Foo and
Bar override the + operator, just in entirely different ways...
Neither override anything. let me say this again: THIS IS NOT DOING
OPERATOR OVERLOADING.
That's 100% predictable. Lookup Foo and Bar, and see if either/both
implement __castTo. If so, the types they return will tell you
exactly what it will be.
How can you even guarantee that $foo, presumably taking precedence,
won't attempt to access a non-existent property of Bar, generating an
ignored E_NOTICE on most hosts, and introduce a subtle bug that nobody
notices for months, even years, in a seldom-used function?
You don't need to. Because $foo will never know about $bar (or vise versa)...
And to be honest, you could say the same thing about LOTS of existing
NON-MAGIC functionality. So I don't see that this contributes to the
conversation at all...
Your proposal lets one re-define + to mean whatever one wants, and
while you might not abuse that, somebody else will...
Ok, This is rediculous. Open the patch. Tell me where it redefines
+, or even remotely can be used to... + is still a scalar operator,
and with this patch you cannot change that. The only thing this patch
lets you do with respect to the + operator is choose what the scalar
representation of the object is...
Personal Note:
I appreciate replies and concerns. But at least read the patch and
try to understand what the POC does before going off on a rant that
does nothing but turn people off unless you actually realize what's
going on. If you don't understand what it does, then ask. But don't
complain about things the feature doesn't even touch, it's
disrespectful and doesn't accomplish anything but to add noise to the
conversation.
Anthony
On Tue, Feb 28, 2012 at 4:37 PM, Richard Lynch c...@l-i-e.com wrote:
On Mon, February 27, 2012 11:05 pm, Anthony Ferrara wrote:
?php
class Foo {
public $value = 1;
}
class Bar {
public $value = 1;
public function __castTo($type) {
return $this-value;
}
public function __assign($value) {
$this-value = $value;
return $value != 10;
}
}
$a = new Foo;
$b = new Bar;
$a++;
So, here's the thing...
This obviously trivial example makes perfect sense, until you realize
that some moron (and PHP has lots of them) will sooner or later make
++ do something completely weird, and I'm going to have to edit their
code-base and will have to dig through umpteen class files to figure
out what the heck ++ means...
I can see a lot of legitimate serious coders using this wisely.
Unfortunately, I can see a million scripters using it very un-wisely.
I can even see people overloading the plus operator for an object
wrapped around an array in multiple different ways, then pulling in
different libraries that seem quite useful, and the only way I can
figure out what + means is to dig through even more files and figure
out which bastard child this object comes from, that was passed into
some random function that uses + on it.
And then god knows what happens when you do:
$foo = new Foo(); //from library A
$bar = new Bar(); //from library B
$foobar = $foo + $bar;
//Will this last statement even make sense, even though both Foo and
Bar override the + operator, just in entirely different ways...
How can you even guarantee that $foo, presumably taking precedence,
won't attempt to access a non-existent property of Bar, generating an
ignored E_NOTICE on most hosts, and introduce a subtle bug that nobody
notices for months, even
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
I think this is +1 for moving the conversation to a less crowded location.
Sorry guys I know I keep promising to take care of it but I've been swamped
all day. I'll try to find some time though.
--Kris
On Tue, Feb 28, 2012 at 4:28 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Richard,
This is not overloading addition. Not by a long shot.
This is overloading casting to primitives (which happens in the case
of addition, but a bunch of others). It turns out that the addition
operator calls object-get in C to get the primitive value of the
object if it exists. That's where this works. So:
This obviously trivial example makes perfect sense, until you realize
that some moron (and PHP has lots of them) will sooner or later make
++ do something completely weird, and I'm going to have to edit their
code-base and will have to dig through umpteen class files to figure
out what the heck ++ means...
Yes, the example is trivial. And yes, it can be abused. But I think
you're blowing it WAY out of proportion. ++ still means what it
always has meant. It's the *exact* same as normal (addition is still
happening).
The only change is where the addition gets its value, and where that
value is stored.
And it's not really digging through umpteen classes to figure out what
the cast is. To be honest, you could say the exact same thing about
polymorphism. And the indirection there is actually seen as a *good*
thing. So I'm not sure what argument you're trying to make aside from
that you don't like it...
And then god knows what happens when you do:
$foo = new Foo(); //from library A
$bar = new Bar(); //from library B
$foobar = $foo + $bar;
//Will this last statement even make sense, even though both Foo and
Bar override the + operator, just in entirely different ways...
Neither override anything. let me say this again: THIS IS NOT DOING
OPERATOR OVERLOADING.
That's 100% predictable. Lookup Foo and Bar, and see if either/both
implement __castTo. If so, the types they return will tell you
exactly what it will be.
How can you even guarantee that $foo, presumably taking precedence,
won't attempt to access a non-existent property of Bar, generating an
ignored E_NOTICE on most hosts, and introduce a subtle bug that nobody
notices for months, even years, in a seldom-used function?
You don't need to. Because $foo will never know about $bar (or vise
versa)...
And to be honest, you could say the same thing about LOTS of existing
NON-MAGIC functionality. So I don't see that this contributes to the
conversation at all...
Your proposal lets one re-define + to mean whatever one wants, and
while you might not abuse that, somebody else will...
Ok, This is rediculous. Open the patch. Tell me where it redefines
+, or even remotely can be used to... + is still a scalar operator,
and with this patch you cannot change that. The only thing this patch
lets you do with respect to the + operator is choose what the scalar
representation of the object is...
Personal Note:
I appreciate replies and concerns. But at least read the patch and
try to understand what the POC does before going off on a rant that
does nothing but turn people off unless you actually realize what's
going on. If you don't understand what it does, then ask. But don't
complain about things the feature doesn't even touch, it's
disrespectful and doesn't accomplish anything but to add noise to the
conversation.
Anthony
On Tue, Feb 28, 2012 at 4:37 PM, Richard Lynch c...@l-i-e.com wrote:
On Mon, February 27, 2012 11:05 pm, Anthony Ferrara wrote:
?php
class Foo {
public $value = 1;
}
class Bar {
public $value = 1;
public function __castTo($type) {
return $this-value;
}
public function __assign($value) {
$this-value = $value;
return $value != 10;
}
}
$a = new Foo;
$b = new Bar;
$a++;
So, here's the thing...
This obviously trivial example makes perfect sense, until you realize
that some moron (and PHP has lots of them) will sooner or later make
++ do something completely weird, and I'm going to have to edit their
code-base and will have to dig through umpteen class files to figure
out what the heck ++ means...
I can see a lot of legitimate serious coders using this wisely.
Unfortunately, I can see a million scripters using it very un-wisely.
I can even see people overloading the plus operator for an object
wrapped around an array in multiple different ways, then pulling in
different libraries that seem quite useful, and the only way I can
figure out what + means is to dig through even more files and figure
out which bastard child this object comes from, that was passed into
some random function that uses + on it.
And then god knows what happens when you do:
$foo = new Foo(); //from library A
$bar = new Bar(); //from library B
$foobar =
RE: [PHP-DEV] Scalar type hinting
-Original Message- From: Rick WIdmer [mailto:vch...@developersdesk.com] On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). [If] this is an error, it is no longer PHP. Rick, I know what you are getting at, and I even agree that this won't work, but please let's avoid extreme aggressive statements. This shuts down the discussion and just makes people angry at you. This is no longer PHP is an aggressive complaint that doesn't help anyone understand why this construct is a problem. Instead, please articulate the core problem with the proposal. In this case a better response would be something like: This re-opens the viral poisoning problem with strict typing that's already been discussed. We can't do this unless you can solve that problem.. Thanks, John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar type hinting
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.comwrote: On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. @Rick Though I'm not sure I'd agree with the overly broad it is no longer PHP hyperbole, I think the basic point that it would be a significant departure from the current model has merit. So ok, you've convinced me. That example should not throw any errors. I'm officially no longer on the fence with that. =) --Kris OK, if we're all on the same page there, I think this means that there is no significant difference between the strong int and weak int in your proposal (the only remaining difference being the level of error raised when it cannot be converted, which IMO is not substantial enough to deserve a keyword.) I'd prefer to just pick one error level to use (E_RECOVERABLE_ERROR would be the most consistent) and keep everything simple. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar type hinting
I would personally be inclined towards something simpler like E_NOTICE or E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we should be consistent, and the consistency argument may make the difference. There may be a strong case for changing the error level on all type hints to something simpler (or new, like E_TYPE), but I think that might be better to tackle that in a separate discussion. John Crenshaw Priacta, Inc. From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 8:40 PM To: John Crenshaw Cc: Rick WIdmer; internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting I wouldn't mind that, though I'm concerned that it may not be sellable because some people on here have expressed a strong opinion that this shouldn't throw anything more than a notice or a warning at most, something that I and others strongly disagree with. The logical approach, to me at least, is to follow the example of include() and require(); i.e. they're both identical except that one throws a scary error while the other one is just a warning. I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may alienate too many people for us to be able to get this through. Though it's possible I might be overestimating that factor. --Kris On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrens...@priacta.commailto:johncrens...@priacta.com wrote: On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.commailto:vch...@developersdesk.comwrote: On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. @Rick Though I'm not sure I'd agree with the overly broad it is no longer PHP hyperbole, I think the basic point that it would be a significant departure from the current model has merit. So ok, you've convinced me. That example should not throw any errors. I'm officially no longer on the fence with that. =) --Kris OK, if we're all on the same page there, I think this means that there is no significant difference between the strong int and weak int in your proposal (the only remaining difference being the level of error raised when it cannot be converted, which IMO is not substantial enough to deserve a keyword.) I'd prefer to just pick one error level to use (E_RECOVERABLE_ERROR would be the most consistent) and keep everything simple. John Crenshaw Priacta, Inc.
[PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Hey all, I've created a draft version of the RFC for implementing __castTo() and __assign(): https://wiki.php.net/rfc/object_cast_magic It's still a draft, and has a lot more work to do, but I figured this would be enough to start triggering some discussion (or at least a little bit more focused discussion). One plea: Please keep this thread on-topic discussing the RFC and its implications... Thanks! Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Agreed. Discussion about type hinting/etc should remain on the other topics. Regarding this proposal, I need to look over it in more detail as I've only just skimmed it. But on a conceptual level at least, I think it definitely has merit. --Kris On Tue, Feb 28, 2012 at 6:40 PM, Anthony Ferrara ircmax...@gmail.comwrote: Hey all, I've created a draft version of the RFC for implementing __castTo() and __assign(): https://wiki.php.net/rfc/object_cast_magic It's still a draft, and has a lot more work to do, but I figured this would be enough to start triggering some discussion (or at least a little bit more focused discussion). One plea: Please keep this thread on-topic discussing the RFC and its implications... Thanks! Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Hi!
Hey all,
I've created a draft version of the RFC for implementing __castTo()
and __assign():
https://wiki.php.net/rfc/object_cast_magic
I think having cast method may have merits, though use cases where
objects need to be converted to scalars that aren't string are very
limited, and cases where they need to do so transparently are almost
non-existent. I think what outlined in the RFC is a backdoor operator
overloading, through rather complex and unobvious magic. My opinion is
that outside of very limited number of cases (such as implementing
complex numbers or matrix algebra - and how frequently would one need do
that in PHP anyway?) operator overloading is way more trouble than it's
worth and makes code nearly unreadable as you never know what exactly
each operator does. For example, if($object) would have completely
different semantics than before, for some objects but not other, and
without any obvious clue to the user what it actually does - and all
that to save couple of keystrokes on if($object-valid())?
Still, if there's a valid use case found, cast magic method and
unboxing method may have merit. So far the cases outlined seem either
too artificial and narrow for language-level functionality, or plain
wrong (like SplFixedArray example - nothing in this proposal would
enable it to work with sort, for example). But I do not exclude other
cases can exist.
However, assignment overloading does not seem viable to me.
Also, I'm not sure how this is possible technically: $obj = {expression}
is supposed to replace $obj with the result of the expression, not call
methods on $obj. Doing otherwise would be huge change in the semantics,
a complete no go. Also, it's impossible if $obj is not set - meaning,
code $obj = 1 would mean totally different things depending on if $obj
is set or not - again, not a good idea. It also does not cover many
corner cases but I don't even want to go there since an idea to change
semantics of the assignment seems very wrong to me in principle, so no
need to go into the fine details.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Newbie: issues developing a new extension
Dear all, I'm asking your help because I'm not able to solve an issue probably related to some foolish mistake I have not yet discovered. I'm trying to develop an experimental extension to interface LIXA library (http:/lixa.sourceforge.net/). I have created the basic stuff (config.m4, lixa.c, php_lixa.h and so on). If I use this sequence from the ext/lixa directory: /opt/php/bin/phpize ./configure --help I can see the lixa extension is available: [...] Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-libdir=NAME Look for libraries in .../NAME rather than .../lib --with-php-config=PATH Path to php-config php-config --with-lixa=FILE Include LIXA support. File is the path to lixa-config [...] and I can compile with: ./configure --with-lixa=/opt/lixa/bin/lixa-config --with-php-config=/opt/php/bin/php-config the build process runs as expected and the extension is available after an addition to php.ini (extension=[...]/ext/lixa/modules/lixa.so). Great, you are done. Why do you want to go any further than this? You built your extension and it is available from PHP exactly like any pecl extension. and if you're using apache, reboot it and check your phpinfo() page for your extension. if you're connected up via the command line you can run php -m to see if your modules exists. -Rasmus Dear all, I would like to see my extension as any other extension, like MySQL, PostgreSQL, Oracle and so on because: 1. LIXA itself is useless without those resource managers 2. I need to patch other extensions to implement the interfaces between LIXA and MySQL/PostgreSQL/Oracle. What's the difference between an internal extension (like MySQL/PostgreSQL/Oracle) and an external extension as the one I produced? Thanks in advance, your help is precious. Ch.F. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Newbie: issues developing a new extension
On Wed, Feb 29, 2012 at 08:50, Christian Ferrari cam...@yahoo.com wrote: Dear all, I'm asking your help because I'm not able to solve an issue probably related to some foolish mistake I have not yet discovered. I'm trying to develop an experimental extension to interface LIXA library (http:/lixa.sourceforge.net/). I have created the basic stuff (config.m4, lixa.c, php_lixa.h and so on). If I use this sequence from the ext/lixa directory: /opt/php/bin/phpize ./configure --help I can see the lixa extension is available: [...] Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-libdir=NAME Look for libraries in .../NAME rather than .../lib --with-php-config=PATH Path to php-config php-config --with-lixa=FILE Include LIXA support. File is the path to lixa-config [...] and I can compile with: ./configure --with-lixa=/opt/lixa/bin/lixa-config --with-php-config=/opt/php/bin/php-config the build process runs as expected and the extension is available after an addition to php.ini (extension=[...]/ext/lixa/modules/lixa.so). Great, you are done. Why do you want to go any further than this? You built your extension and it is available from PHP exactly like any pecl extension. and if you're using apache, reboot it and check your phpinfo() page for your extension. if you're connected up via the command line you can run php -m to see if your modules exists. -Rasmus Dear all, I would like to see my extension as any other extension, like MySQL, PostgreSQL, Oracle and so on because: 1. LIXA itself is useless without those resource managers 2. I need to patch other extensions to implement the interfaces between LIXA and MySQL/PostgreSQL/Oracle. What's the difference between an internal extension (like MySQL/PostgreSQL/Oracle) and an external extension as the one I produced? Thanks in advance, your help is precious. The PHP source archive bundles several extensions under the ext/ directory, these are the extensions are listed when you run ./configure --help I don't understand why you want your extension to show up there, but to do so you have to place your extension in that folder and run ./buildconf --force PHP will not automatically scan your filesystem for possible extension directories to list them under ./configure I'm sure you have seen, and used, http://pecl.php.net - these extensions don't show up when you build PHP. The standard way to build external extensions however is to use pecl, or manually build them as shared modules (as you did first). -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
