this one looks much more intuitive.
Tyrael
2009/7/2 Ford, Mike :
>
>
>> -Original Message-
>> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
>> Sent: 02 July 2009 14:05
>> To: Ilia Alshanetsky
>> Cc: Paul Biggar; PHP Internals; Derick Rethans; Stanislav Malyshev;
>> Hannes Magnusson
On Thu, Jul 2, 2009 at 9:09 PM, Ryan Panning wrote:
> Ford, Mike wrote:
>
>>function func(int $i)
>>
>> for strict type checking, and
>>
>>function func((int)$i)
>>
>> for coercion aka casting (although now I've seen it written down I'm not
>> so sure! ;).
>>
>
> Just want to throw my 2 c
Ford, Mike wrote:
function func(int $i)
for strict type checking, and
function func((int)$i)
for coercion aka casting (although now I've seen it written down I'm not
so sure! ;).
Just want to throw my 2 cents in.
Big +1 for this syntax
I think with the addition of this and __cast()
Hi
2009/7/2 Stanislav Malyshev :
> Without saying anything on the merits of having both syntaxes, visually I
> think this looks much nicer, even with the disadvantage of parentheses
> overload.
I agree, using the type cast operators for casting to the type, and
non parentheses for strict checking
Xyntrix wrote:
> Congratulations on the 5.3 milestone!
>
> Packaging the 5.3.0 stable release into an RPM (linux) will error as the
> bin/phar symlink is created using the build-time path variable. This has been
> submitted as bug:
>
> http://bugs.php.net/bug.php?id=48740
>
> Patch:
>
> --- p
Congratulations on the 5.3 milestone!
Packaging the 5.3.0 stable release into an RPM (linux) will error as the
bin/phar symlink is created using the build-time path variable. This has been
submitted as bug:
http://bugs.php.net/bug.php?id=48740
Patch:
--- php-5.3.0/ext/phar/Makefile.frag.orig
Hi!
function func(int $i)
for strict type checking, and
function func((int)$i)
Without saying anything on the merits of having both syntaxes, visually
I think this looks much nicer, even with the disadvantage of parentheses
overload.
--
Stanislav Malyshev, Zend Software Architect
> -Original Message-
> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
> Sent: 02 July 2009 14:05
> To: Ilia Alshanetsky
> Cc: Paul Biggar; PHP Internals; Derick Rethans; Stanislav Malyshev;
> Hannes Magnusson
> Subject: Re: [PHP-DEV] Re: Flexible type hinting
>
>
> On 02.07.2009,
On Thu, Jul 02, 2009 at 09:59:43AM -0700, Stanislav Malyshev wrote:
> >A big +1 from me to incorporate type hinting into PHP.
>
> I think calling this proposal "type hinting" just confuses the
> discussion. It's (optional) strict typing and it should be called so.
+1
But first we must fix the
Hi!
Doesn't "stuff their code with explicit type conversions" actually
mean "perform appropriate validation and conversion on incoming data"
?
Sometimes it does, but in many cases it doesn't - since variables are
not typed and types can be juggled, you'd have to take precautions even
though
Hi!
Are optional argument specifications inherited? I did not think they
were, but its not clear if you are saying they are.
Of course they are - how couldn't they be, they are part of method
definition.
My understanding of PHP's optional arguments is that they only apply
to a function onc
2009/7/2 troels knak-nielsen :
> [snip] ... - I don't remember ever
> seen __construct() called directly.
Its commonly done when extending reflection for example, or to
populate the Exception class constructor when extending it:
code = (integer) $code;
parent::__construct($message);
troels knak-nielsen wrote:
> On Thu, Jul 2, 2009 at 4:47 PM, Edward Z. Yang wrote:
>> Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400
>> 2009:
>>> I would have expected the second call to __construct() to yield an error.
>> Why should it? Especially since this is idiomatic
Excerpts from troels knak-nielsen's message of Thu Jul 02 10:55:48 -0400 2009:
> I understand that. It's not a technical issue - It's more a matter of
> language semantics. Constructors are used for initializing state on an
> object. Basically, this behaviour makes it impossible to implement
> immu
On Thu, Jul 2, 2009 at 4:47 PM, Edward Z. Yang wrote:
> Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400 2009:
>> I would have expected the second call to __construct() to yield an error.
>
> Why should it? Especially since this is idiomatic code:
>
> class A {
> public fun
2009/7/2 Paul Biggar
> On Thu, Jul 2, 2009 at 3:17 PM, Jonathan Bond-Caron
> wrote:
> > From userland, I'm a big fan of this proposal / agree to the principle
> although I'm not convinced that
> >
> > function($quantity)
> > function(int $quantity)
> > function(+int $quantity)
> > function(-int $
Excerpts from troels knak-nielsen's message of Thu Jul 02 10:14:18 -0400 2009:
> I would have expected the second call to __construct() to yield an error.
Why should it? Especially since this is idiomatic code:
class A {
public function __construct($a) {
$this->a = $a;
}
}
class B extend
2009/7/2 troels knak-nielsen :
> Has this been discussed before? In that case, was it decided to go
> with this behaviour or is it purely accidental? Are there perhaps some
> implementation issues in preventing the second call to __construct()?
Magic methods can always be called directly because t
On Thu, Jul 2, 2009 at 3:17 PM, Jonathan Bond-Caron wrote:
> From userland, I'm a big fan of this proposal / agree to the principle
> although I'm not convinced that
>
> function($quantity)
> function(int $quantity)
> function(+int $quantity)
> function(-int $quantity)
>
> looks appropriate...
>
>
On Thu Jul 2 08:53 AM, Paul Biggar wrote:
> On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote:
> >
> > On 2-Jul-09, at 4:45 AM, Paul Biggar wrote:
> >> I think you might not have read what I suggested (it is different
> >> than the one I emailed to you privately). What you want is fully
> sup
On 2-Jul-09, at 10:02 AM, Paul Biggar wrote:
On Thu, Jul 2, 2009 at 1:53 PM, Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it allows
weak type
hinting, which should not be used if you need type hinting. The
whole idea
about type hinting is definition of st
I just realised that the following is valid php code:
class Foo {
function __construct() {
echo "constructor called\n";
}
}
$f = new Foo();
$f->__construct();
Output:
constructor called
constructor called
I would have expected the second call to __con
On Thu, Jul 2, 2009 at 1:53 PM, Ilia Alshanetsky wrote:
> Paul's proposal is some part does not make sense because it allows weak type
> hinting, which should not be used if you need type hinting. The whole idea
> about type hinting is definition of strict interfaces, not loosely based
> one. That'
Ilia Alshanetsky wrote:
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it allows
weak type hinting, which should not be used if you need type
hinting. The whole idea about type hinting is definition of stri
Ilia Alshanetsky wrote:
On 2-Jul-09, at 9:23 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it
allows weak type hinting, which should not be used if you
2009/7/2 Robert Cummings :
> Ionut G. Stan wrote:
> I think it should be E_WARNING with auto type juggling if bad data comes
> through. This way it behaves as normal PHP code does without special
> handling to mitigate a script failure. The log files will still alert you to
> the problem, and if yo
On 2-Jul-09, at 9:23 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it
allows weak type hinting, which should not be used if you need
type hinting. The
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it allows
weak type hinting, which should not be used if you need type
hinting. The whole idea about type hinting is definition of strict
interfaces, not lo
On 02.07.2009, at 15:02, Ilia Alshanetsky wrote:
Personally, I am uncertain about +int or -int in general, IMO that
compromise will eventually be identical to numeric an cause endless
confusion for the users between (+/-)int and int. The reason I used
a completely different name is to prev
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it allows
weak type hinting, which should not be used if you need type hinting.
The whole idea about type hinting is definition of strict interfaces,
not loosely based one. That's just my opinion, which admitte
Personally, I am uncertain about +int or -int in general, IMO that
compromise will eventually be identical to numeric an cause endless
confusion for the users between (+/-)int and int. The reason I used a
completely different name is to prevent confusion.
On 2-Jul-09, at 8:53 AM, Paul Bigg
On 2-Jul-09, at 4:56 AM, Lukas Kahwe Smith wrote:
On 02.07.2009, at 10:45, Paul Biggar wrote:
to work in a future with a library/framework that is strict about
its input
or some far fetched idea that it will change the very nature of PHP.
I don't think we are worried about it changing PH
On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote:
>
> On 2-Jul-09, at 4:45 AM, Paul Biggar wrote:
>> I think you might not have read what I suggested (it is different than
>> the one I emailed to you privately). What you want is fully supported.
>> If you must be passed an int, use the +int h
On 2-Jul-09, at 4:45 AM, Paul Biggar wrote:
On Thu, Jul 2, 2009 at 5:26 AM, Ilia Alshanetsky wrote:
1) Strict type hinting helps to solve bugs, both the ones made out of
careless/missing validation as well as subtle logic bugs that often
take
hours to resolve. I can tell you that within a w
On 2-Jul-09, at 3:28 AM, Stanislav Malyshev wrote:
Hi!
2) Type hinting will not create a mess of cast to the right types
in the code as Stas had suggested, in close to a million lines of
PHP code we have, I've been able to find less then 1000 (just did a
grep) instances of casts. There i
Hi,
I recommend that you sign up on the wiki and publish your proposal on
wiki.php.net/rfc
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2009/7/1 Stanislav Malyshev :
> Hi!
>
>> The patch is available here: http://ia.gd/patch/type_hint_53.txt
>
> Technical comment: as this patch changes binary API this shouldn't happen in
> 5.3 branch. So maybe it's better to make it for 6.
>
> As for the idea itself, it is obvious that many people
Ionut G. Stan wrote:
On 7/2/2009 13:56, Hannes Magnusson wrote:
Actually, I'd use an exception class which extends from the builtin
ErrorException
class, but that's not the point. Anyway, probably Kalle Sommer Nielsen
is right,
and the way PHP already behaves in that regard should be kept.
On 7/2/2009 13:56, Hannes Magnusson wrote:
Actually, I'd use an exception class which extends from the builtin
ErrorException
class, but that's not the point. Anyway, probably Kalle Sommer Nielsen
is right,
and the way PHP already behaves in that regard should be kept. At least
for now.
I'm an advocate for introducing optional type hinting as I write many
assert('is_*($foo)') a day.
On Thu, Jul 2, 2009 at 9:28 AM, Stanislav Malyshev wrote:
> And there's only two ways to do it - either make absolutely all functions
> and variables that interact with typehinted functions to be st
On Thu, Jul 2, 2009 at 11:24, Ionut G. Stan wrote:
> Hi,
>
> I'm a userland developer with limited C skills, and while I don't yet have
> an
> opinion on the whole type enforcing issue, aside from a fear of libraries
> abusing
> it, I'd like to propose a little change in the patch.
>
> Is it possib
Nick Cooper wrote:
Does anyone have any further information on the PECL Binaries for 5.3, will
they be released?
I don't, but I suspect it is just a matter of compile + test.
On Linux (CentOS) I've only done testing with i386 but none of the pecl
modules I personally am using w/ 5.2.9 failed
Hi
2009/7/2 Ionut G. Stan :
> Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to
> be thrown? I don't know whether InvalidArgumentException satisfies the
> semantics,
> but it's a step in that direction.
I don't think we should start changing the standard way of the engine
to
In Ilia's type hinting patch, on line 255, is the line:
+"string"|"binary"|"unicode" {
This failed for me. I fixed it by changing it to:
+("string"|"binary"|"unicode") {
Which matches all the other lexing rules for type hints. My
understanding of the lexer is insufficient to understand why t
Hi,
I'm a userland developer with limited C skills, and while I don't yet
have an
opinion on the whole type enforcing issue, aside from a fear of
libraries abusing
it, I'd like to propose a little change in the patch.
Is it possible that instead of an E_RECOVERABLE_ERROR, an Exception to
be t
Does anyone have any further information on the PECL Binaries for 5.3, will
they be released?
2009/6/30 pan
> Lukas Kahwe Smith wrote:
> >> Hello!
> >>
> >> The PHP Development Team would like to announce the immediate release
> >> of PHP 5.3.0. This release is a major improvement in the 5.X ser
On 02.07.2009, at 10:45, Paul Biggar wrote:
to work in a future with a library/framework that is strict about
its input
or some far fetched idea that it will change the very nature of PHP.
I don't think we are worried about it changing PHP, or about libraries
using strict type hints. We are
On Thu, Jul 2, 2009 at 5:26 AM, Ilia Alshanetsky wrote:
> 1) Strict type hinting helps to solve bugs, both the ones made out of
> careless/missing validation as well as subtle logic bugs that often take
> hours to resolve. I can tell you that within a week of implementing type
> hints we've been a
On Thu, Jul 2, 2009 at 9:27 AM, Stanislav Malyshev wrote:
> There is a functionality handling default values (or, more precisely,
> optional arguments) with inheritance, etc.
Are optional argument specifications inherited? I did not think they
were, but its not clear if you are saying they are.
M
Hi!
I don't think we need to worry about this. Consider it to be the same
as default values. So yes, yes, allowed but dont do anything since
those functions are never called.
There is a functionality handling default values (or, more precisely,
optional arguments) with inheritance, etc. And i
On Thu, Jul 2, 2009 at 8:28 AM, Stanislav Malyshev wrote:
> Also, looking at the patch I think it doesn't cover the matter of inheriting
> the typehinted methods - i.e. if there's a typehinted method, could I
> override it with non-typehinted version or vice versa? What about typehinted
> interface
I sent this message to the php.soap newsgroup, but noone answered me.
Today I found a nasty problem with a simple php SOAP client. Never had
problems before, but today I have the following error at SOAPClient
constructor line:
SoapClient::SoapClient(http://www.w3.org/2001/xml.xsd): failed to ope
Hello,
For what it's worth, a large +1 from me.
One concern I do have, however, is that the addition of scalar type hints
will put more attention to the lack of method overloading. Right now methods
can accept multiple values due to the type-lessness, and while it will
remain a possibility, c
Hi!
2) Type hinting will not create a mess of cast to the right types in the
code as Stas had suggested, in close to a million lines of PHP code we
have, I've been able to find less then 1000 (just did a grep) instances
of casts. There is a good reason for that once you get out of the input
p
54 matches
Mail list logo
