This sounds very similar to preconditions in Design by Contract. However,
preconditions validate input to the method as a whole, while the proposed
syntax only checks individual arguments one at a time. Thus the proposed
syntax has rather significan limitations compared to real preconditions.
For
On Fri, July 10, 2009 10:50 am, Alban wrote:
Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
And
On Tue, July 21, 2009 11:22 am, Christian Schneider wrote:
Richard Lynch wrote:
I think anybody who is coding with strict/weak/contract
type-enforcement/casting is going to understand
try/catch/Exceptions...
I'm not going to start an pro/contra Exceptions rant but *please* keep
Exceptions
Richard Lynch wrote:
I think anybody who is coding with strict/weak/contract
type-enforcement/casting is going to understand
try/catch/Exceptions...
I'm not going to start an pro/contra Exceptions rant but *please* keep
Exceptions out of the core language itself, that's a line we should not
hi,
I'm still in favour of #2 (Ilia's patch) as I don't see a real benefit
of a weak typing implementation, it defeats the main goal of this
addition. I'm also still opposed to add such thing in 5.3.x.
Cheers,
On Thu, Jul 9, 2009 at 9:47 AM, Zeev Suraskiz...@zend.com wrote:
2. Move forward
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
}
Since $x is guaranteed to be
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
function addFive(is_numeric $x) {
return $x + 5;
2009/7/10 Ionut G. Stan ionut.g.s...@gmail.com
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would simply do:
On Fri, Jul 10, 2009 at 01:35:45PM +0300, Ionut G. Stan wrote:
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x) {
return $x + 5;
}
You would
2009/7/10 Alain Williams a...@phcomp.co.uk
On Fri, Jul 10, 2009 at 01:35:45PM +0300, Ionut G. Stan wrote:
On 7/10/2009 13:23, Giovanni Giacobbi wrote:
On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
[...]
For example, instead of:
function addFive(int $x)
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful than just calling the is_numeric method in the function
Le Thu, 09 Jul 2009 21:11:31 +0200, Geoffrey Sneddon a écrit :
On 9 Jul 2009, at 18:20, Lukas Kahwe Smith wrote:
On 09.07.2009, at 10:39, Paul Biggar wrote:
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. If people here find it
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on Strict / Weak question.
It is really about:
* type checking and enforcement
or
* type casting and generation of an error if the value cannot be converted
cleanly
Both of these have a
Please let me state that this is the greatest idea I read since the type
hinting discussion began (and the only one I personally like, as I find all the
other proposals really disappointing).
+1.
This contract system seems to be the best by far.
--
PHP Internals - PHP Runtime
Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
much more
useful
Alban wrote:
I don't understand why you focus on Strict / Weak question.
For me it's very simple, it's not obligatory use Type Hiting. Developpers
wants to write a weak code, they'll just have to not use Type Hiting and
developpers wants wrote a stric code they'll have to use it.
After,
On Fri, Jul 10, 2009 at 01:40:47PM +0200, Lukas Kahwe Smith wrote:
On 10.07.2009, at 13:20, Lewis Wright wrote:
3) function Foo(is_int($x)) {
Function is_int is called, an error is raised if it returns false.
But then you're complicating it to the point where it's no longer
Just to add a little fuel to this fire, should we allow the specification of
return
type of functions, eg:
function int Factorial(int $num) {...}
What about things that return FALSE on error, eg fgets(), something like this:
function (string, bool) fgets(resource $handle, int
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on Strict / Weak question.
It is really about:
* type checking and enforcement
or
* type casting and generation of an
2009/7/10 Alain Williams a...@phcomp.co.uk:
Just to add a little fuel to this fire, should we allow the specification of
return
type of functions, eg:
function int Factorial(int $num) {...}
What about things that return FALSE on error, eg fgets(), something like this:
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on Strict / Weak question.
It is really about:
* type
On 10.07.2009, at 17:16, Alain Williams a...@phcomp.co.uk wrote:
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit
And Exception is better than an Error because this give one chance to
programmer for resolving the
At 10:42 10/07/2009, Pierre Joye wrote:
hi,
I'm still in favour of #2 (Ilia's patch) as I don't see a real benefit
of a weak typing implementation, it defeats the main goal of this
addition. I'm also still opposed to add such thing in 5.3.x.
Can you elaborate on what is the main goal of this
Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 10:57:22AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 14:23:24 +0100, Alain Williams a écrit :
On Fri, Jul 10, 2009 at 08:45:55AM -0400, Alban wrote:
Hello all,
I don't understand why you focus on
On Fri, Jul 10, 2009 at 11:50:04AM -0400, Alban wrote:
Le Fri, 10 Jul 2009 16:16:51 +0100, Alain Williams a écrit :
The GET argument, yes, should be an integer, but it's possible is not !
In this, actually i always use this syntaxe :
is_child(intval($_GET['age']));
or
is_child( (int)
*You* do the above because you know that you should; (hopefully you do
other checks as well). One of the things that we are doing is trying to help the
naive/lazy programmer who doesn't bother - or thinks that javascript checking
is enough :-(
What we want to do is to generate an
Hi!
According to Zeev's description of the behavior this would cause a
fatal error, as $_GET['a'] cannot be converted to an integer value.. I
like that, but I think we need to devise a mechanism that allows you
to catch this error at runtime and write application logic around
it... In the
Hi!
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function body to
reduce code, increase readability and enable IDE's to be even smarter.
I think while intent is good (avoiding repetitive code) the
Hi!
This would be the perfect pairing. A library utilizing strict/enforced
types would surely want to indicate explicitly the return type.
To what use? PHP can't do static type checking, and for dynamic checking
specifying the type is useless - it's zval that gets checked, not the
On 10.07.2009, at 19:58, Stanislav Malyshev wrote:
Hi!
right .. lets not forget the original goal (though it hasnt been
perfectly defined)
the idea was to move common validation code out of the function
body to
reduce code, increase readability and enable IDE's to be even
smarter.
I
Hi Zeev,
I've been keeping a very close eye, and have taken part in a good few
discussions, including putting my own idea on the table.
On Thu, Jul 9, 2009 at 8:47 AM, Zeev Suraskiz...@zend.com wrote:
The options as I see them:
1. Do nothing. I think the vote established that this is not
At 11:39 09/07/2009, Paul Biggar wrote:
I believe nearly all opinions voiced have wanted the current patch.
Many more were in favour of strict typing only, but for the few
dissenters, like myself, Ilia included casting semantics using (int)
syntax.
I think that many of the people who expressed
On Thu, Jul 9, 2009 at 10:46 AM, Zeev Suraskiz...@zend.com wrote:
I believe that
if we had a 'clean' Weak typing RFC as well as a Strict typing RFC, each
with its pros and cons - there would be very different results.
The two approaches were never compared head-to-head, with the pros and cons
-Oorspronkelijk bericht-
Van: Zeev Suraski [mailto:z...@zend.com]
Verzonden: donderdag 9 juli 2009 11:46
Aan: Paul Biggar
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
At 11:39 09/07/2009, Paul Biggar wrote:
I believe nearly all
Hi Dennis,
On Thu, Jul 9, 2009 at 11:49 AM, Dennis Haarbrinkden...@born05.nl wrote:
The most important thing is that it is _optional_, you have the _choice_ to
use it.
Sorry to go a little bit off-topic, but this idea has been bandied
around a lot over the last week, and I'd like to respond to
2009/7/9 Zeev Suraski z...@zend.com:
Two other issues that we need to revisit:
1. Agree on when it will be implemented - I think it's pretty clear it
should not go to 5.3.
What would be the impact including this feature (once it is
*technically* fine for everybody) in 5.3 code with #ifdef's
On 09.07.2009, at 13:10, Patrick ALLAERT wrote:
2009/7/9 Zeev Suraski z...@zend.com:
Two other issues that we need to revisit:
1. Agree on when it will be implemented - I think it's pretty
clear it
should not go to 5.3.
What would be the impact including this feature (once it is
On 09.07.2009, at 12:49, Dennis Haarbrink wrote:
I'm a framework developer and I have great interest in type hinting/
casting.
I'm all for clarity and strictness, but it should definitely be a
choice.
PHP is known for its easy learning curve, that is one of its big
powers and
that should
On Thu, Jul 9, 2009 at 1:33 PM, Dennis Haarbrinkden...@born05.nl wrote:
I mean, libraries may have all kinds of quirks, you may not be satisfied with
the supplied API or maybe even the entire philosophy behind it, but that
shouldn't stop you from using it or is it?
You must learn what these
Hi Paul,
-Oorspronkelijk bericht-
Van: Paul Biggar [mailto:paul.big...@gmail.com]
Verzonden: donderdag 9 juli 2009 13:03
Aan: Dennis Haarbrink
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
Although the proposed checks are optional
Zeev Suraski wrote:
We need to go back to the fundamentals - and look for use cases where
strict typing would be substantially superior to weak typing.
I whole-heartedly agree. I can see some benefits of having weak typing
(even though I'm not desperate for it) and think it would better fit PHP
Lukas,
-Oorspronkelijk bericht-
Van: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
Verzonden: donderdag 9 juli 2009 14:01
Aan: Dennis Haarbrink
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
I think you misunderstood Zeev. He
-Oorspronkelijk bericht-
Van: Paul Biggar [mailto:paul.big...@gmail.com]
Verzonden: donderdag 9 juli 2009 14:40
Aan: Dennis Haarbrink
CC: internals@lists.php.net
Onderwerp: Re: [PHP-DEV] Type hinting - Request for Discussion
You must learn what these quirks are. Likewise, every
On 09.07.2009, at 10:39, Paul Biggar wrote:
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. If people here find it useful
I'll go
ahead and do that.
I believe people don't want this. I wrote a set of rules, Lukas wrote
the RFC,
On Thu, Jul 9, 2009 at 5:20 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote:
Actually, in terms of weak typing we are now at 4 supporters of the general
idea:
Paul B.,
Better make that 3 supporters. After seeing how complicated it was to
explain the semantics of a sensible middle, I think the
I want to remind everyone that this discussion is inadvertently sabotaging
the work/schedule of maintenance 5.3.x point releases, which we actually
need, for the 5.3 branch get to a point where it's stable enough to be used
in production.
So, knowing this can go on forever, it's time to pick
Hi list.
In advance, sorry for muddying the waters even further.
Following the current discussion about typehints to primitives, I'm
wondering if anyone have ever suggested to include some sort of
user-land contract system, such as the one that exists in
plt-scheme[1]
Given the dynamic nature
Hi!
Actually, in terms of weak typing we are now at 4 supporters of the
general idea:
Count me in, then :)
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To
On 9 Jul 2009, at 18:20, Lukas Kahwe Smith wrote:
On 09.07.2009, at 10:39, Paul Biggar wrote:
I think we can take Lukas's RFC and either change it or write
something
based on it for weak typing only. If people here find it useful
I'll go
ahead and do that.
I believe people don't want
Hi!
I am a userland developer, so please take my advice with caution. I am not
aware of the consequences of any of the implementations from an internals
point of view. However, since the main question here seems to be strict
against weak typing, or casting, I feel I should voice my opinion.
troels knak-nielsen wrote:
1) It covers all the use cases for a type-based system (You can use
`is_integer` as a contract, if you want that)
2) It's extensible in user-space, which means that it can be used to
convey much more accurate information, relevant to the application
needs.
3) It's
On Fri, Jul 10, 2009 at 2:28 AM, Josh
Thompsonspam.goes.in.h...@gmail.com wrote:
troels knak-nielsen wrote:
- How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function
troels knak-nielsen wrote:
- How do you know if it is a contract or the current object type hint?
The simplest solution would be to make one take precedence. You're not
likely to have both a class and a function with the same name, and if
you do, you kind of had it coming to you. For
All:
I'm in favor of this so-called Weak typing Zeev has proposed as
well, but I would like to see it become available in PHP before PHP 6.
That doesn't mean it has to go into 5.3.x, but I don't see why there
can't be a 5.4 that includes it. Personally, I think primitive typing
has a much more
54 matches
Mail list logo
