It really doesn't fit in very well with PHP's loosely typed nature which
is one of the main reasons it has been so easy to use.
I think this is one of the cornerstones that two sides disagree the most on.
People are afraid that PHP would turn into a strong-typed language by
allowing type
On Thu, 3 Jan 2008, Stanislav Malyshev wrote:
I don't get it. We already have type hinting, just not for scalars. The
Type hinting for scalars is different because it disables one of the features
of PHP language - conversion of scalar types into each other.
It doesn't disable this. It's
On Thu, 3 Jan 2008, Sam Barrow wrote:
It doesn't disable type conversion unless you specifically tell it to.
Plus the fact that if it issues an E_WARNING, your application will not
necessarily stop execution.
Stop right here for a moment. Type hints currently throw an
E_RECOVERABLE_ERROR,
On Thu, 3 Jan 2008, Sam Barrow wrote:
On Thu, 2008-01-03 at 22:37 +0100, Markus Fischer wrote:
Of course, Jochem, you're right. Exceptions would be nice.
WrongArgumentException, InvalidWhateverException, ...
That would be very nice. The full blown suite of exception error
handlers
Hi.
I've been trying to get a sensible understanding of the for's and
against's of the optional scalar type hinting question.
With that I have a few points and a question.
1 - In the main, PHP is used to create web pages and to deal with data
coming from the user.
2 - In the main, the data
On Fri, 2008-01-04 at 10:55 +, Alain Williams wrote:
On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty
Hi Markus,
Thanks for testing out the patch!
Has anyone else had a chance to test it out? I think this is a good
solution to the naming conflict issue that is currently present with
namespaces, but I'd love to hear other's opinions/experiences on this.
--
Jessie Hernandez
Zend Certified
On Thu, 2008-01-03 at 15:58 -0600, Brian Moon wrote:
I don't get it. We already have type hinting, just not for scalars.
The discussion seems to be about whether or not we should have it all.
But, the truth is, we have it. We half way have it. I fought for it to
be all or nothing back
On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.
In fact,
On Fri, 2008-01-04 at 10:06 +0200, Tomi Kaistila wrote:
It really doesn't fit in very well with PHP's loosely typed nature which
is one of the main reasons it has been so easy to use.
I think this is one of the cornerstones that two sides disagree the most on.
People are afraid that PHP
On Fri, 2008-01-04 at 09:52 -0600, Gregory Beaver wrote:
Alain Williams wrote:
On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say
To add another two points to Stefan's argument. Type hinting does not
remove the need to filter user input, but it does allow you to safe-
guard internal functions (library code etc...) against accidental or
internal misuse or improper handling of the data in the front-end
layer. It also
On Fri, 2008-01-04 at 17:53 +0100, Pierre wrote:
On Jan 4, 2008 5:53 PM, Pierre [EMAIL PROTECTED] wrote:
On Jan 4, 2008 4:52 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
But I *don't* want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point.
Alain Williams wrote:
On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make
Good Morning everyone,
one should not forget that type hinting has some clear advantages the
anti type hinting advocates always try to forget...
* the code gets smaller because not so many typechecks in every function
* because the code gets smaller it is faster executed (userspace
typecheck is
On Jan 4, 2008 5:53 PM, Pierre [EMAIL PROTECTED] wrote:
On Jan 4, 2008 4:52 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
But I *don't* want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem
On Jan 4, 2008 4:52 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
But I *don't* want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point. A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.
My
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.
marcus
Friday, January 4, 2008, 5:53:56 PM, you wrote:
On Jan 4,
On Fri, 2008-01-04 at 11:51 -0500, Ilia Alshanetsky wrote:
To add another two points to Stefan's argument. Type hinting does not
remove the need to filter user input, but it does allow you to safe-
guard internal functions (library code etc...) against accidental or
internal misuse or
On Jan 4, 2008 6:01 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-01-04 at 17:53 +0100, Pierre wrote:
On Jan 4, 2008 5:53 PM, Pierre [EMAIL PROTECTED] wrote:
On Jan 4, 2008 4:52 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
But I *don't* want my functions to take an argument of
On Fri, 2008-01-04 at 18:09 +0100, Pierre wrote:
On Jan 4, 2008 6:01 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-01-04 at 17:53 +0100, Pierre wrote:
On Jan 4, 2008 5:53 PM, Pierre [EMAIL PROTECTED] wrote:
On Jan 4, 2008 4:52 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
On Fri, 2008-01-04 at 09:52 -0600, Gregory Beaver wrote:
Alain Williams wrote:
On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say
On Fri, 2008-01-04 at 17:41 +0100, Stefan Esser wrote:
Good Morning everyone,
one should not forget that type hinting has some clear advantages the
anti type hinting advocates always try to forget...
* the code gets smaller because not so many typechecks in every function
True.
*
On Fri, 2008-01-04 at 12:48 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 12:41 -0500, Sam Barrow wrote:
On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
On Fri, Jan 04, 2008 at 12:11:41PM -0500, Sam Barrow wrote:
Exactly. I just added the mixed type hint which is the same as using
no type hint. The new patch is attached.
Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool,
On Jan 4, 2008, at 6:37 PM, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional
On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight
* the code gets smaller because not so many typechecks in every function
What do you mean not so many? You need one per checked parameter.
* because the code gets smaller it is faster executed (userspace
typecheck is slower than engine-space)
If you need single-opcode-level speedups, you
On Fri, 2008-01-04 at 18:44 +0100, Lukas Kahwe Smith wrote:
On Jan 4, 2008, at 6:37 PM, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro argument.
Hi Sam,
Am Freitag, den 04.01.2008, 12:11 -0500 schrieb Sam Barrow:
[...]
Exactly. I just added the mixed type hint which is the same as using
no type hint. The new patch is attached.
[...]
To make your patch better you should add a bunch of test cases. Just a
test brainstorming:
*
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason.
On Fri, 2008-01-04 at 17:51 +, Alain Williams wrote:
On Fri, Jan 04, 2008 at 12:37:19PM -0500, Robert Cummings wrote:
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter
On Fri, 2008-01-04 at 12:41 -0500, Sam Barrow wrote:
On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro
On Fri, 2008-01-04 at 17:46 +, Alain Williams wrote:
On Fri, Jan 04, 2008 at 12:11:41PM -0500, Sam Barrow wrote:
Exactly. I just added the mixed type hint which is the same as using
no type hint. The new patch is attached.
Extra keywords (real, long, double, etc.) have been taken
On Fri, 2008-01-04 at 12:51 -0500, Sam Barrow wrote:
On Fri, 2008-01-04 at 12:48 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 12:41 -0500, Sam Barrow wrote:
On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4,
On Fri, 2008-01-04 at 12:53 -0500, Sam Barrow wrote:
On Fri, 2008-01-04 at 17:51 +, Alain Williams wrote:
On Fri, Jan 04, 2008 at 12:37:19PM -0500, Robert Cummings wrote:
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and
See below:
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 5:47 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
We've
[**] I suppose that we might implement the type hint 'mixed' which would
have the same effect as no type hint. Some people might like this from
the 'internal documentation' point of view.
And the purpose of that exercise would be?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
layer. It also makes the code far more readable and understandable not
the mention help doc generation tools that interrogate the code.
I was under impression that it is good manners to actually document your
code and not rely on the tools to interrogate your code. Of course,
not everybody
On 4-Jan-08, at 1:20 PM, Stanislav Malyshev wrote:
layer. It also makes the code far more readable and understandable
not the mention help doc generation tools that interrogate the code.
I was under impression that it is good manners to actually document
your code and not rely on the
On Fri, Jan 04, 2008 at 12:37:19PM -0500, Robert Cummings wrote:
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should
On Fri, 2008-01-04 at 13:22 -0500, Ilia Alshanetsky wrote:
On 4-Jan-08, at 1:20 PM, Stanislav Malyshev wrote:
layer. It also makes the code far more readable and understandable
not the mention help doc generation tools that interrogate the code.
I was under impression that it is good
On Fri, 2008-01-04 at 18:46 +, Alain Williams wrote:
On Fri, Jan 04, 2008 at 01:06:26PM -0500, Robert Cummings wrote:
?php
echo 'Foo: '.(0 + '5five').\n;
echo 'Foo: '.((int)'5five').\n;
echo 'Foo: '.(intval( ' 5five' )).\n;
echo 'Foo: '.(sprintf( '%d', '5five'
On Fri, 2008-01-04 at 10:37 -0800, Andi Gutmans wrote:
I think the mixed identifier is a minor issue but I also don't see
it's purpose. If you don't want type hinting then don't write a type
hint. It's also tool friendly...
Andi
It is kind of pointless, just syntactic sugar to be honest. Not
On Fri, 2008-01-04 at 10:35 -0800, Stanislav Malyshev wrote:
It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a complicated feature then they shouldn't. I
Not an argument.
don't think cutting the legs out from developers who want to use said
On Fri, 2008-01-04 at 10:28 -0800, Stanislav Malyshev wrote:
Exactly. I just added the mixed type hint which is the same as using
no type hint. The new patch is attached.
IMO adding new type hint for the sole purpose of having some string next
to the variable is just silly. If you need
I've stated my opinion on this, I'm going for standard hinting. Int
means int, not 1 or one or 1one. Bool means boolean true or false,
I don't see any difference in substance between 1 and 1.
not true, 1, 0, 0, etc.
Same for boolean - I don't see any substantial difference between
(int)0,
On Fri, 2008-01-04 at 10:59 -0800, Stanislav Malyshev wrote:
Not necessarily, if you have a function that performs a generic
operation on any object. As for resources you are right, it might be
Like what? I don't know many operations that are good for any object and
only object and need
On Fri, 2008-01-04 at 11:26 -0800, Stanislav Malyshev wrote:
A language that can be used for large scale applications, with tons of
extensions for integration with many third party applications and
protocols. PHP is no longer a form submitter/emailer.
Hey, you are right, it isn't! It is
This is not what we are doing. We are not changing PHP into a
type-strict language. This is type hinting. This is completely
different.
For type hinting that you propose to work, you need to change PHP into
type-strict language.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
On Fri, 2008-01-04 at 11:20 -0800, Stanislav Malyshev wrote:
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string Array instead once you handle it.
If it's a problem, then having Array from the start is a problem too.
Yes, and the type
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string Array instead once you handle it.
If it's a problem, then having Array from the start is a problem too.
with that. And I said standardized way, ie bool true outputs as 1,
float 5.20
On Fri, Jan 04, 2008 at 02:06:09PM -0500, Sam Barrow wrote:
No, it's not better. Having GD image instead of mysql connection is not
better than having integer in any way. It would just produce different
error message, so what?
That's actually very true.
But the liklyhood is that the
What's smaller, type checking with parameter type hinting, or manually
using is_int, is_string, etc?
Smaller from what POV? Developer-side, it's the same - one check there,
one check here. Execution-side, since is_integer is a function and not
operation, it's a tiny bit slower, but as I said,
Exactly. I just added the mixed type hint which is the same as using
no type hint. The new patch is attached.
IMO adding new type hint for the sole purpose of having some string next
to the variable is just silly. If you need documentation, use documentation.
Extra keywords (real, long,
On Fri, 2008-01-04 at 10:08 -0800, Andi Gutmans wrote:
See below:
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 5:47 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] RE: Optional scalar type hinting
On
It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a complicated feature then they shouldn't. I
Not an argument.
don't think cutting the legs out from developers who want to use said
features is the solution. I mean we're all programmers around
I think the mixed identifier is a minor issue but I also don't see
it's purpose. If you don't want type hinting then don't write a type
hint. It's also tool friendly...
Andi
-Original Message-
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 10:23 AM
To:
On Fri, 2008-01-04 at 13:02 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 12:51 -0500, Sam Barrow wrote:
On Fri, 2008-01-04 at 12:48 -0500, Robert Cummings wrote:
On Fri, 2008-01-04 at 12:41 -0500, Sam Barrow wrote:
On Fri, 2008-01-04 at 12:37 -0500, Robert Cummings wrote:
On
IMHO, optionally inclusion of type hinting for functions/methods can
only be a boon to code quality and readability. IMHO when a type hint is
provided and a parameter doesn't match the type hint then I think a
fatal error should occur. This forces the user of the function that has
So you code
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.
OO mandates you to work in certain way. However, the way PHP works with
values was never type-strict and there's no reason to suddenly change
Look it boils down to the following:
True type enforcement ala === (i.e. you pass 1 to an int and it errors
out) does not make sense for PHP (and yes, philosophy and design goals
of the language are important). Forget even the argument that this is
not how PHP works all around and is inconsistent
Not necessarily, if you have a function that performs a generic
operation on any object. As for resources you are right, it might be
Like what? I don't know many operations that are good for any object and
only object and need special function to perform them. Actually,
excluding scenarios
Well PHP is changing into an enterprise-level language now. Out with the
What is enterprise-level language?
old, in with the new. And I'm sure there were some developers who did
want this feature but didn't necessarily say anything.
So what? There are developers that don't want this feature
You are right. I should have written... I don't think preventing
developers from building a stronger foundation upon which they can stand
is the solution.
Nobody prevents you from building any foundation. I am convinced that in
fact using of typehints as proposed now would lead to worse, not
On Fri, 2008-01-04 at 11:01 -0800, Stanislav Malyshev wrote:
Well PHP is changing into an enterprise-level language now. Out with the
What is enterprise-level language?
A language that can be used for large scale applications, with tons of
extensions for integration with many third party
On Fri, 2008-01-04 at 11:04 -0800, Stanislav Malyshev wrote:
Well it would be much easier to type hint than to manually document
every one of your function parameters.
How is this:
/* @param $client string Contains the name of the client for the account
is worse or less clear or
On Fri, 2008-01-04 at 10:30 -0800, Stanislav Malyshev wrote:
To make it optional was to lower the issues for those who don't care
about argument strictness. We did not give them this choice for the OO
strictness.
OO mandates you to work in certain way. However, the way PHP works with
Stanislav Malyshev schrieb:
* the code gets smaller because not so many typechecks in every function
What do you mean not so many? You need one per checked parameter.
There is a difference in complexity between a userlevel type check and a
low level type check.
* with type hints byte code
On Fri, 2008-01-04 at 10:23 -0800, Stanislav Malyshev wrote:
* the code gets smaller because not so many typechecks in every function
What do you mean not so many? You need one per checked parameter.
What's smaller, type checking with parameter type hinting, or manually
using is_int,
On Fri, 2008-01-04 at 10:35 -0800, Stanislav Malyshev wrote:
It's funny sometimes the complaints about too complicated. I mean, if
people don't want to use a complicated feature then they shouldn't. I
Not an argument.
don't think cutting the legs out from developers who want to use said
It is kind of pointless, just syntactic sugar to be honest. Not a big
More like syntactic used motor oil IMHO ;)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing
Definitely not. Type hints now throw E_RECOVERABLE_ERROR, and that
should be the same for any other typehinting system that we add.
Then we don't add any, because without static type control it's just a
ticking timebomb waiting to blow up your production code (and having
application display
On Fri, 2008-01-04 at 19:19 +, Alain Williams wrote:
On Fri, Jan 04, 2008 at 02:06:09PM -0500, Sam Barrow wrote:
No, it's not better. Having GD image instead of mysql connection is not
better than having integer in any way. It would just produce different
error message, so what?
On Fri, 2008-01-04 at 20:13 +0100, Stefan Esser wrote:
Stanislav Malyshev schrieb:
* the code gets smaller because not so many typechecks in every function
What do you mean not so many? You need one per checked parameter.
There is a difference in complexity between a userlevel type check and
A language that can be used for large scale applications, with tons of
extensions for integration with many third party applications and
protocols. PHP is no longer a form submitter/emailer.
Hey, you are right, it isn't! It is actually used right now for large
scale applications, with tons of
About the same, but the @param comment doesn't stop someone from putting
an array into $client.
No, it doesn't. The function should handle that.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP
On Fri, 2008-01-04 at 11:27 -0800, Stanislav Malyshev wrote:
About the same, but the @param comment doesn't stop someone from putting
an array into $client.
No, it doesn't. The function should handle that.
Ok, in a bunch of extra unwanted code and a call to trigger_error(). Or
we could
On Fri, 2008-01-04 at 17:46 +, Alain Williams wrote:
On Fri, Jan 04, 2008 at 12:11:41PM -0500, Sam Barrow wrote:
Exactly. I just added the mixed type hint which is the same as using
no type hint. The new patch is attached.
Extra keywords (real, long, double, etc.) have been taken
On Fri, 2008-01-04 at 11:20 -0800, Stanislav Malyshev wrote:
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string Array instead once you handle it.
If it's a problem, then having Array from the start is a problem too.
with that.
Good point. We were fine before OO and exceptions too weren't we.
No, actually we weren't as fine. OO allowed for application frameworks
and libraries to flourish.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
I'd prefer that than have garbage in the database.
If your application drops dead in the middle of work because some handle
can't process the data your database probably won't be in the best shape
anyway.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
Hi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
that you can actually make sure to say something novel. What would be
even
On Fri, 2008-01-04 at 11:52 -0800, Stanislav Malyshev wrote:
Good point. We were fine before OO and exceptions too weren't we.
No, actually we weren't as fine. OO allowed for application frameworks
and libraries to flourish.
Now that we have them, we can help them become more robust by
On Fri, 2008-01-04 at 18:20 +0100, Marcus Boerger wrote:
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional to vote against it. We do this
for a reason. That is we only want to support mainstream features.
What
On Fri, 2008-01-04 at 11:54 -0800, Stanislav Malyshev wrote:
I'd prefer that than have garbage in the database.
If your application drops dead in the middle of work because some handle
can't process the data your database probably won't be in the best shape
anyway.
Yes, it drops dead, I
There is a difference in complexity between a userlevel type check and a
low level type check.
Rather minimal.
How should one have an optimizer for that as long PHP does not have this
feature? Noone would implement one that is capable of doing this not
knowing if the feature ever makes it
On Fri, 2008-01-04 at 11:27 -0800, Stanislav Malyshev wrote:
This is not what we are doing. We are not changing PHP into a
type-strict language. This is type hinting. This is completely
different.
For type hinting that you propose to work, you need to change PHP into
type-strict
Ok deal.
On Fri, 2008-01-04 at 21:19 +0100, Lukas Kahwe Smith wrote:
Hi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
Also true, and the resource hint is still useful for documentation and
clarity of code. Better than no type hint I'd say.
Documentation belongs to documentation. We already have perfectly good
phpdoc.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
On Fri, 2008-01-04 at 11:27 -0800, Stanislav Malyshev wrote:
This is not what we are doing. We are not changing PHP into a
type-strict language. This is type hinting. This is completely
different.
For type hinting that you propose to work, you need to change PHP into
type-strict
On Jan 4, 2008 8:20 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string Array instead once you handle it.
If it's a problem, then having Array from the start is a problem too.
with
On Fri, 2008-01-04 at 20:51 +0100, Pierre wrote:
On Jan 4, 2008 8:20 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Ok but if someone inputs an array in the query string i have a problem
Which problem? OK, you'd have string Array instead once you handle it.
If it's a problem, then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Robert Cummings wrote:
| On Fri, 2008-01-04 at 11:52 -0800, Stanislav Malyshev wrote:
| Good point. We were fine before OO and exceptions too weren't we.
| No, actually we weren't as fine. OO allowed for application frameworks
| and libraries to
At least I suggest that people limit themselves to max 1 email per hour
(incl. Stas Sam) - preferably 2-3 per day. Just take a 1-2 hour
breather after you've sent an email and then read the whole thread that
comes back and answer multiple arguments in one email.
Seriously, the person answering
Andi Gutmans wrote:
Look it boils down to the following:
True type enforcement ala === (i.e. you pass 1 to an int and it errors
out) does not make sense for PHP (and yes, philosophy and design goals
of the language are important).
What I suggested in my previous email is type hinting which
I'm not gonna start the discussion about making this list read-only again, maybe
it's just enough that Stas is not allowed to post? :D
Anyway, who dropped the word OPTIONAL from the subject? I think that was quite
essential part of this whole debate? As I'm +1 for OPTIONAL scalar-type
Hi,
I'm trying to figure out how to test a feature in the phar extension
that requires the executable test file to be an actual phar archive.
This would be possible if there was some way to load the --FILE--
section from an external file. Would anyone object to adding a new
section to the .phpt
Gregory Beaver wrote:
Hi,
I'm trying to figure out how to test a feature in the phar extension
that requires the executable test file to be an actual phar archive.
This would be possible if there was some way to load the --FILE--
section from an external file. Would anyone object to
1 - 100 of 101 matches
Mail list logo
