Gregory Beaver wrote:
> 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 f
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
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
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 hinti
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 whic
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 mo
-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
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
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 proble
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
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
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/
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]
--
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.
>
> > wi
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.
>
>
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/
(40
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 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 dea
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.
>
W
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 b
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 into
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 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 coul
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!
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]
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
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
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
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 c
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,
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
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 tha
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 "A
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,
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 List
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
On Fri, 2008-01-04 at 18:46 +, Alain Williams wrote:
> On Fri, Jan 04, 2008 at 01:06:26PM -0500, Robert Cummings wrote:
> > >
> > echo 'Foo: '.(0 + '5five')."\n";
> > echo 'Foo: '.((int)'5five')."\n";
> > echo 'Foo: '.(intval( ' 5five' ))."\n";
> > echo 'Foo: '.(sprintf( '%d',
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.
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 t
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 t
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
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,
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 betwee
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: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 wi
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
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 p
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
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 harder to write that this:
processAccount(string $client)
Note that unles
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 be
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 featur
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 lik
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 inconsisten
On Fri, Jan 04, 2008 at 01:06:26PM -0500, Robert Cummings wrote:
>
> echo 'Foo: '.(0 + '5five')."\n";
> echo 'Foo: '.((int)'5five')."\n";
> echo 'Foo: '.(intval( ' 5five' ))."\n";
> echo 'Foo: '.(sprintf( '%d', '5five' ))."\n";
>
> ?>
>
> All produce 5.
But the string 'foobar'
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 hi
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:
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
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 her
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 co
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 sho
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
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, do
* 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 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 tools
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 h
[**] 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]
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:
> > W
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 a
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 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 par
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]> wr
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
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 b
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 thi
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,
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
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
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:
* Cu
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 feature
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 (PE
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, 20
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]
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 t
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 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 missin
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 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
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 validati
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 mak
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 s
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 (PE
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
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
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 En
On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote:
> We've discussed scalar type hinting many times in the past and decided
> against it.
> 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. The only reason
> why it
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 PH
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
> > ce
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
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 comin
1 - 100 of 104 matches
Mail list logo
