I support this patch 100%. I have a large application I'm rewriting to
include namespaces, however now I can no longer use my script caching
functionality (which improved performance literally about 500%) that
compiled all of my includes into one file, because many of the files
have namespaces.
I think support for multiple namespaces in one file should definitely be
used. As far as using curly braces vs using the namespace declaration,
it doesn't really matter to me, however it is important that i be able
to use the same namespace twice:
namespace a {
function function1() {
I think namespaces are very useful when it comes to PHP in large scale
applications with hundreds of functions/classes.
On Tue, 2007-12-04 at 16:39 -0600, Brian Moon wrote:
With all the above considerations, especially my first point, I still have
not
heard any good reason why namespaces
Autoload would work exactly the same with namespaces, just do a
str_replace and replace :: with _.
On Wed, 2007-12-05 at 09:52 +0100, Robert Lemke wrote:
Hi Derick,
I also agree with your arguments - beautifying class names is not
reason enough for
introducing namespaces.
On 04.12.2007
This would be a good idea, if implemented with a compatibility layer to
be removed later.
::php
::str
::arr
::ob
etc
::ext
::mysql
::mysqli
Userland code can then use a namespace such as ::app, or just use the
global namespace with no
I didn't put any work in here and I agree with him 100%. Namespaces have
been incredibly useful for me. Now that I'm using them I would not want
to do without them.
As far as bundling, my application (over 11,000 lines now) did use a
bundling feature that I can no longer use. It would be very
I agree, I also see this as critical in large applications. The current
implementation may have some problems, yes, but it's not hurting anyone
who's not using namespaces.
The minor issues around namespaces can be worked out in due time, but I
think it would be a huge mistake to drop the whole
The implementation as it is now works. It's functional, and useful.
Minor issues like import/use can be worked out when necessary, but for
now I see this as something that can be released (provided that most of
the bugs are worked out). Multiple namespaces per file is the only thing
I see as a
You have a point, however it is not always this simple. Some
applications have classes/functions that are not necessarily gathered in
order by their namespaces. It would be a nightmare to try to organize
and then bundle these functions and classes together dynamically into
different files by
I agree with everything here, especially the solution to multiple
namespaces per file (allow but discourage), but i don't agree with the
__php__ namespace. If any separation of core php and extensions into
namespaces happens, it should be kept as simple as possible, with root
namespaces like php::
However you don't have a semicolon after your namespace declaration.
With the current implementation you would need a semicolon, which
doesn't look nearly as good with braces.
On Fri, 2007-12-07 at 15:21 -0500, Ken Stanley wrote:
I understand what you mean, but I was just trying to put a
Very good point
namespace stuff ;
{
function myfunction() {
return true ;
}
}
That would actually work, but it's not quite the same as you have the
semicolon after the namespace declaration, which looks kind of stupid.
Overall i dont think braces are a bad idea.
Once you say namespace xyz ; everything in the file is now relative to
namespace xyz. To refer to the global namespace, you use the following
?php
namespace xyz ;
function substr() {
return true ;
}
substr(); // calls substr in current namespace
::substr(); // calls substr in global
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 agree with this 100%, is this something that could be changed? I don't
see a reason behind it.
On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote:
internal class/function with the same name.
Dmitry, what's the reason this lookup logic wasn't used in your patch?
--
PHP Internals
Ok, it's supposed to be this way right? If i define a custom class in
the global namespace called myClass and I'm in another namespace, I
can only access it using ::myClass, not just myClass (without the
colons)? Seems to me that it should check the local namespace and then
the global, but it only
with no problems.
On Tue, 2007-12-11 at 13:07 +0100, Christian Müller wrote:
Sam Barrow schrieb:
What is the general opinion on this?
I'm all for it.
Would be using it already, if it where available as an extension.
Do i recall right, that you (or someone else) had this combined
Is this patch going to be implemented in the PHP release?
On Tue, 2007-12-11 at 18:42 -0500, David Coallier wrote:
On Dec 11, 2007 6:13 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to
If anyone here is experienced enough to help me, I will pay for a patch
to allow for multiple class inheritance (class D extends A, B, C)
against PHP 5.3 CVS. Or if you can just help me get started on writing
it, I'm sure I could finish myself. I'm just stuck at the basic zend
class declaration
but I have yet to see many
situations where that's really needed.
Andi
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 25, 2007 12:23 PM
To: PHP Developers Mailing List
Subject: [PHP-DEV] Will pay for feature add
If anyone here
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a
I think E_WARNING would be appropriate. That's what happens when you
omit an argument to a function right?
And about function return type hinting, I don't think it would be as
useful as parameter type hinting, but it would be useful. Mostly for
stuff like declaring an abstract function in a
I think we should stick with E_WARNING for now. If you want to use
exceptions you can throw one in a custom error handler. I can change
about 4 lines of code in my patch to have it emit an E_WARNING easily.
On Thu, 2008-01-03 at 19:49 +0100, Jochem Maas wrote:
am I the only one to consider
Thank you. As long as a feature is useful, why not add it? Just because
some people don't find it useful, this is not at all a reason to
completely discard the idea, especially when the only argument is well
PHP doesn't need that so just use another language.
On Thu, 2008-01-03 at 20:23 +0100,
Just so anyone who wants it has it, I have attached the last version of
my patch.
Note that it still issues a fatal error but this can be changed very
easily, would take me about 2 minutes.
Full specs:
Type hinting patch allows for 8 new type hints, in addition to array and
class type hinting.
On Thu, 2008-01-03 at 20:50 +0100, Derick Rethans wrote:
With that statement I don't agree though. It needs to be usefull for a
more general public, and not introduce a huge performance loss for
example.
You're right, I didn't mean that like it sounded.
But a feature that maintains
On Thu, 2008-01-03 at 22:01 +0200, Tomi Kaistila wrote:
Broken record perhaps? I am getting a bit tired of this just use
Java
argument, it's perhaps even a bit arrogant. From what I read there
is
plenty of people that want type hints for static types - there's a
few
patches out there,
On Thu, 2008-01-03 at 13:00 -0700, John Coggeshall wrote:
Wouldn't this patch also allow for additional performace optimizations
which would help counter losses even in the non-general case?
Performance optimizations in what way?
--
PHP Internals - PHP Runtime Development Mailing List
To
On Thu, 2008-01-03 at 12:27 -0800, Stanislav Malyshev wrote:
patches out there, it doesn't slow down the general case. So why
should
we *not* add it? (And yes, I changed my mind)
My opinion is that the language is not a salad of features that somebody
somewhere found useful. The
On Thu, 2008-01-03 at 12:51 -0800, Stanislav Malyshev wrote:
In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
I do not believe
On Thu, 2008-01-03 at 22:14 +0100, Jochem Maas wrote:
Stanislav Malyshev schreef:
In a way this is true, but I look at it this way. Some languages are
strictly typed, some are dynamically typed. PHP can have the best of
both worlds by having optional strict typing where desired, as well as
The value is this:
With type hinting:
function a(string $mystring, num $mynum, object $myobject) {
}
Without type hinting:
function a($mystring, $mynum, $myobject) {
if (!is_string($mystring)) {
trigger_error('Parameter 1 of function a() must be a string.',
E_USER_WARNING) ;
}
if
You have a point, but for input in general non type-hinted functions
should be used. Your first example shows a scenario in which not to use
type hinting, because all $_REQUEST input is in string form. However
when dealing with internal functions and methods, type hinting can
prevent flawed
If foo() is changed, the type hints should be removed. Most of the time
however, a function will not change its functionality enough to change
the purpose of the arguments.
On Thu, 2008-01-03 at 14:50 -0800, Stanislav Malyshev wrote:
type-hinting is asserting.
checking of types is needed only
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.
On Thu, 2008-01-03 at 14:30 -0800, Stanislav Malyshev wrote:
I don't get it. We already have type hinting, just not for
On Fri, 2008-01-04 at 02:01 +, Steph wrote:
I'm just a php developer who didn't agree with the rules on type
hinting.
... or superglobals, or multiple class inheritance rules. Why PHP? What did
we do? :\
More seriously (because I don't think this has a hope in hell of getting in,
On Fri, 2008-01-04 at 02:56 +, Steph wrote:
I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19
Right, that'd explain it. It's just that usually people do a bit of
On Fri, 2008-01-04 at 02:56 +, Steph wrote:
I just like PHP enough that rather than switch languages, I would like
to attempt to make PHP better. I've only been working with the PHP
source since November and I'm 19
Right, that'd explain it. It's just that usually people do a bit of
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, 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 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
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.
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 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, 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
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 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 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 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: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
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
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 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 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
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
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
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 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
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 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 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
On Sun, 2008-01-06 at 01:11 +0200, Vlad Bosinceanu wrote:
Also,
function foo(SomeClass $obj) would error out if passed something other
than a SomeClass instance, while
function foo(int $number) would just cast $number to int.
Not really intuitive and not really consistent.
My patch does
On Sat, 2008-01-05 at 15:59 -0800, Mike Lively wrote:
Because type hinting is supposed to limit what kind of variable type
is
allowed for a parameter. When you magically convert you kill the whole
idea of type hints and replace it with some magical function parameter
auto type
On Sun, 2008-01-06 at 11:28 +, Alain Williams wrote:
On Sat, Jan 05, 2008 at 07:34:04PM -0800, Mike Lively wrote:
input is going to makes it's way into your api at some point. Now of
course you can (and should) be filtering this
input before it is used, but if imo when dealing with
On Sun, 2008-01-06 at 15:59 +0100, Magnus Määttä wrote:
On Sunday 06 January 2008, Alain Williams wrote:
On Sun, Jan 06, 2008 at 01:02:54PM +0100, Stefan Esser wrote:
Hello Alain,
I think you are also confused about PHP type hinting...
The manual clearly states:
On Sun, 2008-01-06 at 09:03 -0800, Mike Lively wrote:
On Sun, 2008-01-06 at 10:55 -0500, Sam Barrow wrote:
function requireFile(string $file, bool $getOutput = false, array $args
// ...
This function will not be called using input data.
So is there some way you are ensuring
On Sun, 2008-01-06 at 19:18 +0200, Giedrius D wrote:
On Jan 6, 2008 5:55 PM, Sam Barrow [EMAIL PROTECTED] wrote:
As I said, this patch is not intended for stuff like $_GET, $_POST,
database data, etc. It is intended for internal functions to your
application.
function requireFile(string
On Sun, 2008-01-06 at 15:41 -0300, Cristian Rodriguez wrote:
2008/1/4, Jani Taskinen [EMAIL PROTECTED]:
As I'm +1 for OPTIONAL scalar-type hinting.
me too +1 as long as :
?php
function foo(int $a) {}
foo('5');
?
Raises an error, and is rejected because is not a valid
On Sun, 2008-01-06 at 20:02 +, Mikko Koppanen wrote:
Why I mean by:
Type HINTING is not type ENFORCEMENT.
is that:
function foo(int $a) {}
foo(1); // OK
foo(1); // OK - the string is juggled to an int when the
function is called
On Sun, 2008-01-06 at 21:53 +0100, Pierre wrote:
Hi Marcus,
On Jan 6, 2008 9:24 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
That said I would only agree to type hints if we make them respect existing
PHP conversion rules.
That can be a good compromise and may make happy the cons camp.
On Sun, 2008-01-06 at 21:23 +, Alain Williams wrote:
On Sun, Jan 06, 2008 at 10:08:16PM +0100, Markus Fischer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pierre wrote:
| That can be a good compromise and may make happy the cons camp.
| However, I would not like to have
On Sun, 2008-01-06 at 23:15 +0100, Stefan Priebsch wrote:
Pierre schrieb:
I don't see the point to make a application working when you pass to
it the wrong data, it is a bad usage. That was the moto for the
So how are you going to deal with the bad usage then? Isn't the
problem that
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 Mon, 2008-01-07 at 15:19 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Well these errors can be handled like any other, as long as they don't
issue a fatal.
That's exactly my point. You need to handle them. So in pidgin PHP that
could look something like
function foo(int $foo
On Mon, 2008-01-07 at 13:16 -0500, Elizabeth M Smith wrote:
Afternoon,
Wow, go away for a weekend and look what happens...
Personally I think the issue is that true scalar type hinting doesn't
make much sense with a dynamically typed language. Deciding if/when/how
to juggle a scalar
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever
On Mon, 2008-01-07 at 13:33 -0500, Robert Cummings wrote:
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number
On Tue, 2008-01-08 at 09:41 +, Richard Quadling wrote:
On 07/01/2008, Stefan Priebsch [EMAIL PROTECTED] wrote:
Robert Cummings schrieb:
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every
On Tue, 2008-01-08 at 16:03 +0200, Tomi Kaistila wrote:
I believe the cleanest solution that we could implement would be using
the type casting with Type objects.
I experimented with this for a couple of months, a couple of weeks ago. In
opinion, it does not work well. I am guessing
On Tue, 2008-01-08 at 22:47 +0200, Tomi Kaistila wrote:
But the syntax is longer ($a = 5 vs $a = new Integer(5)), and if you
have a large application with hundreds of integers it starts to add up.
Performance is also much worse when using objects for every variable.
I agree. That is what I
On Wed, 2008-01-09 at 00:58 +0200, Tomi Kaistila wrote:
Ok, but a scalar becomes useful for a couple of important things.
Scalars are all displayable values, that can be stored in a db,
outputted, etc. The scalar type hint prevents errors related to objects,
resources, and arrays
I like b.
On Thu, 2008-01-10 at 19:07 +0900, Ryusuke SEKIYAMA wrote:
Hello, lists,
I'm tired to type array() many times. And I want to
declare arrays more easily. So I wrote the patch for
zend_language_parser.y which enables to declare arrays
with square brackets like some other languages.
On Thu, 2008-01-10 at 14:56 +0100, Hannes Magnusson wrote:
So you reject scalar type hinting because it isn't type casting and
can therefor confuses newbies - but scattering seemingly random
brackets around your code (to safe 5 key strokes) is obvious to users?
Noone would confuse this with
On Thu, 2008-01-10 at 16:18 +0200, Giedrius D wrote:
Hi,
On Jan 10, 2008 3:56 PM, Hannes Magnusson [EMAIL PROTECTED] wrote:
So you reject scalar type hinting because it isn't type casting and
can therefor confuses newbies - but scattering seemingly random
brackets around your code (to
I just tried this out using option b, and I really like it.
$var = [1, 6, 434] ;
I think it looks good and helps code readability alot.
On Thu, 2008-01-10 at 19:07 +0900, Ryusuke SEKIYAMA wrote:
Hello, lists,
I'm tired to type array() many times. And I want to
declare arrays more easily.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 2008-01-11 at 10:05 +0200, Lokrain wrote:
Hello mr. Antonio Touriño,
So as if I understand, you want to change the syntax of array() keyword.
Will you mind to update the changes in all php scripts in the world too?
PS. You can always have your [] in custom patch, but I do not think
On Fri, 2008-01-11 at 11:07 -0800, Stanislav Malyshev wrote:
It is better to have input from people with a wide range of experience
levels, it results in a fairer vote that actually represents the
population, rather than putting PHP under the control of a select few.
No, it is not. This
1 - 100 of 190 matches
Mail list logo
