Re: [PHP-DEV] Strict typing (was: Typehints)
At 01:47 11/08/2010, Stas Malyshev wrote: Hi! For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I agree completely. The fact that obvious absence of consensus is ignored and we are releasing feature that clearly has no consensus behind it as a part of an official release - when we have killed much lesser things for much lesser reasons - I think it is a very bad development. I agree completely too. We've also had quite a lengthy discussion on this topic, and there was more support for 'weak' typing then there was for strict typing. The response to Johannes's blog also don't leave much room for speculation regarding what the community at large thinks. Facts: - When we introduced type hints, one of the 'conditions' were that we'll never, ever have type hints for scalars - for many different reasons - the strongest of which it simply doesn't fit PHP's theme. - We managed to come up with an alternative solution, in the form of auto-converting type hints for scalars, which does in fact fit PHP's theme perfectly. - I suggested we actually take the opportunity to slightly modify PHP's conversion rules in esoteric cases, where our historical decision is probably not the right one (e.g., silently converting abc into 0 in case of integer context - instead emit a new E_TYPE warning that would be off by default). My view in terms of preferences: #1 - Auto-converting type hints + minor changes to PHP's conversion rules #2 - Auto-converting type hints #3 - Doing nothing #inf - Introducing strict typing into PHP (current trunk status) As Stas said - there's clearly anything but consensus around strict typing, so our 'default' in case we can't reach agreement is #3 - the status quo. As everyone told me when this feature was committed to trunk - it doesn't mean anything, it's just trunk. Let's stand behind that statement and revert it. Strict typing should go away before any 'official' package comes out of php.net. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski z...@zend.com wrote: At 01:47 11/08/2010, Stas Malyshev wrote: Hi! For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I agree completely. The fact that obvious absence of consensus is ignored and we are releasing feature that clearly has no consensus behind it as a part of an official release - when we have killed much lesser things for much lesser reasons - I think it is a very bad development. I agree completely too. We've also had quite a lengthy discussion on this topic, and there was more support for 'weak' typing then there was for strict typing. The response to Johannes's blog also don't leave much room for speculation regarding what the community at large thinks. Facts: - When we introduced type hints, one of the 'conditions' were that we'll never, ever have type hints for scalars - for many different reasons - the strongest of which it simply doesn't fit PHP's theme. - We managed to come up with an alternative solution, in the form of auto-converting type hints for scalars, which does in fact fit PHP's theme perfectly. - I suggested we actually take the opportunity to slightly modify PHP's conversion rules in esoteric cases, where our historical decision is probably not the right one (e.g., silently converting abc into 0 in case of integer context - instead emit a new E_TYPE warning that would be off by default). My view in terms of preferences: #1 - Auto-converting type hints + minor changes to PHP's conversion rules #2 - Auto-converting type hints #3 - Doing nothing #inf - Introducing strict typing into PHP (current trunk status) As Stas said - there's clearly anything but consensus around strict typing, so our 'default' in case we can't reach agreement is #3 - the status quo. As everyone told me when this feature was committed to trunk - it doesn't mean anything, it's just trunk. Let's stand behind that statement and revert it. Strict typing should go away before any 'official' package comes out of php.net. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 (All of what Zeev said) -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
Re: [PHP-DEV] Strict typing
Zeev Suraski wrote: Strict typing should go away before any 'official' package comes out of php.net. +1 from me as well. And it is nice to hear that I'm not on my own in that ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Hi! I'm sorry but I have no idea what you're talking about there =\ PHP has a bunch of different types, the current type hinting (typechecking int is a different kind of type from Zend_Controller_Factory and SimpleXML - the same kind of types are int and object. The former are engine types (IS_INTEGER, IS_OBJECT), the latter are classes. I very much can, it's just not my intention. I want to be able to use type hinting/type checking as a sanity check. If I write a method whose signature is foo(int $n) I signal my intention to only accept Then you should use statically typed language. There's no law saying every code on the planet should be written in PHP, and PHP is not a statically typed language. So by bolting static typing onto it you are using wrong tool for the job. If PHP was meant to prevent programmers from controlling the type of their variables then I'm afraid there's been a misunderstanding and PHP and dynamic languages in general are not preventing people from knowing the types of variables, they however remove a number of annoyances that come with static types. You want to bring all those back - and that without the benefits that are compensating for those annoyances in compiled languages - meaning being sure upfront that the code always gets proper data in proper places. You don't know that unless you statically type and compile your whole code - so you just traded flexibility and API agility for nothing. I'm not sure what you meant by objects of classes can not [be converted into another type]. Arrays can be cast as booleans (false There are no generic rules that allow conversion between two classes - such as SimpleXML and Exception, for example. In general, conversions between classes don't happen in the engine. Conversion between IS_* types happen all the time. TL;DR: I always thought PHP would help me control the type of my variables instead of forcing my userland code to mirror PHP's internal functions. If you want strict typing (control the type of my variables) I'm afraid you're using not only wrong language but wrong paradigm. You should be using statically typed language. Try C# or Java or Scala or something like that. Just having parameter typing won't help you - you'd just kick the problem around the code, it will be now it variables upstream, 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] Strict typing (was: Typehints)
Completly agree with Zeev, most russian comunity is for the weak type hinting. Many would like strict, but most of the pro strict type hinters understand that PHP and strict type hinting not match and vote for type hints with auto converting. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
+1. Strict typing will only prevent PHP from being itself, while not providing the advantages of a real statically types language (as Stas Malyshev has mentioned in another thread of discussion). 2010/8/11 Arvids Godjuks arvids.godj...@gmail.com: Completly agree with Zeev, most russian comunity is for the weak type hinting. Many would like strict, but most of the pro strict type hinters understand that PHP and strict type hinting not match and vote for type hints with auto converting. -- 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] Strict typing (was: Typehints)
Hi, why are we discussing this again? get the RFC's fixed up (though I would assume by now they are already) and do a vote and of story without a vote the status quo from the last release should be maintained for such a controversial feature, aka if there is no consensus then the strict type check changes should be moved to a feature branch. just committing, and then try to wait for a moment when nobody complains (guess it didnt work this time) to release the commit has been done before i guess, but its not the way to go .. for obvious reasons. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Annoucing PHP 5.4 Alpha 1
On Tue, 2010-08-10 at 22:52 -0700, Clint Byrum wrote: So, support the LTS versions of PHP, and let developers try out new features in a hassle free manner with these interim releases. We can't try out changes in the core language. (individual developers may of course provide patches, but not in the form of official releases) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On Wed, Aug 11, 2010 at 8:03 AM, Zeev Suraski z...@zend.com wrote: Facts: There are two facts that matter right now, imo: - There is no 5.4 or whatever other version as of now. - There is no RM either. I don't know why nobody cares (well I do ;), but this is totally insane. Do we ever learn? PHP6, the last 5.4 horrible episode, etc. And as we clearly see today, we are not ready. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get script filename in module RINIT function
On 9 August 2010 12:32, Bostjan Skufca bost...@a2o.si wrote: Hi all! I am developing a small PHP extension and I ATM can't figure out how to get to $_SERVER['SCRIPT_FILENAME'] content while in PHP_RINIT or PHP_RSHUTDOWN function. Can someone please hint me with this one? Thanks, b. If the script is run via the command line (in my limited experience, this would be the CLI, CGI, FastCGI SAPIs, others also maybe), can't you look through the command line parameters? -- Richard Quadling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
I think that weak type-hinting defeats the whole purpose of the feature and I would rather not have it than have a non-obvious implementation. -1 On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski z...@zend.com wrote: At 01:47 11/08/2010, Stas Malyshev wrote: Hi! For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I agree completely. The fact that obvious absence of consensus is ignored and we are releasing feature that clearly has no consensus behind it as a part of an official release - when we have killed much lesser things for much lesser reasons - I think it is a very bad development. I agree completely too. We've also had quite a lengthy discussion on this topic, and there was more support for 'weak' typing then there was for strict typing. The response to Johannes's blog also don't leave much room for speculation regarding what the community at large thinks. Facts: - When we introduced type hints, one of the 'conditions' were that we'll never, ever have type hints for scalars - for many different reasons - the strongest of which it simply doesn't fit PHP's theme. - We managed to come up with an alternative solution, in the form of auto-converting type hints for scalars, which does in fact fit PHP's theme perfectly. - I suggested we actually take the opportunity to slightly modify PHP's conversion rules in esoteric cases, where our historical decision is probably not the right one (e.g., silently converting abc into 0 in case of integer context - instead emit a new E_TYPE warning that would be off by default). My view in terms of preferences: #1 - Auto-converting type hints + minor changes to PHP's conversion rules #2 - Auto-converting type hints #3 - Doing nothing #inf - Introducing strict typing into PHP (current trunk status) As Stas said - there's clearly anything but consensus around strict typing, so our 'default' in case we can't reach agreement is #3 - the status quo. As everyone told me when this feature was committed to trunk - it doesn't mean anything, it's just trunk. Let's stand behind that statement and revert it. Strict typing should go away before any 'official' package comes out of php.net. Zeev -- 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] Strict typing (was: Typehints)
On 11.08.2010, at 10:53, Pierre Joye wrote: On Wed, Aug 11, 2010 at 8:03 AM, Zeev Suraski z...@zend.com wrote: Facts: There are two facts that matter right now, imo: - There is no 5.4 or whatever other version as of now. - There is no RM either. I don't know why nobody cares (well I do ;), but this is totally insane. Do we ever learn? PHP6, the last 5.4 horrible episode, etc. And as we clearly see today, we are not ready. +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
That's not the issue on the table now. We need to remove strict typing from trunk before we release anything 'official' from php.net, and the sooner the better. It's clearly not something there's consensus over, almost the opposite. We should discuss the merits of auto-converting type hints separately - and if we decide not to have it that's fine. It has nothing to do with the fact there's almost consensus not to have strict typing in PHP. Zeev At 13:52 11/08/2010, Ilia Alshanetsky wrote: I think that weak type-hinting defeats the whole purpose of the feature and I would rather not have it than have a non-obvious implementation. -1 On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski z...@zend.com wrote: At 01:47 11/08/2010, Stas Malyshev wrote: Hi! For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I agree completely. The fact that obvious absence of consensus is ignored and we are releasing feature that clearly has no consensus behind it as a part of an official release - when we have killed much lesser things for much lesser reasons - I think it is a very bad development. I agree completely too. We've also had quite a lengthy discussion on this topic, and there was more support for 'weak' typing then there was for strict typing. The response to Johannes's blog also don't leave much room for speculation regarding what the community at large thinks. Facts: - When we introduced type hints, one of the 'conditions' were that we'll never, ever have type hints for scalars - for many different reasons - the strongest of which it simply doesn't fit PHP's theme. - We managed to come up with an alternative solution, in the form of auto-converting type hints for scalars, which does in fact fit PHP's theme perfectly. - I suggested we actually take the opportunity to slightly modify PHP's conversion rules in esoteric cases, where our historical decision is probably not the right one (e.g., silently converting abc into 0 in case of integer context - instead emit a new E_TYPE warning that would be off by default). My view in terms of preferences: #1 - Auto-converting type hints + minor changes to PHP's conversion rules #2 - Auto-converting type hints #3 - Doing nothing #inf - Introducing strict typing into PHP (current trunk status) As Stas said - there's clearly anything but consensus around strict typing, so our 'default' in case we can't reach agreement is #3 - the status quo. As everyone told me when this feature was committed to trunk - it doesn't mean anything, it's just trunk. Let's stand behind that statement and revert it. Strict typing should go away before any 'official' package comes out of php.net. Zeev -- 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] Typehints (was Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1)
On Tue Aug 10 07:42 PM, Josh Davis wrote: Derick's point was about consistency. The approach described in his mail is consistent with current syntax and mechanism(s). Current typehints do not apply any kind of conversion, so treating scalar hints the same way is consistent with the current mechanism. It's only consistent in the function declarations but *completely* inconsistent with how the rest of the language works. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11 August 2010 12:10, Zeev Suraski z...@zend.com wrote: We need to remove strict typing from trunk before we release anything 'official' from php.net I thought trunk is, to some degree, the work in progress / developers only, YMMV branch. Pretty much anything/everything in there is subject to change. No money back guarantees. Etc. For an official release, even as a Here is what we are working on. It might not be perfect, but we like it release, a separate branch would be created. If strict typing isn't wanted in the new branch, then it doesn't go into the new branch (I have a limited understanding of what that entails, so I suspect I'm missing a lot of important processes by saying that - thankfully, no one will ever consider _me_ for the role of RM!). So, the trunk keeps strict typing. Richard Quadling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11.08.2010, at 14:14, Richard Quadling wrote: So, the trunk keeps strict typing. no .. a controversial patch like this should never have gotten into trunk without a vote. the only place for this patch in the svn.php.net repo would be a feature branch. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
2010/8/11 Ilia Alshanetsky i...@prohost.org:
I think that weak type-hinting defeats the whole purpose of the
feature and I would rather not have it than have a non-obvious
implementation.
-1
I would like to point out an argument, posted in the Typehints (was
Re: [PHP-DEV] Annoucing PHP 5.4 Alpha 1) thread by Jonathan
Bond-Caron, quoting:
It's only consistent in the function declarations but *completely*
inconsistent with how the rest of the language works.
He took the words out of my mouth.
The auto-convert feature only touches the idea that 1 = 1, 1 = 1
conversions should take place automatically. In the case of abcd =
0 we emit an error message. As it was mentioned in the RFC, the idea
is not only to make type hint's this way, but _also_ to change the
language conversion rules acordingly to match the type hinting
auto-conversion rules. That way the conversion rules are made more
strict and type hints get some freedom instead of going into E_FATAL
everytime a developer misses string to int (and other similiar)
conversion in the code before passing data to objects/functions/API.
The conversions don't just go completly silent if inapropriate value
is passed to the function/method witch can't be converted
transparently to the required type. It gives you the error message and
it's your choise to ignore it or fix it. Strict type hintng will just
bring tons of code that does:
settype('integer', $total);
settype('integer', $per_page);
settype('integer', $page);
pager($page, $total, $per_page);
It will have to be written to make sure the variables have the right
type. Especially $page, witch usually comes via $_GET. Instead of just
checking for is_numeric now we have also to convert the type.
I just have an empression that you don't write much PHP code or you
work on very big and highly sophisticated projects, where the
situation is different. You leaving out the majority of PHP code
written for the middle and small scale projects, witch usually done by
far more simplier tools, sometimes even just using the plain old PHP
without a framework (and yes, sometimes it's just faster that way!).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Closures as methods (and Closure::bind)
I've updated the wiki page for Closures with objects extension with
things that are in Proposal A with modifications but are not implemented:
http://wiki.php.net/rfc/closures/object-extension#status_as_of_august_10_2010
I propose an implementation of closures stored in properties used as
methods, as in:
$this-prop = function () { ...}
$this-prop();
A few issues that may merit discussion (copied from the wiki page):
- Do we really want to make closures-as-methods have priority over
__call/__callStatic? On one hand, there's no way to otherwise allow
closures-as-methods in classes that implement these magic methods, on the
other one, this breaks BC and makes the magic methods even more
inefficient – we have to check if there is a method and a property with
that name.
- Properties are not case-sensitive, hence calling closures-as-methods is
case-sensitive (contrary to calling regular methods).
- What to do with properties with no visibility? Ignore them (and let fall
back to __call/__callStatic) or raise error (the implementation in the
patch raises an error).
- What to do with properties used as methods that are not closures? Ignore
them or raise an error (the implementation raises an error).
- Should we throw an exception when calling a closure-as-instance method
that's stored as a static method? Usually, accessing a static property in
a non static context raises an E_STRICT, but I think may very well be very
useful, because we can swap instance method implementations on a class
basis instead of only an instance basis.
I've also updated the bindTo behavior change and document it in the same
wiki page. Compared to the previous patch I'd sent, this implementation
has more tests, moves getScope to reflection (a getClosureScopeClass that
returns a ReflectionClass) and allows binding objects with NULL scope
(uses a dummy scope instead) instead of silently refusing to bind the
object.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Strict typing (was: Typehints)
-Original Message- From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Sent: Wednesday, August 11, 2010 5:19 AM To: rquadl...@googlemail.com Cc: Zeev Suraski; Ilia Alshanetsky; Stas Malyshev; Johannes Schlüter; Kalle Sommer Nielsen; Internals; Derick Rethans Subject: Re: [PHP-DEV] Strict typing (was: Typehints) On 11.08.2010, at 14:14, Richard Quadling wrote: So, the trunk keeps strict typing. no .. a controversial patch like this should never have gotten into trunk without a vote. the only place for this patch in the svn.php.net repo would be a feature branch. I completely agree. I don't know how this patch sneaked in and there clearly is a vast majority against it. We have discussed several times over the years on why such strict type hinting does not make sense for PHP. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Strict typing (was: Typehints)
I wouldn't mind living with neither but I think it's two separate discussions. -Original Message- From: Ilia Alshanetsky [mailto:i...@prohost.org] Sent: Wednesday, August 11, 2010 3:52 AM To: Zeev Suraski Cc: Stas Malyshev; Johannes Schlüter; Kalle Sommer Nielsen; Internals; Derick Rethans Subject: Re: [PHP-DEV] Strict typing (was: Typehints) I think that weak type-hinting defeats the whole purpose of the feature and I would rather not have it than have a non-obvious implementation. -1 On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski z...@zend.com wrote: At 01:47 11/08/2010, Stas Malyshev wrote: Hi! For the record: I consider the current implementation as (one of) the biggest mistakes in the last ten years. I agree completely. The fact that obvious absence of consensus is ignored and we are releasing feature that clearly has no consensus behind it as a part of an official release - when we have killed much lesser things for much lesser reasons - I think it is a very bad development. I agree completely too. We've also had quite a lengthy discussion on this topic, and there was more support for 'weak' typing then there was for strict typing. The response to Johannes's blog also don't leave much room for speculation regarding what the community at large thinks. Facts: - When we introduced type hints, one of the 'conditions' were that we'll never, ever have type hints for scalars - for many different reasons - the strongest of which it simply doesn't fit PHP's theme. - We managed to come up with an alternative solution, in the form of auto-converting type hints for scalars, which does in fact fit PHP's theme perfectly. - I suggested we actually take the opportunity to slightly modify PHP's conversion rules in esoteric cases, where our historical decision is probably not the right one (e.g., silently converting abc into 0 in case of integer context - instead emit a new E_TYPE warning that would be off by default). My view in terms of preferences: #1 - Auto-converting type hints + minor changes to PHP's conversion rules #2 - Auto-converting type hints #3 - Doing nothing #inf - Introducing strict typing into PHP (current trunk status) As Stas said - there's clearly anything but consensus around strict typing, so our 'default' in case we can't reach agreement is #3 - the status quo. As everyone told me when this feature was committed to trunk - it doesn't mean anything, it's just trunk. Let's stand behind that statement and revert it. Strict typing should go away before any 'official' package comes out of php.net. Zeev -- 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] Closures as methods (and Closure::bind)
On Wed, 2010-08-11 at 14:38 +0100, Gustavo Lopes wrote:
I've updated the wiki page for Closures with objects extension with
things that are in Proposal A with modifications but are not implemented:
http://wiki.php.net/rfc/closures/object-extension#status_as_of_august_10_2010
I propose an implementation of closures stored in properties used as
methods, as in:
$this-prop = function () { ...}
$this-prop();
A few issues that may merit discussion (copied from the wiki page):
A few more things coming to mind without much thought:
* What if both a method and a property with the name exist?
* What about allowing properties with function names as strings or
array($obj_or_class, 'method'), won't that be needed for being
consistent with local variables?
* In the array($object, 'method') case: What's the scope
for $this?
I don#t have an opinion on this feature, yet, I like the current
class-based object model as reading code is relatively simple, with this
addition (and the fact that you can create properties on the fly) we
create a powerful tool for really hard to read code.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 8/11/10 1:03 AM, Zeev Suraski wrote: We've also had quite a lengthy discussion on this topic, and there was more support for 'weak' typing then there was for strict typing. Yes, I would like to restate the obvious from my email in May: Really, I am confused what the argument is about. We already decided how this should work years ago. It should work just like the code below. Having user land functions work different than built in functions is the most confusing thing you can do. Unless of course someone plans on fixing all the internal functions too. ?php error_reporting(E_ALL); $int = 1.25454; $var = substr($int, 0, 4); var_dump($var); $var = round($var, 1); var_dump($var); $arr = array(); $var = substr($arr, 0, 1); var_dump($var); $text = test; $var = round($text, 1); var_dump($var); ? $ php test.php string(4) 1.25 float(1.3) Warning: substr() expects parameter 1 to be string, array given in /Users/brianm/test.php on line 17 NULL float(0) -- Brian. http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
At 15:14 11/08/2010, Richard Quadling wrote: On 11 August 2010 12:10, Zeev Suraski z...@zend.com wrote: We need to remove strict typing from trunk before we release anything 'official' from php.net I thought trunk is, to some degree, the work in progress / developers only, YMMV branch. Pretty much anything/everything in there is subject to change. No money back guarantees. Etc. Supposedly we switched to this strategy although I'm not sure why, nor I recall any discussion about it - although I may have missed it. We never ever treated HEAD this way in the CVS days. So sure, now it's called 'trunk', but why we should deviate from our decision making processes (as lax as they may be) because we changed version control systems is beyond me. For an official release, even as a Here is what we are working on. It might not be perfect, but we like it release, a separate branch would be created. It's really not a matter of branches, trunk or HEAD. It's a matter of what 'php.net' puts its virtual stamp of approval on. If 5.4 alpha 1 came out with strict typing in it, it would send two very strong messages to the PHP community: 1. The next version of PHP is going to be named 5.4 - something that wasn't agreed upon (although personally I don't mind that much). 2. We think strict typing is a good idea, here, play with it. Well, turns out that the collective 'we' doesn't really think that at all. It's no big news either, it's been known for many months. That goes back to my first paragraph. Personally, I don't like the 'shoot first, ask questions later' approach that we supposedly switched to recently. To me it makes a whole lot more sense to discuss first, and only once a decision is made - go ahead and implement it. Whether we go formal with RFCs or less formal on internals@ (depending on the scope) - either way it's way better than committing first and only then discussing. Once in trunk we suddenly need a great reason to remove it, since trunk is now the new 'status quo'. Thankfully in the case of strict typing there was a strong, clear message from the community 'don't do it', but what about smaller features? 'Shoot first, ask questions later' equates 'bias for change'. Is that where we want to be? IMHO no, we should carefully consider every change we make to the core language at this point in time. Maybe I'm old school, but in my opinion, trunk should only contain agreed-upon features. It should also always build and pass tests successfully. It's not the wild-west version of PHP, it's PHP's next version, in progress. Want to work on something experimental or controversial? Do that in a branch, merge it if when it gets accepted to the language. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11.08.2010, at 16:13, Zeev Suraski wrote: Maybe I'm old school, but in my opinion, trunk should only contain agreed-upon features. It should also always build and pass tests successfully. It's not the wild-west version of PHP, it's PHP's next version, in progress. Want to work on something experimental or controversial? Do that in a branch, merge it if when it gets accepted to the language. +1 actually this is in a lot of ways new school, since even though we do not yet use one of those fancy DVCS, with svn we have a much better work flow already to handle feature branches. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11 August 2010 15:13, Zeev Suraski z...@zend.com wrote: At 15:14 11/08/2010, Richard Quadling wrote: On 11 August 2010 12:10, Zeev Suraski z...@zend.com wrote: We need to remove strict typing from trunk before we release anything 'official' from php.net I thought trunk is, to some degree, the work in progress / developers only, YMMV branch. Pretty much anything/everything in there is subject to change. No money back guarantees. Etc. Supposedly we switched to this strategy although I'm not sure why, nor I recall any discussion about it - although I may have missed it. We never ever treated HEAD this way in the CVS days. So sure, now it's called 'trunk', but why we should deviate from our decision making processes (as lax as they may be) because we changed version control systems is beyond me. For an official release, even as a Here is what we are working on. It might not be perfect, but we like it release, a separate branch would be created. It's really not a matter of branches, trunk or HEAD. It's a matter of what 'php.net' puts its virtual stamp of approval on. If 5.4 alpha 1 came out with strict typing in it, it would send two very strong messages to the PHP community: 1. The next version of PHP is going to be named 5.4 - something that wasn't agreed upon (although personally I don't mind that much). 2. We think strict typing is a good idea, here, play with it. Well, turns out that the collective 'we' doesn't really think that at all. It's no big news either, it's been known for many months. That goes back to my first paragraph. Personally, I don't like the 'shoot first, ask questions later' approach that we supposedly switched to recently. To me it makes a whole lot more sense to discuss first, and only once a decision is made - go ahead and implement it. Whether we go formal with RFCs or less formal on internals@ (depending on the scope) - either way it's way better than committing first and only then discussing. Once in trunk we suddenly need a great reason to remove it, since trunk is now the new 'status quo'. Thankfully in the case of strict typing there was a strong, clear message from the community 'don't do it', but what about smaller features? 'Shoot first, ask questions later' equates 'bias for change'. Is that where we want to be? IMHO no, we should carefully consider every change we make to the core language at this point in time. Maybe I'm old school, but in my opinion, trunk should only contain agreed-upon features. It should also always build and pass tests successfully. It's not the wild-west version of PHP, it's PHP's next version, in progress. Want to work on something experimental or controversial? Do that in a branch, merge it if when it gets accepted to the language. Zeev Thank you for that Zeev. -- Richard Quadling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures as methods (and Closure::bind)
On Wed, 11 Aug 2010 14:57:47 +0100, Johannes Schlüter
johan...@schlueters.de wrote:
On Wed, 2010-08-11 at 14:38 +0100, Gustavo Lopes wrote:
I've updated the wiki page for Closures with objects extension with
things that are in Proposal A with modifications but are not
implemented:
http://wiki.php.net/rfc/closures/object-extension#status_as_of_august_10_2010
I propose an implementation of closures stored in properties used as
methods, as in:
$this-prop = function () { ...}
$this-prop();
A few issues that may merit discussion (copied from the wiki page):
A few more things coming to mind without much thought:
* What if both a method and a property with the name exist?
An existing method has priority over closure-as-method, just like it has
priority over __call. I implemented what was in the modified proposal A.
Personally, I think __call should have priority over closure-as-method so
as to not to break BC.
* What about allowing properties with function names as strings or
array($obj_or_class, 'method'), won't that be needed for being
consistent with local variables?
Well, you cannot do $a = 'phpinfo'; $a(); as well, so it's consistent
with that. I think what you refer to would only make sense if that were
allowed.
* In the array($object, 'method') case: What's the scope
for $this?
call_user_func(array($object, 'method')) is the same as $object-method(),
the calling scope is that whatever scope is defined for the closure. The
value of $this is the object that's bound to the closure; an E_WARNING
notice is raised if $this !== $object (as mentioned in the proposal).
class A {
public $prop;
}
$a1 = new A;
$a2 = new A;
$a1-prop = Closure::bind(function () { var_dump($this); }, $a2);
call_user_func(array($a1, 'prop'));
gives:
Warning: Closure called as method but bound object differs from containing
object in ...
object(A)#2 (1) {
[prop]=
NULL
}
I don#t have an opinion on this feature, yet, I like the current
class-based object model as reading code is relatively simple, with this
addition (and the fact that you can create properties on the fly) we
create a powerful tool for really hard to read code.
We could forbid using dynamic properties for this functionality, though
I'd say it's arguably useful.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures as methods (and Closure::bind)
On Wed, 2010-08-11 at 15:29 +0100, Gustavo Lopes wrote: * What about allowing properties with function names as strings or array($obj_or_class, 'method'), won't that be needed for being consistent with local variables? Well, you cannot do $a = 'phpinfo'; $a(); as well, so it's consistent with that. I think what you refer to would only make sense if that were allowed. You can. This is valid. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Victor Bolshov wrote: Having two similar syntaxes that work differently - would make the situation even worse that it is now - I beleive. And I totally agree with Rasmus - strict typed language mustnt be called PHP. (Just a poor user's notice to all of you internals' geeks out there) 2010/8/11 Stas Malyshev smalys...@sugarcrm.com: Hi! 1. right now we *have* strict type checks for classes and arrays in the form of classname or array Because classes and arrays were never intechangeable types and there was never implicit or explicit conversion between SplRecursiveTreeIterator and Zend_Pdf_Generator - it doesn't even make sense to suggest it. There always was conversion between int and string or int and bool. These two things are completely different. 2. the strict scalary type hint patch reuses this same syntax in the form oftype-name to do the same thing in function arguments It's not a good thing. As I mentioned, primitive types and classes are very different in their use cases and established patterns in PHP. Primitive types are largely interchangeable, classes are not. (As for arrays, arrays really should be a class by their usage patterns etc. but for historic reasons... you know) 3. we have casting type hints in the rest of the code in the form of (int). Just to make it simpler and less confusing, of course. It's nothing like language having two features that look almost exactly the same but work in different way, and using plenty of ()s is an added bonus for all Lisp fans out there. Some people don't like strict typehints, but the syntax as it currently is regarding type hints is *consistent*. Now, to allow both strict and casting hints, the logical step seems to be, to give the weak typehint advocates their tool as well: Calling something that works completely differently from all the established patterns of PHP - like internal functions, etc. - *consistent* requires totally new definition of this word. -- 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 Why do you think the two syntax's would be more complex!? IMO it is very clear what each would do. The strict type hinting, foo(int $var), is the same as the current type hinting for classes and arrays. It's required to be of that type, plain and simple. The weak type hinting, foo((int) $var), is the same as casting any other var, plain and simple. It will try to be casted to the specified type, with an error if it can't. I'm willing to bet that if you bring this to the end users they will agree that it's easy to understand. Why try to figure out a new syntax for something that already exists!? Now, changing the current implementation to weak type hinting would be more confusing. Because the current syntax used for type hinting classes/arrays is strict. If changed, you would need to specify that scaler types are weak but classnames are strict and now you have a WTH moment. Not sure how much my opinion matters here though because I'm just an end user of PHP. IMO some of these debates should be brought to the end users. Who uses PHP in the end? The users. (And yes, I know the devs here do to..) What is one thing most companies go by? The customers come first. This we know best attitude here is gone way to far. Please don't just leave this here, because you'll hear it from the users in the end anyway. A good community is one who communicates. Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 11.08.2010, at 16:55, Ryan Panning wrote: Now, changing the current implementation to weak type hinting would be more confusing. Because the current syntax used for type hinting classes/arrays is strict. If changed, you would need to specify that scaler types are weak but classnames are strict and now you have a WTH moment. actually for objects its fairly along the lines of what is being proposed with weak typing, since the type hints for objects do consider inheritance. so you do not need to pass in exactly the object that is type hinted, but instead you can also pass in any subclass (an integer is a float). anyway .. for the love of god, could be please stop arguing in circles, nothing .. really nothing that people brought forth pro/con any approach in regards to type checking/hinting whatever hasn't been mentioned on this list multiple times. please please please please .. read the RFC's on the wiki .. if there is something not mentioned there .. ask the author of the RFC why that is and see if they are willing to add it there and notify the list once. If the author in question is unwilling to add it .. then .. and only then bring it back to this list. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Lukas Kahwe Smith wrote: ... anyway .. for the love of god, could be please stop arguing in circles, nothing .. really nothing that people brought forth pro/con any approach in regards to type checking/hinting whatever hasn't been mentioned on this list multiple times. ... I agree with you, another topic that has been debated to death here. Between this and the namespace separator debate, it's been hard to keep up. One other comment I forgot with my original post: Why not leave the choice (strict/weak) up to the end users by implementing both using the syntax I commented about? Is one way or the other so bad that it can't be implemented? At this point I feel like a decision should be made and stick with it. I would use this feature either way (strict/weak/both). It'll mainly be used in a framework so the users of that are going to have to deal with the end result. But if I had to vote it would be for weak. Thanks again. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On Wed, 2010-08-11 at 09:55 -0500, Ryan Panning wrote: IMO some of these debates should be brought to the end users. Who uses PHP in the end? The users. (And yes, I know the devs here do to..) What is one thing most companies go by? The customers come first. This we know best attitude here is gone way to far. Please don't just leave this here, because you'll hear it from the users in the end anyway. A good community is one who communicates. Thanks Good that this discussion happens in a secret place on a list no community members can see. Oh wait. It doesn't. Oh and wait we let users participate! And we know best - well part of this is that for doing the discussion in a sane way you need some minimum knowledge and some experience. I talked to PHP users on different conferences, even about type hints at different conferences and such and if you ask them Do you want type hints? most of them will answer yes, yes, yes! until you explain the consequences, like I did a bit on my blog[1] (again very secret discussion ignoring all users!). Then suddenly they agree that type hints are bad. But that's not their opinion. That's manipulation. Asking the question the way you want while providing the material to support your point. (It is hard to ask this in an neutral way) For _real_ argumentation you need to really think through it. And here on the list are people who try to do this. Many people participating in this discussion discussed other problems, too and then found out what the bad consequences are, and learned from these mistakes. Others are willing to invest time to think through ideas. Few just flame/try to push their opinion. But still this is an open list. (sometimes unfortunately) johannes [1] http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures as methods (and Closure::bind)
On Wed, 11 Aug 2010 15:37:01 +0100, Johannes Schlüter johan...@schlueters.de wrote: On Wed, 2010-08-11 at 15:29 +0100, Gustavo Lopes wrote: * What about allowing properties with function names as strings or array($obj_or_class, 'method'), won't that be needed for being consistent with local variables? Well, you cannot do $a = 'phpinfo'; $a(); as well, so it's consistent with that. I think what you refer to would only make sense if that were allowed. You can. This is valid. Oh. I'll change it then. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On Wed, 2010-08-11 at 10:17 -0500, Ryan Panning wrote: One other comment I forgot with my original post: Why not leave the choice (strict/weak) up to the end users by implementing both using the syntax I commented about? Is one way or the other so bad that it can't be implemented? Yes. It was clearly said by quite many people that strict typing is so bad. Way clearer than almost any other decision. So please lets end this thread and move on to undecided questions. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Hi, trying to get back to productive issues: On Tue, 2010-06-15 at 07:41 -0400, Ilia Alshanetsky wrote: After speaking to a few developers in DPC, I think it makes sense for us to drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. I think the consensus here is to drop the extension and the pdo_sqlite2 driver. Should we add deprecation notices to sqlite_open() and the PDO driver ctor? Any other comments (CC'ing the webmaster list as the PHP Web site depends heavily on SQLite2) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Johannes Schlüter wrote: Good that this discussion happens in a secret place on a list no community members can see. Oh wait. It doesn't. Oh and wait we let users participate! And we know best - well part of this is that for doing the discussion in a sane way you need some minimum knowledge and some experience. I talked to PHP users on different conferences, even about type hints at different conferences and such and if you ask them Do you want type hints? most of them will answer yes, yes, yes! until you explain the consequences, like I did a bit on my blog[1] (again very secret discussion ignoring all users!). Then suddenly they agree that type hints are bad. But that's not their opinion. That's manipulation. Asking the question the way you want while providing the material to support your point. (It is hard to ask this in an neutral way) For _real_ argumentation you need to really think through it. And here on the list are people who try to do this. Many people participating in this discussion discussed other problems, too and then found out what the bad consequences are, and learned from these mistakes. Others are willing to invest time to think through ideas. Few just flame/try to push their opinion. But still this is an open list. (sometimes unfortunately) johannes [1] http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html Fair enough. I just feel like if I don't follow this newsgroup then I won't know what's going on with PHP. For others like myself, I don't know about other places to watch, such as your blog or the IRC. Votes that I have casted here have been counted, and I thank you for that. But it just seems hard to follow at times. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures as methods (and Closure::bind)
On Wed, 11 Aug 2010 15:37:01 +0100, Johannes Schlüter johan...@schlueters.de wrote: On Wed, 2010-08-11 at 15:29 +0100, Gustavo Lopes wrote: * What about allowing properties with function names as strings or array($obj_or_class, 'method'), won't that be needed for being consistent with local variables? Well, you cannot do $a = 'phpinfo'; $a(); as well, so it's consistent with that. I think what you refer to would only make sense if that were allowed. You can. This is valid. OK, I know where I got this idea. $a = 'phpinfo'; $a(); is actually the only valid case. array callbacks or 'Foo::bar' are forbidden. In order to be called as instance methods, the closure properties needs to have a bound instance -- preferably -- very preferably -- the instance where the closure is stored. In this case, it doesn't make sense to allow 'function' to be called, because then we wouldn't have anything with which to fill the $this pointer. I guess it could make some sense for static calls, though. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Well this is turning into a real flamefest. Personally I really HATE the 5.3 implementation of typehints - heck you can't even typehint arrays with an arrayobject instance, it's not hinting in any way shape or form and is generally broken. On the other hand I'd like to be able to have the same control of parameters in my userland code that I do in extensions - namely the same control I get with zend_parse_parameters. And the same errors/warnings I get with zend_parse_parameters Any reason we can't expose the logic included there into userland? Would make internal functions and userland functions work the same and act the same. Anyway, at this point there's a lot of arguing and very little consensus. I'm kind of tempted to say maybe all the people on the internals mailing list are a bit myopic in their viewpoints, and maybe this does need to get out to a wider community (php.general perhaps?) since the guy hacking on a wordpress plugin is every bit as much a PHP user as any of us. Thanks, Elizabeth M Smith -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Hi Elizabeth 2010/8/11 Elizabeth M Smith auroraeosr...@gmail.com: Well this is turning into a real flamefest. Personally I really HATE the 5.3 implementation of typehints - heck you can't even typehint arrays with an arrayobject instance, it's not hinting in any way shape or form and is generally broken. On the other hand I'd like to be able to have the same control of parameters in my userland code that I do in extensions - namely the same control I get with zend_parse_parameters. And the same errors/warnings I get with zend_parse_parameters Sara wrote an extension for zend_parse_parameters() to expose it to userland and its available in PECL: http://svn.php.net/viewvc/pecl/params/trunk/ Im a +1 for exposing such functionality from the core/stdlib. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing (was: Typehints)
On 11 Aug 2010, at 15:13, Zeev Suraski wrote: Maybe I'm old school, but in my opinion, trunk should only contain agreed-upon features. It should also always build and pass tests successfully. It's not the wild-west version of PHP, it's PHP's next version, in progress. Want to work on something experimental or controversial? Do that in a branch, merge it if when it gets accepted to the language. I think that depends upon (a) consistency with how it was done last time; and (b) what you're used to. I've worked on plenty of projects where the trunk was bleeding edges and branches are used for release preparation. Melanie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On Wed, 11 Aug 2010 16:03:14 +0100, Alexey Zakhlestin indey...@gmail.com wrote: 2010/8/11 Ryan Panning rpann...@gmail.com: Because the current syntax used for type hinting classes/arrays is strict. If changed, you would need to specify that scaler types are weak but classnames are strict and now you have a WTH moment. Not really. Class type-hinting is not strict. The only reason why it looks strict is, that PHP doesn't provide userland ways for object-casting. As far as I remember, zend-engine, underneath, actually has hook for casting. And nothing stops us from supporting such casting with hints, eventually. If you're referring to the cast_object handler, the only thing it can specify in terms of the target type is IS_STRING, IS_OBJECT, etc. I don't think what we have now and both strategies that are being considered are directly comparable, so the the current type hinting* is/is not strict and the new strategy is/is not consistent with current type hinting are just rhetoric. I'm my opinion, what we should strive for is consistency with the only comparable thing, the current parsing API, zend_parse_parameters. If an internal function says it accepts an array, it can only take an array**. If it says it only accepts an object of a certain type, it checks the inheritance hierarchy***. So the current type hinting implementation is already consistent with zend_parse_parameters. Unfortunately, both competing options want to deviate from this: - The strict side wants a simple, 'gettype' like check, that has nothing to do with the current API. - The weak side thinks the current parameter parsing API is a bit loose (for instance, if I'm not mistaken, all the scalars are automatically converted to bool), so it's better to create a whole new set of rules, even though they will still deviate slightly from the current API. In my opinion, the transition should be made slowly. First, by raising a warning on the undesirable automatic conversions we don't want, and finally disallowing them altogether and introducing a compatible user-space type hinting. * terminology objections aside ** the rare 'H'/'A', which also take an object, excluded) *** 'o' can also be given, which accepts all the object types -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 11 Aug 2010, at 17:01, Elizabeth M Smith wrote: Well this is turning into a real flamefest. I'm now totally confused to be honest. Personally I really HATE the 5.3 implementation of typehints - heck you can't even typehint arrays with an arrayobject instance, it's not hinting in any way shape or form and is generally broken. On the other hand I'd like to be able to have the same control of parameters in my userland code that I do in extensions - namely the same control I get with zend_parse_parameters. And the same errors/warnings I get with zend_parse_parameters This. Any reason we can't expose the logic included there into userland? Would make internal functions and userland functions work the same and act the same. Anyway, at this point there's a lot of arguing and very little consensus. I'm kind of tempted to say maybe all the people on the internals mailing list are a bit myopic in their viewpoints, and maybe this does need to get out to a wider community (php.general perhaps?) since the guy hacking on a wordpress plugin is every bit as much a PHP user as any of us. Absolutely. Melanie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
anyway .. for the love of god, could be please stop arguing in circles, nothing .. really nothing that people brought forth pro/con any approach in regards to type checking/hinting whatever hasn't been mentioned on this list multiple times. +1 please please please please .. read the RFC's on the wiki .. if there is something not mentioned there .. ask the author of the RFC why that is and see if they are willing to add it there and notify the list once. If the author in question is unwilling to add it .. then .. and only then bring it back to this list. +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- 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] Strict typing
Hi! Yeah, hmm, no, and it is disingenuous of you to equate type hints to PHP becoming statically typed. I'm sure that some people would love to See? That's exactly why I am so opposed to calling it type hints. Because if you called it proper name - strict typing, you'd say it is disingenuous of you to equate strict typing to PHP becoming statically typed and it'd make you think that maybe it doesn't sound good. have optional static typing in parts of their code, but I like being able to use my vars freely when I need to. Being able to enforce what That only leads to very bad coding practices. If you have strictly typed parameter int $foo, any data path that leads to $foo should be verified to always produce int - otherwise your code blows up at runtime (no compile-time checks, remember?). That can be achieved in one of two ways: 1. Having convert/check before each call to the function 2. Having variables and parameters to upstream functions typed 1 is insanely-ugly code, 2 is static typing. You choose. PHP being dynamically typed shouldn't be an argument to prevent people from enforcing method signatures. You're saying that PHP users should have no control over what variable types are passed to their functions. No, I'm not saying that. I'm saying, see above, that there are consequences to strictly typed parameters. You can, of course, choose third way and have half-assed implementation, but that would prove to work badly very quickly. As soon as you discover it, you'd ask for typed variables and typed returns and typed properties, etc. etc. Enter static typing. The fact that you won't use it for every variable doesn't matter. More seriously, one of PHP's most popular quality is that it is flexible. When I started using PHP, I would never initialize variables Flexible doesn't mean changes at my every whim without regard for consequences. This change is bad. It should be rolled back. back then no one told me oh you want warnings on initialized variables? You should use C++ then! Haha! PHP was flexible enough to Unitialized vars notice is one of the great mistakes in PHP. The amount of ugly boilerplate code that it brings along is mind-boggling. You can't just say if($_REQUEST['blah'] == 'blah') do_stuff(); - you have to put isset() there or you get a very costly, annoying and completely useless error message. It was a mistake to create it. But that's another discussion, not for now. to their functions what they want. And you're against that on... ideological grounds? I'm against it on sanity and logic grounds. I explained the reasons (for the Nth time) above. If you still can't comprehend that there's logic behind what I am saying and call it ideology - well, I guess there's a limit of what one can explain. -- 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
[PHP-DEV] params ext (was: Strict typing)
Hi! Sara wrote an extension for zend_parse_parameters() to expose it to userland and its available in PECL: http://svn.php.net/viewvc/pecl/params/trunk/ Im a +1 for exposing such functionality from the core/stdlib. I like the idea, though it looks like this function is a re-implementation of the engine parsing, which is not good. The function that actually reuses the engine function would be much better. Ahother thing - for core I think it has to be named something like func_parse_args() to be in line with func_get_args() etc. and some error feedback (like, which parameter failed and why) wouldn't hurt. But having such thing in core would be very nice. Though it wouldn't solve the current debate about types/params, since the whole idea is for it to work without calling additional functions. -- 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
[PHP-DEV] back to 5.4 alpha
Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? -- 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] Strict typing
On 11 August 2010 19:20, Stas Malyshev smalys...@sugarcrm.com wrote: I'm against it on sanity and logic grounds. I explained the reasons (for the Nth time) above. If you still can't comprehend that there's logic behind what I am saying and call it ideology - well, I guess there's a limit of what one can explain. I perfectly understand that there are reasons behind wanting the more relaxed smartcasting to be the only option but please go ahead and be condescending if you want. There is logic behind what you're saying: your logic. It's not a universal logic though, as evidenced by the lack of consensus. My point is this: Derick's proposal (which started this thread before it got forked somehow) was to allow everybody to have it their way. You are fighting tooth and nail to prevent that from happening, choosing instead to impose your logic and your definition of what is sound to the users. I call that ideology. My own ideology is to leave that choice to the users if it doesn't incur a high cost. That way, my ideology is more compatible with others'. Offering both typechecking and smartcasting is compatible with both groups of users, which, btw, do overlap to some extent; if the feature was available I'd use typechecking for internal functions and smartcasting for most of the public stuff, depending on what rules it follows. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: params ext (was: Strict typing)
Hi 2010/8/11 Stas Malyshev smalys...@sugarcrm.com: I like the idea, though it looks like this function is a re-implementation of the engine parsing, which is not good. The function that actually reuses the engine function would be much better. I did have a short peak at the code and yes I belive we could implement such a function relatively more simple than pecl/params Ahother thing - for core I think it has to be named something like func_parse_args() to be in line with func_get_args() etc. and some error feedback (like, which parameter failed and why) wouldn't hurt. I thought the same, and then implementing it in zend_builtin_functions in line with the other func_*() utilities. But having such thing in core would be very nice. Though it wouldn't solve the current debate about types/params, since the whole idea is for it to work without calling additional functions. Indeed it doesn't solve the current arguments for and against type hinting. But its a good step in the right direction for a better way to parse passed parameters from a library developer perspective. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
Hi 2010/8/11 Stas Malyshev smalys...@sugarcrm.com: So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? +1 for moving the type hinting to a feature branch, and merging it back when the discussions about the implementations are over. I don't think type hinting should be the show stopper here and we can always change the code afterwards like we did with namespaces in the 5.3 development days. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Wed, 11 Aug 2010, Stas Malyshev wrote:
So I'd propose doing the following:
1. Moving parameter typing to a feature branch (by branching current trunk and
then rolling back the typing part in the trunk).
2. Starting 5.4 alpha process after that basing on trunk.
Any objections to this?
A little bit; yes. There is indeed 0 consensus for having the strict
typehints. However, instead of removing it altogether, and instead
answering every mail in this thread :P, I wrote/am writing a patch that
removes the hard type checks. It however keeps the parsed structures and
reflection API for it. In this sense, they're actually real hints. The
patch also adds a mechanism similariy to the zend_error_cb mechanism so
that extensions could override the argument type checking. As my use
case for strict checking is development I'd be happy to just move the
hard checks into an extension. I could even offer a soft check. It also
allows some type inference which might be useful for webservice
introspecition generation. I am sure SOAP might have some benefit of
this, and I know that at least pecl/dbus does. The patch is attached,
but not ready (I haven't remove the hard checks yet because things got
busy at work).
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebugIndex: ext/standard/var_unserializer.c
===
--- ext/standard/var_unserializer.c (revision 302073)
+++ ext/standard/var_unserializer.c (working copy)
@@ -1,4 +1,4 @@
-/* Generated by re2c 0.13.5 on Fri Aug 6 19:20:07 2010 */
+/* Generated by re2c 0.13.5 on Tue Aug 10 15:20:52 2010 */
#line 1 ext/standard/var_unserializer.re
/*
+--+
Index: Zend/zend.c
===
--- Zend/zend.c (revision 302073)
+++ Zend/zend.c (working copy)
@@ -648,6 +648,7 @@
zend_vspprintf = utility_functions-vspprintf_function;
zend_getenv = utility_functions-getenv_function;
zend_resolve_path = utility_functions-resolve_path_function;
+ zend_verify_arg_type = utility_functions-verify_arg_type_function;
#if HAVE_DTRACE
/* build with dtrace support */
Index: Zend/zend.h
===
--- Zend/zend.h (revision 302073)
+++ Zend/zend.h (working copy)
@@ -536,6 +536,7 @@
int (*vspprintf_function)(char **pbuf, size_t max_len, const char
*format, va_list ap);
char *(*getenv_function)(char *name, size_t name_len TSRMLS_DC);
char *(*resolve_path_function)(const char *filename, int filename_len
TSRMLS_DC);
+ int (*verify_arg_type_function)(union _zend_function *zf, zend_uint
arg_num, zval *arg, ulong fetch_type TSRMLS_DC);
} zend_utility_functions;
typedef struct _zend_utility_values {
Index: Zend/zend_execute.c
===
--- Zend/zend_execute.c (revision 302073)
+++ Zend/zend_execute.c (working copy)
@@ -589,7 +589,7 @@
}
}
-static inline int zend_verify_arg_error(const zend_function *zf, zend_uint
arg_num, const char *need_msg, const char *need_kind, const char *given_msg,
char *given_kind TSRMLS_DC)
+ZEND_API int zend_verify_arg_error(const zend_function *zf, zend_uint arg_num,
const char *need_msg, const char *need_kind, const char *given_msg, char
*given_kind TSRMLS_DC)
{
zend_execute_data *ptr = EG(current_execute_data)-prev_execute_data;
char *fname = zf-common.function_name;
@@ -612,7 +612,7 @@
return 0;
}
-static inline int zend_verify_arg_type(zend_function *zf, zend_uint arg_num,
zval *arg, ulong fetch_type TSRMLS_DC)
+ZEND_API int zend_original_verify_arg_type(zend_function *zf, zend_uint
arg_num, zval *arg, ulong fetch_type TSRMLS_DC)
{
zend_arg_info *cur_arg_info;
char *need_msg;
Index: Zend/zend_execute.h
===
--- Zend/zend_execute.h (revision 302073)
+++ Zend/zend_execute.h (working copy)
@@ -389,7 +389,11 @@
ZEND_API zend_class_entry *zend_fetch_class(const char *class_name, uint
class_name_len, int fetch_type TSRMLS_DC);
ZEND_API zend_class_entry *zend_fetch_class_by_name(const char *class_name,
uint class_name_len, const zend_literal *key, int fetch_type TSRMLS_DC);
void zend_verify_abstract_class(zend_class_entry *ce TSRMLS_DC);
+ZEND_API int zend_verify_arg_error(const zend_function *zf, zend_uint arg_num,
const char *need_msg, const char *need_kind, const char *given_msg, char
*given_kind TSRMLS_DC);
+ZEND_API int zend_original_verify_arg_type(zend_function *zf, zend_uint
arg_num, zval *arg, ulong fetch_type TSRMLS_DC);
+ZEND_API int (*zend_verify_arg_type)(zend_function *zf, zend_uint arg_num,
zval *arg, ulong fetch_type TSRMLS_DC);
+
#ifdef ZEND_WIN32
Re: [PHP-DEV] back to 5.4 alpha
+1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. On Wed, Aug 11, 2010 at 2:30 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
Josh, This too (having both options) was debated many times. Read the archives. Short version? Strict typing is evil. The only thing that's even worse? Adding both Strict typing and something else. Why? You get everything that's bad about strict typing, combined with the added confusion of two ways of doing similar things. Zeev At 21:31 11/08/2010, Josh Davis wrote: On 11 August 2010 19:20, Stas Malyshev smalys...@sugarcrm.com wrote: I'm against it on sanity and logic grounds. I explained the reasons (for the Nth time) above. If you still can't comprehend that there's logic behind what I am saying and call it ideology - well, I guess there's a limit of what one can explain. I perfectly understand that there are reasons behind wanting the more relaxed smartcasting to be the only option but please go ahead and be condescending if you want. There is logic behind what you're saying: your logic. It's not a universal logic though, as evidenced by the lack of consensus. My point is this: Derick's proposal (which started this thread before it got forked somehow) was to allow everybody to have it their way. You are fighting tooth and nail to prevent that from happening, choosing instead to impose your logic and your definition of what is sound to the users. I call that ideology. My own ideology is to leave that choice to the users if it doesn't incur a high cost. That way, my ideology is more compatible with others'. Offering both typechecking and smartcasting is compatible with both groups of users, which, btw, do overlap to some extent; if the feature was available I'd use typechecking for internal functions and smartcasting for most of the public stuff, depending on what rules it follows. -- 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] back to 5.4 alpha
On 8/11/10 1:30 PM, Stas Malyshev wrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? +1. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 11 August 2010 19:11, Alexey Zakhlestin indey...@gmail.com wrote: Did you read second RFC? The one which is about so called weak typehinting. Stas (and a lot of people on this list) prefer it. http://wiki.php.net/rfc/typecheckingstrictandweak Yes of course, but reposting that link is a good idea. :) If you did, can you tell if there is some case, when it doesn't work for you? If I'm using type checking as a sanity check then it doesn't work as soon as it accepts 1 for an int. The described weak typehinting is good if you're looking for a way to validate input. However, it does not work if you're trying to make sure that Stuff Is Going As Planned(tm). For example, consider a protected method getTheNextNTokens(int $n) which is part of some tokenizer or something. It is a protected method and you never write getTheNextNTokens(2) so if it ever receives something that is not an integer, it means that there's a subtle bug somewhere. In that case, strict typehinting buys you peace of mind. If your function lives in a controlled environment (e.g. private methods, or because your specifications require to use the filter extension to validate input) then checking for the type of a variable offers more protection against the unexpected than checking for its contents. Of course, it's not an absolute protection, just like making a method private does not guarantee that a user [of your code] won't extend it to make it public or use ReflectionMethod to make it accessible. It's just another way to defend against the unexpected. I hope it answers your question :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Wed, Aug 11, 2010 at 2:30 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? -- 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 +1 -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
Re: [PHP-DEV] Remove sqlite2 from trunk
2010/8/11 Johannes Schlüter johan...@schlueters.de: Hi, trying to get back to productive issues: On Tue, 2010-06-15 at 07:41 -0400, Ilia Alshanetsky wrote: After speaking to a few developers in DPC, I think it makes sense for us to drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. I think the consensus here is to drop the extension and the pdo_sqlite2 driver. Should we add deprecation notices to sqlite_open() and the PDO driver ctor? Any other comments (CC'ing the webmaster list as the PHP Web site depends heavily on SQLite2) Most of our mirrors have other sqlite extensions available, so its just up to us to generate the sqlite3 databse. I find this sqlite situation very annoying, but I do agree with killing the no-longer-supported variations :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
Ilia Alshanetsky wrote: +1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. A slight aside here, as I have not be bothering about what HAS been implemented typing wise ... A large section of the code a work with passes a range of data to functions and classes. If the function gets an integer it looks up the record with that id, an array assumes the data is already loaded, and perhaps a string value defines that a new record of that name is to be created. So I don't want the parameters passed to be tied to a single type. Is THAT affected by any of the current typing actions? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
At 21:30 11/08/2010, Stas Malyshev wrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: +1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. A slight aside here, as I have not be bothering about what HAS been implemented typing wise ... A large section of the code a work with passes a range of data to functions and classes. If the function gets an integer it looks up the record with that id, an array assumes the data is already loaded, and perhaps a string value defines that a new record of that name is to be created. So I don't want the parameters passed to be tied to a single type. Is THAT affected by any of the current typing actions? both suggested type-hinting strategies are optional. so, you, as developer, are free to not use type-hinting and accept any data you like -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 11 August 2010 20:40, Zeev Suraski z...@zend.com wrote: Josh, This too (having both options) was debated many times. Read the archives. I have already read the archives thank you very much. I'm sure you have too and you remember that there's never been a consensus. I'm sure that Derick remembers them as well, yet he restarted the discussion instead of letting it rot in limbo. Short version? Strict typing is evil. The only thing that's even worse? Adding both Strict typing and something else. Why? You get everything that's bad about strict typing, combined with the added confusion of two ways of doing similar things. That's your opinion and I beg to differ. I find that having both type of typehints is having the best of both world at almost no cost. I am no more confused by the use of parentheses in a method's declaration than I am by their use in a if construct, in a new Foo() instantiation or used anywhere else in PHP. Knowing the difference between different constructs is part of learning a language (just like learning that $a==$b and $a===b are different) and I don't see librairies meant to be used by beginners use strict typechecking anyway. In all likelihood, it will only be used by users and frameworks that want the greatest degree of control over their own code, possibly using strict typechecking for internal stuff and weak typehinting (smartcasting!) for public APIs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
At 22:54 11/08/2010, Josh Davis wrote: On 11 August 2010 20:40, Zeev Suraski z...@zend.com wrote: Josh, This too (having both options) was debated many times. Read the archives. I have already read the archives thank you very much. I'm sure you have too and you remember that there's never been a consensus. I'm sure that Derick remembers them as well, yet he restarted the discussion instead of letting it rot in limbo. Consensus about what? About two similar features with slightly different syntax being a bad thing? I don't think we need consensus for that. That's not up for discussion. It's an axiom for PHP. Short version? Strict typing is evil. The only thing that's even worse? Adding both Strict typing and something else. Why? You get everything that's bad about strict typing, combined with the added confusion of two ways of doing similar things. That's your opinion and I beg to differ. I find that having both type of typehints is having the best of both world at almost no cost. I am no more confused by the use of parentheses in a method's declaration than I am by their use in a if construct, in a new Foo() instantiation or used anywhere else in PHP. Knowing the difference between different constructs is part of learning a language (just like learning that $a==$b and $a===b are different) and I don't see librairies meant to be used by beginners use strict typechecking anyway. In all likelihood, it will only be used by users and frameworks that want the greatest degree of control over their own code, possibly using strict typechecking for internal stuff and weak typehinting (smartcasting!) for public APIs. See above. It would do everyone good if they don't just think about themselves and whether they're fine or not with a given feature, but about the impact it would have on the userbase at large. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
At 22:50 11/08/2010, Alexey Zakhlestin wrote: On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: +1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. A slight aside here, as I have not be bothering about what HAS been implemented typing wise ... A large section of the code a work with passes a range of data to functions and classes. If the function gets an integer it looks up the record with that id, an array assumes the data is already loaded, and perhaps a string value defines that a new record of that name is to be created. So I don't want the parameters passed to be tied to a single type. Is THAT affected by any of the current typing actions? both suggested type-hinting strategies are optional. so, you, as developer, are free to not use type-hinting and accept any data you like Alexey, It's been explained countless times why this is WRONG. Please read the archives. If you have and you disagree with it, please take it as an axiom - a feature being 'optional' does not take away from any confusion or complexity associated with it. It's been a design guideline in PHP from the get go, we're not going to give up on it now. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 12:01 AM, Zeev Suraski z...@zend.com wrote: At 22:50 11/08/2010, Alexey Zakhlestin wrote: On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: +1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. A slight aside here, as I have not be bothering about what HAS been implemented typing wise ... A large section of the code a work with passes a range of data to functions and classes. If the function gets an integer it looks up the record with that id, an array assumes the data is already loaded, and perhaps a string value defines that a new record of that name is to be created. So I don't want the parameters passed to be tied to a single type. Is THAT affected by any of the current typing actions? both suggested type-hinting strategies are optional. so, you, as developer, are free to not use type-hinting and accept any data you like Alexey, It's been explained countless times why this is WRONG. Please read the archives. If you have and you disagree with it, please take it as an axiom - a feature being 'optional' does not take away from any confusion or complexity associated with it. It's been a design guideline in PHP from the get go, we're not going to give up on it now. You misunderstood my comment. Lester asked if he can still have his APIs without type-hinting and I told him that he can. That's all We're not talking about complexities of understanding -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
You're absolutely right, sorry about that! Zeev At 23:11 11/08/2010, Alexey Zakhlestin wrote: You misunderstood my comment. Lester asked if he can still have his APIs without type-hinting and I told him that he can. That's all We're not talking about complexities of understanding -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: back to 5.4 alpha
Stas Malyshev wrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? Coming from a PHP user, +1. I would like to see annual releases with the new features. However, I think the typehint debate should be put to rest. Have a vote and be done with it... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On Wed, Aug 11, 2010 at 9:29 PM, Josh Davis php...@gmail.com wrote: If I'm using type checking as a sanity check then it doesn't work as soon as it accepts 1 for an int. The described weak typehinting is good if you're looking for a way to validate input. However, it does not work if you're trying to make sure that Stuff Is Going As Planned(tm). For example, consider a protected method getTheNextNTokens(int $n) which is part of some tokenizer or something. It is a protected method and you never write getTheNextNTokens(2) so if it ever receives something that is not an integer, it means that there's a subtle bug somewhere. In that case, strict typehinting buys you peace of mind. Hi Thank you for the use case, we need more of them. However in this example, what kind of application wouldn't make this $n parameter configurable (ini file, XML file, user preference from a database etc.) at some point? Then you would be back to square one, meaning you would have to cast your database output so that your strict API accepts the natural evolution of your app. Or you would have to get rid of the strict check and replace it with a userland checking and validation chain (which you should do anyway), at which point you wouldn't need or want type checking but you would be glad to have type casting. In PHP, every single value potentially comes from a kind of stream (file, HTTP or otherwise), there is no such thing as a fully internal configurable value that I can think of. Or is there? If there is, why would it need type checking at all? Type checking or type casting won't save you much trouble since, as you said yourself, in both cases you need to properly validate any data before doing anything funny. However, with type checking you don't get any actual benefit that I can see, while with type casting you can do other things relying on the cast to properly format some of your data for you. If you have a validation chain, why do you need type checking? If you don't validate your data, type checking won't help. It would give a false sense of security, nothing more. In edge cases like you described, type checking leaves you with a broken app (fatal error / white page), while with type casting you'd have a kind of recoverable error that you could... recover from. In neither case your users care what happens internally, so IMO they should not be taken hostage of your design mistakes or your choice of libraries. And yes, if your app fails a typecheck, it means it fails with a fatal error and your users get frustrated. One use case I can think of is during testing, but in this case you can already do the same with a testing framework. Just declare the types in the comments and have the framework use those, but don't let them stand in the way the app actually works. Using strict type checks would be like hard coding your debugging breakpoints, would it not? Best regards, -- Guillaume Rossolini
Re: [PHP-DEV] back to 5.4 alpha
Zeev Suraski wrote: You're absolutely right, sorry about that! Zeev However if this is something controlled by php setup, it becomes another 'register_global'. If my users have to have it off for my projects and on for others ... complexity in managing instead :( At 23:11 11/08/2010, Alexey Zakhlestin wrote: You misunderstood my comment. Lester asked if he can still have his APIs without type-hinting and I told him that he can. That's all We're not talking about complexities of understanding -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 11 August 2010 21:59, Zeev Suraski z...@zend.com wrote: Consensus about what? About two similar features with slightly different syntax being a bad thing? I don't think we need consensus for that. That's not up for discussion. It's an axiom for PHP. Of course it depends on your definition of similar features. One feature checks the type of an argument, the other checks the value of an argument and casts it to another type if necessary. I see it as serving two different applications, just like == and === are meant for different things despite being two similar operators. See above. It would do everyone good if they don't just think about themselves and whether they're fine or not with a given feature, but about the impact it would have on the userbase at large. Not sure what kind of impact we're talking about here. Currently, there's no scalar type hinting and there will never be a consensus around strict XOR weak. Having an implementation that allows both while reusing a familiar syntax (parentheses as a way typecast) looks like the best (and perhaps only) way to move on. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
At 23:59 11/08/2010, Josh Davis wrote: Not sure what kind of impact we're talking about here. Currently, there's no scalar type hinting and there will never be a consensus around strict XOR weak. Having an implementation that allows both while reusing a familiar syntax (parentheses as a way typecast) looks like the best (and perhaps only) way to move on. Josh, No disrespect, but I can't explain why it's bad to have both implementations any better than I already did. If you don't see it, chances are that no matter how much I try to explain - it won't help - we probably see things too differently for us to ever agree on it. Let's end it by saying that a great deal of people here think it's horrible to introduce strict typing to PHP period. Whether we also add anything else at the same time doesn't change that one bit. Moving forward with both is certainly not the only option, I'd say (given the paragraph above) that it's not an option at all. At the very least, there's one other option which is doing nothing. And that's assuming we can't reach widespread consensus that auto-converting type hints are bad. The opposition to strict typing was that it's 'evil', and we mustn't introduce it into PHP. The opposition to auto-converting type hints was that strict typing is supposedly better. Now that strict typing is pretty clearly off the table - how would those that supported it vote between doing nothing at all and 'settling' for auto-converting type hints? That's the real question on the table now. For the record, I'm fine with both options, although personally I'd go for the latter. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
At 00:26 12/08/2010, Zeev Suraski wrote: Moving forward with both is certainly not the only option, I'd say (given the paragraph above) that it's not an option at all. At the very least, there's one other option which is doing nothing. And that's assuming we can't reach widespread consensus that auto-converting type hints are bad. s/bad/good -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Wed, Aug 11, 2010 at 8:30 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I think by now, whatever you think on strict typing/typehints, it is clear to everybody that there's no consensus about this feature, and with Rasmus, Zeev Andi, along with many others, being against it, as of now it can not be a part of an official PHP release. On the other hand, we have tons of cool features in trunk which aren't controversial and that we do want people to try out. So I'd propose doing the following: 1. Moving parameter typing to a feature branch (by branching current trunk and then rolling back the typing part in the trunk). 2. Starting 5.4 alpha process after that basing on trunk. Any objections to this? Yes. People that like the typing can still have them in the branch (and they can keep the branch as current as they want) and if we ever See The Light (TM) and want typed scalar parameters back, they're only a merge away. What do you think? I think using trunk as base is a mistake. We should begin using a stable branch (5.3) and merge what we want for the next release. It is also too early to begin to think about 5.4 as there is still a couple of things to clarify before. The most important ones being: - What are the top new things we like to have in - Define a clear release process (not going to go through a 5.3.0 or 6.0 again). - Define the RMs, I do want a good, honest and respectful RMs. The last point can wait as we are a couple of months away of defining the first two. For example I have a couple of very important things to add to the stack but I won't be able to describe them fully before September (I'm in holidays now, remember that 5.3.3 is a couple of weeks old...). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 11 August 2010 23:26, Zeev Suraski z...@zend.com wrote: matter how much I try to explain - it won't help - we probably see things too differently for us to ever agree on it. Let's end it by saying that a great deal of people here think it's horrible to introduce strict typing to PHP period. Sure, as long as you don't present your opinion as a fact and we acknowledge that a lot of people also think that type checking is desirable. (as evidenced by the various strict typing patches we have seen) I would never try to change your opinions. The opposition to strict typing was that it's 'evil', and we mustn't introduce it into PHP. Yes, and we know how overused the argument X is evil is. The opposition to auto-converting type hints was that strict typing is supposedly better. I think I read some mails to that effect the last time that discussion ran its course. Now that strict typing is pretty clearly off the table - how would those Wait, what? Clearly off the table? Derick has restarted the discussion 23 hours ago and judging from his last mail he his still writing a new patch and you're already calling it off the table ? =\ that supported it vote between doing nothing at all and 'settling' for auto-converting type hints? That's the real question on the table now. The only question I have read from a developer about what kind of type hints would satisfy the community was from Derick, 23 hours ago and the question was [supporting both kinds of typing] [s]hould make everybody happy (enough), right? - So right now I would say that it is literally the only question being asked. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Wed, 2010-08-11 at 23:34 +0200, Pierre Joye wrote: - What are the top new things we like to have in I would say * Traits * Aray dereferencing * $this support inclosures As language changes, in combination with performance improvements make a good package. This combined with removal of register_globals and safe mode make it a really big release already. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On Wed, Aug 11, 2010 at 23:26, Zeev Suraski z...@zend.com wrote: Now that strict typing is pretty clearly off the table [...] Did I miss a vote or something? The only thing I've seen is the same small group of people that has been fighting for the last few months. Your reasoning seems to be there are people who complained, so it's out, but there are plenty of people who haven't complained, so it's in is an equally justifiable position to take. Obviously people aren't going to sends loads of I think everything is perfectly fine-emails. PS: Can I get a list of the PHP axioms? Seeing as that's apparently how things are decided, it would be nice if people won't have to waste your precious time making obnoxious feature requests that are *clearly* against the PHP axioms. -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
At 00:58 12/08/2010, Josh Davis wrote: Now that strict typing is pretty clearly off the table - how would those Wait, what? Clearly off the table? Yes, clearly off the table. I'm not sure how long you've been on internals, but I'm not sure there's any precedence to such strong and diverse opposition to a feature - amongst both core developers, original authors and the community at large. At least I can't remember one in the last 13 years (it's been a long time though, maybe I forgot). It's completely independent from any other idea we might have in mind. Strict typing will not happen in PHP. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
Hi! I think using trunk as base is a mistake. We should begin using a stable branch (5.3) and merge what we want for the next release. It is also too early to begin to think about 5.4 as there is still a couple of things to clarify before. The most important ones being: Why have trunk then? 5.4 has a lot of things added to 5.3, merging them one-by-one to 5.3 would be just waste of time. - What are the top new things we like to have in - Define a clear release process (not going to go through a 5.3.0 or 6.0 again). - Define the RMs, I do want a good, honest and respectful RMs. Go ahead, do that :) The last point can wait as we are a couple of months away of defining the first two. For example I have a couple of very important things to add to the stack but I won't be able to describe them fully before September (I'm in holidays now, remember that 5.3.3 is a couple of weeks old...). It'd be alpha, you have enough time. -- 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] Strict typing
Daniel, In order to radically change PHP you need very strong consensus. If you don't have it, the status quo holds. Strict typing doesn't have anything remotely close to strong consensus. It doesn't really matter if a lot of people support it - there are also plenty of people who oppose it. Among them you have the original authors of the language, many core developers, and countless community members. That seals the deal - the status quo cannot change when so many oppose it - even if many support it. You should definitely take a closer look if you think that there's only a small group of people who oppose it. Recommended reading are this list and Johannes's blog. Zeev At 01:05 12/08/2010, Daniel Egeberg wrote: On Wed, Aug 11, 2010 at 23:26, Zeev Suraski z...@zend.com wrote: Now that strict typing is pretty clearly off the table [...] Did I miss a vote or something? The only thing I've seen is the same small group of people that has been fighting for the last few months. Your reasoning seems to be there are people who complained, so it's out, but there are plenty of people who haven't complained, so it's in is an equally justifiable position to take. Obviously people aren't going to sends loads of I think everything is perfectly fine-emails. PS: Can I get a list of the PHP axioms? Seeing as that's apparently how things are decided, it would be nice if people won't have to waste your precious time making obnoxious feature requests that are *clearly* against the PHP axioms. -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 12:14 AM, Stas Malyshev smalys...@sugarcrm.com wrote: It'd be alpha, you have enough time. Is it really the new way to do things in php.net? Totally ignore other developers, discuss things privately, act like the last of the last and drop a mail to officially announce a new release/big change? And then we feel forced to act? I cannot talk for the other, but for me it is a no-go, period. I'm totally against an alpha at this stage. Not before we have clarified all we need to get a clean release. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
Pierre, With all due respect, there are plenty of things already in trunk to make it a worth while effort to start planning the 5.4 release. Just because you disagree, an opinion you are entitled to (like everyone else), does not mean it is a no go, last I checked no one had veto powers on the future release process. Johannes had already outlined a number of major features/changes in 5.4 branch that are IMHO are definitely enough to start thinking about a new version. Waiting until we got every feature, idea considered will take an indefinite amount of time and unlikely to result in a release. Additionally, a really BIG 5.4 with tons of features will take that much longer to make stable that something with a more manageable changeset. 5.4 is not the *last* PHP release, there will defiantly be others and those version can encompass features that didn't make it into 5.4. The strict type / type hinting discussion aside there definitely appears to be a consensus among the core devs that 5.4 release process should start. On Wed, Aug 11, 2010 at 6:21 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Aug 12, 2010 at 12:14 AM, Stas Malyshev smalys...@sugarcrm.com wrote: It'd be alpha, you have enough time. Is it really the new way to do things in php.net? Totally ignore other developers, discuss things privately, act like the last of the last and drop a mail to officially announce a new release/big change? And then we feel forced to act? I cannot talk for the other, but for me it is a no-go, period. I'm totally against an alpha at this stage. Not before we have clarified all we need to get a clean release. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- 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] back to 5.4 alpha
Hi! I'm totally against an alpha at this stage. Not before we have clarified all we need to get a clean release. OK, so what do you propose to do? I.e., if you think there are things to be discussed, set the agenda. I think that besides typing, trunk is ok for alpha, you obvious don't think so. So, in your opinion: 1. What's missing and should be added? 2. What should be removed? 3. When you expect/want it to happen? -- 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] Strict typing
On Thu, Aug 12, 2010 at 12:11 AM, Zeev Suraski z...@zend.com wrote: At 00:58 12/08/2010, Josh Davis wrote: Now that strict typing is pretty clearly off the table - how would those Wait, what? Clearly off the table? Yes, clearly off the table. I'm not sure how long you've been on internals, but I'm not sure there's any precedence to such strong and diverse opposition to a feature - amongst both core developers, original authors and the community at large. At least I can't remember one in the last 13 years (it's been a long time though, maybe I forgot). Zeev, I think you underestimate the problem. The hinting (or whatever is the name of this pointless thing) is the least of the problems we have right now. To think that one guy considered that he is allowed to decide to fire a 5.4, announce it, all that without a single discussion in the public list is really bad. Even worst is that nobody actually even tries to say that it is not acceptable. And it happened more than once already. Yes, I sound and I am negative. Because it is a huge step backward for the PHP project. And I seriously think that it won't end well if we continue to act like that. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 12:27 AM, Ilia Alshanetsky i...@prohost.org wrote: Pierre, With all due respect, there are plenty of things already in trunk to make it a worth while effort to start planning the 5.4 release. Just because you disagree, an opinion you are entitled to (like everyone else), does not mean it is a no go, last I checked no one had veto powers on the future release process. Johannes had already outlined a number of major features/changes in 5.4 branch that are IMHO are definitely enough to start thinking about a new version. Waiting until we got every feature, idea considered will take an indefinite amount of time and unlikely to result in a release. Additionally, a really BIG 5.4 with tons of features will take that much longer to make stable that something with a more manageable changeset. 5.4 is not the *last* PHP release, there will defiantly be others and those version can encompass features that didn't make it into 5.4. The strict type / type hinting discussion aside there definitely appears to be a consensus among the core devs that 5.4 release process should start. I think you missed the point. Pierre isn't against the release, but against the current process. Tyrael
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 12:27 AM, Ilia Alshanetsky i...@prohost.org wrote: Pierre, With all due respect, there are plenty of things already in trunk to make it a worth while effort to start planning the 5.4 release. Just because you disagree, an opinion you are entitled to (like everyone else), does not mean it is a no go, last I checked no one had veto powers on the future release process. Right, and no one can decide alone when we have to begin a release. Please understand my point: I'm not saying we won't need to begin soon, but I do not accept the way it is done, the total lack of respect of the other core developers and the total lack of roadap, consensus or general agreement about what will be php-next. I have worked with all RMs since years as part of the release process (windows and other things like pear before). We are so bad at release management, dead lines, QA, BC between releases, etc. And what do we do to improve the situation? Absolutely nothing, however we prefer to let one person decides again what and when we have to do. Sorry, I can't and won't accept that. For the rest of this discussion, I will come back in time with proposals, obviously and as I have to. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 12 August 2010 00:11, Zeev Suraski z...@zend.com wrote: I'm not sure how long you've been on internals, but I'm not sure there's any precedence to such strong and diverse opposition to a feature - amongst both core developers, original authors and the community at large. I don't know, I remember some pretty strong words used against goto :) As for the community at large... I don't remember seeing a strong and diverse opposition to having both typechecking and smartcasting in PHP. If you have any links, perhaps that will help me grasp how strong and diverse the opposition is. Either way, let me skew your numbers a bit by using Ilia's blog post from last year [1] and earlier this year [2]. If that was my only benchmark I'd say that there is unanimous support for the implementation in current trunk. I guess it shows that different communities produce different opinions. [1] http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html [2] http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On Thu, 2010-08-12 at 01:21 +0200, Josh Davis wrote: Either way, let me skew your numbers a bit by using Ilia's blog post from last year [1] and earlier this year [2]. If that was my only benchmark I'd say that there is unanimous support for the implementation in current trunk. I guess it shows that different communities produce different opinions. [1] http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html [2] http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html Now compare it to the comments on my blog: http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html Yes, my blog posting reflects my opinion and therefore is manipulative by focusing on the negative effects. Both blog postings reach their audience via the same channels so they reach more or less the same people. But well, Ilia's audience only got the positive effects, mine got only the negative effects of the patch. To really judge it you need some time to think through it and probably even play with the patch (which I did, the blog posting only shows small parts, I'd have other examples where weird things happened, but they were too complex for a simple blog post) what nobody commenting in blogs does. But then even if there are many users out there: It is still this group here which has to maintain it. And why should I maintain anything I consider stupid and wrong for free for strangers? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
2010/8/12 Johannes Schlüter johan...@php.net: Yes, my blog posting reflects my opinion and therefore is manipulative Indeed. Depending where you'll look, you'll find big communities that have no clue about or no need for type hinting/checking/casting, some communities where strict typing is heresy, others where weak typing is seen as too lax, etc... All I've read on that topic was from small communities with targeted audiences, which produce some very polarized opinions. What would be interesting to see is what people think of Derick's latest proposal allowing both the strict typechecking and the more sensible weak typing (which I call smartcasting because you know, it does typecast stuff and prefixing it with smart make it sound better IMO.) It would weed out most of the knee-jerk reactions and focus on whether it solves problems or overly complicates things or makes them confusing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On 2010-08-11, Pierre Joye pierre@gmail.com wrote: On Thu, Aug 12, 2010 at 12:11 AM, Zeev Suraski z...@zend.com wrote: To think that one guy considered that he is allowed to decide to fire a 5.4, announce it, all that without a single discussion in the public list is really bad. Even worst is that nobody actually even tries to say that it is not acceptable. And it happened more than once already. I agree. During 5.3 development we made a step into the right directon of having a slightly more formal release process with more transparency, that includes decisions of active developers and not a decision of one guy. Ongoing discussions offlist do not help here. We should try to focus on the way we want to do the release and not fall back into who-shot-first-wins. Although I think it's good to have a 5.4 alpha soon, we first should try to clarify the way we want to release it (from trunk, from 5.4 branch with feature merges, RMs, strict typing, etc). - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 12:28 AM, Lester Caine les...@lsces.co.uk wrote:
Zeev Suraski wrote:
You're absolutely right, sorry about that!
Zeev
However if this is something controlled by php setup, it becomes another
'register_global'. If my users have to have it off for my projects and on
for others ... complexity in managing instead :(
Nothing is controlled by php setup.
It is perfectly ok to not specify type-hints in your functions.
both of these are fine:
function a($var) {}
function b(int $var) {}
you just keep using syntax of a and everything works. you CAN
specify typehint like in b but you don't have to.
p.s. if something is still not clear, let's take this talk away from list
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
Stas Malyshev wrote: I'm totally against an alpha at this stage. Not before we have clarified all we need to get a clean release. OK, so what do you propose to do? I.e., if you think there are things to be discussed, set the agenda. I think that besides typing, trunk is ok for alpha, you obvious don't think so. So, in your opinion: 1. What's missing and should be added? First thing perhaps ... which IS Pierre's problem ... Windows snapshots But short of trawling the commit tree ... what HAS already been added? ( links to the CURRENT release notes from the windows site are broken by the way ) 2. What should be removed? Without a clean list of what has been added Although I do seem to have missed something in 5.3.3 - where is the constructor in a namespaced class if it's not going to use the those that already exist in the source non-namespaced one. Not having been able to move TO php5.3 yet I seem to have missed that discussion. 3. When you expect/want it to happen? Perhaps some time after PHP5.3 is actually complete on all windows builds? Creating an Alpha of PHP-Trunk may be a way of creating the documentation that is currently missing to even discuss the above questions, but how many of those changes have even been tested on windows builds? Perhaps a move to a DVCS approach WOULD be a good thing. Nothing gets allowed back into the master without the necessary cross checks that there is agreement ... AND it has been fully tested across all builds? However I am personally of the opinion that DVCS is just creating a much bigger minefield for those projects that now depend on it completely :( A single master IS essential for stable production releases. Currently I am still working my way through the holes in PHP5.3.x which is why PHP5.2 is STILL the last stable release as far as my ( windows ) customer sites are concerned. SO sensible debate on the next step forward IS more important and simply pulling PHP even further apart? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
