On Sun, 2008-01-06 at 23:15 +0100, Stefan Esser wrote:
Hi Marcus,
That said I would only agree to type hints if we make them respect existing
PHP conversion rules
if type hints are supposed to convert data, then they are wrongly
named. Then they should be better called implicit typecasting.
On Sun, 2008-01-06 at 23:58 -0300, Martin Alterisio wrote:
A friend told me you were having a most interesting debate on type hinting
in the internals, when I got some free time I checked the newsgroup to see
how was it coming. It's quite interesting and many good points have been
made
On Jan 5, 2008 1:52 AM, Jani Taskinen [EMAIL PROTECTED] kirjoitti:
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
hinting.
+1 on scalar-type-hinting (not to be confused with type-casting)
On Saturday 05 January 2008, Hannes Magnusson wrote:
On Jan 5, 2008 1:52 AM, Jani Taskinen [EMAIL PROTECTED] kirjoitti:
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
hinting.
+1
Magnus Määttä wrote:
+1 on scalar-type-hinting (not to be confused with type-casting)
I'm also +1 for optional scalar-type hinting FWIW.
Same here.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514
PHP is first and foremost a Web scripting language. Everything we do
and every decision is based on that. For every feature the first
question you need to ask yourselves is:
Will this make it easier or harder for the average PHP user to
build a web app? And if it makes it harder, is the
On Sat, Jan 05, 2008 at 09:46:34AM -0800, Rasmus Lerdorf wrote:
PHP is first and foremost a Web scripting language. Everything we do
and every decision is based on that. For every feature the first
question you need to ask yourselves is:
Will this make it easier or harder for the
Be conservative in what you do; be liberal in what you accept from
others.
You hopefully realise that this is exactly the opposite of your earlier
opinion that ext/filter should be used to block everything and let only
harmless data through. And only have raw data on demand...
I really
Stefan Esser wrote:
Be conservative in what you do; be liberal in what you accept from
others.
You hopefully realise that this is exactly the opposite of your earlier
opinion that ext/filter should be used to block everything and let only
harmless data through. And only have raw data on
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
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 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
[**] 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
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,
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
To: Stas Malyshev
Cc: internals Mailing List
Subject: Re: [PHP-DEV] type hinting
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
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
Mailing List
Subject: RE: [PHP-DEV] type hinting
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
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
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
most often and quickest is not going to
win this debate :)
Andi
-Original Message-
From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 12:19 PM
To: Robert Cummings
Cc: Stas Malyshev; Sam Barrow; Pierre; internals Mailing List
Subject: Re: [PHP-DEV] type
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
, January 04, 2008 12:19 PM
To: Robert Cummings
Cc: Stas Malyshev; Sam Barrow; Pierre; internals Mailing List
Subject: Re: [PHP-DEV] type hinting
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
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, it would make it harder. Many of the functions I work with
require
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For the record, I'm all for it. Optionality means flexibility. If one
doesn't want to use it, he doesn't have to.
Can you send a patch against 5.3 in CVS?
Have you thought about type hinting for return values?
thanks,
- - Markus
Sam Barrow wrote:
A few weeks ago I wrote a message on this list about my patch for scalar
type hinting. I've been using it for about a month now in a large scale
application im developing with no problems. It allows type hinting for
the following types: int, float, string, bool (boolean), num (int or
float),
I know well the sacred loose typing anthem, but is there any hope to see
the class properties type hinted one day? (and the return value as well)
I mean, as an OPTION, as it is already done with function parameters...
Class A {
}
Class B {
public A $a;
}
Because:
1. It is so strange to see
Fair enough Wez :)
On Thu, 2005-08-25 at 20:34 -0400, Wez Furlong wrote:
In some environments you *need* to run a zts enabled PHP.
People that run in those environments can heed the warnings about
potential stability issues, evaluate them, and decide whether it makes
sense for their
401 - 500 of 596 matches
Mail list logo
