On Thu, 2008-06-19 at 20:07 +0200, Timm Friebe wrote:
Hi,
I like this generally, but cannot live with the BC issues raised.
Introducing all type names as keywords will make class Object, class
Integer and so on give a syntax error.
That's actually not true, the patch does not
On Sun, 2008-06-15 at 11:44 +0200, Timm Friebe wrote:
Hi,
If anyone wants use type hinting, i believe that it should be strict.
Otherwise, it makes more sense to not use it.
I like this generally, but cannot live with the BC issues raised.
Introducing all type names as keywords will
On Tue, 2008-04-29 at 22:13 -0400, Jessie Hernandez wrote:
Sam Barrow wrote:
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters
On Wed, 2008-04-30 at 09:23 +0300, Arvids Godjuks wrote:
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
And bad idea about making a return type function - looks very
useless and will not be used a lot. Work with
On Wed, 2008-04-30 at 08:27 +0100, Alain Williams wrote:
On Wed, Apr 30, 2008 at 09:23:17AM +0300, Arvids Godjuks wrote:
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
+1 -- least confusion to most people.
On Wed, 2008-04-30 at 12:58 +0200, LAUPRETRE François (P) wrote:
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
First is that function
definition and code is usually written by the same person in the same
(very small) context, and this person has to be somewhat
absent-minded
Currently there is no way to call a class constructor using
call_user_func or something similar, the only way is to use a reflection
object which is useless overhead and takes a few lines of code.
This would be very useful to be able to do
create_new(string $class, array $constructor_args)
Does
On Wed, 2008-04-30 at 10:03 -0700, Stanislav Malyshev wrote:
Hi!
create_new(string $class, array $constructor_args)
You can create new object via ReflectionClass::newInstance.
Still, that just seems unnecessary, I usually compile without the
reflection stuff because i never use it. I'd
not mind lending some time for.
Yes, this seems to be the most agreed upon.
[modifiers] [type] function name() {
I'm trying to get this to work in the parser right now, but I can't. Do
you know enough to be able to help out with that?
-Chris
On Wed, Apr 30, 2008 at 4:51 AM, Sam Barrow [EMAIL
On Wed, 2008-04-30 at 19:09 +0200, Hannes Magnusson wrote:
On Wed, Apr 30, 2008 at 6:57 PM, Sam Barrow [EMAIL PROTECTED] wrote:
create_new(string $class, array $constructor_args)
Does anyone else see a need for this?
No.
Have you considered subscribing to [EMAIL PROTECTED]
Could
I want to make two classes:
abstract class a {
abstract public function go($a);
}
final class b extends a {
abstract public function go(array $a);
}
This will not work, I get an error that the two must be compatible.
Wouldn't it be a good idea to allow any type hint for a
On Tue, 2008-04-29 at 09:34 -0400, Sam Barrow wrote:
I want to make two classes:
abstract class a {
abstract public function go($a);
}
final class b extends a {
abstract public function go(array $a);
}
Sorry, function in class b should not be abstract.
This will not work
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
The only thing left would be to decide on the syntax
public array function x() { // Probably
Joye wrote:
On Tue, Apr 29, 2008 at 5:22 PM, Sam Barrow [EMAIL PROTECTED] wrote:
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters
On Tue, 2008-04-29 at 17:43 +0200, Stefan Walk wrote:
On Tuesday 29 April 2008 15:34:07 Sam Barrow wrote:
This will not work, I get an error that the two must be compatible.
Wouldn't it be a good idea to allow any type hint for a parameter that
does not specify a type hint?
That would
29.04.2008 um 17:22 schrieb Sam Barrow:
Well in summation I think this is something that should be
implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
The only thing left would be to decide
I like the first too, if this can be implemented I think it is a
suitable syntax.
On Sat, 2008-04-26 at 00:13 +0100, Alain Williams wrote:
public function int doThing(string $foo) { return 1; }
The above is the best (ie omit 'return' or 'returns').
This also is consistent with C and with
Attached is my return type hinting patch. It allows type hinting for
parameters and return values. Int, float, bool, string, num, scalar,
resource, object, array, and class names are supported for both
parameters and return values. Objects with __toString methods are
allowed to pass for scalar
On Fri, 2008-04-25 at 10:06 -0700, Stanislav Malyshev wrote:
Hi!
In general, it'd be very nice to have some definition of the proposed
feature beyond the patch. It would probably answer some of my questions
that follow :)
parameters and return values. Objects with __toString methods
int {
}
Currently:
function a return int($arg1, $arg2) {
}
On Fri, 2008-04-25 at 11:30 -0400, Sam Barrow wrote:
Attached is my return type hinting patch. It allows type hinting for
parameters and return values. Int, float, bool, string, num, scalar,
resource, object, array, and class names
On Fri, 2008-04-25 at 10:06 -0700, Stanislav Malyshev wrote:
I notice it introduces new keyword -
returns. Is it necessary? Each new keyword means broken code.
I have adapted the patch to reuse the return keyword.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Why note the following (which would be more C like):
function return int a($arg1, $arg2) {
}
It gets a little long when you're using classes
abstract protected function return int dostuff() {
}
vs
abstract protected function dostuff() return int {
}
--
PHP Internals
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a page out of
the book
On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
Sam Barrow wrote:
I figured it out, the syntax is now as follows
:25 PM, Sam Barrow [EMAIL PROTECTED]
wrote:
On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow
[EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett
wrote
On Fri, 2008-04-18 at 12:33 +0100, Richard Quadling wrote:
On 18/04/2008, Arvids Godjuks [EMAIL PROTECTED] wrote:
+1 for strict types.
That way it will be simple:
* Don't need - then don't use at all
* You need it - you use it fully.
One thing than left to clearfy - do we allow
I had a question about object instantiation.
You can do this:
function createObject() {
return new myObject;
}
$result = createObject() - myMethod();
But you can't do this:
$result = new myObject - myMethod();
Is there a technical reaosn as to why this can't be done? If not can
this
On Fri, 2008-04-18 at 10:40 -0700, Kalle Sommer Nielsen wrote:
Hey Internals
I've been wondering for quite some time why PHP doesn't allow you to access
arrays when you assign it to a value like in Javascript:
function ArrayTest(Array $range)
{
return($range);
}
$range =
On Thu, 2008-04-17 at 14:52 +0200, Paul Biggar wrote:
Hi,
Your current implementation seems to be inconsistent with both itself
and the rest of PHP. I hope this can be rectified before it is
included. PHP is inconsisent enough without adding more.
1.) There are a number of is_*
In this case, I'd suggest using my patch for parameter type hinting. It
utilizes the current type hinting system for minimal code changes,
whereas this is a whole new set of functionality. It also has scalar and
number types, and supports objects with __tostring methods.
On Thu, 2008-04-17 at
On Thu, 2008-04-17 at 17:29 +0200, Paul Biggar wrote:
On Thu, Apr 17, 2008 at 5:24 PM, Felipe Pena [EMAIL PROTECTED] wrote:
Thanks for making the change. This is much more consistent. It remains
that there is no 'scalar' or 'numeric' hint. Are you planning on
including them?
No,
On Thu, 2008-04-17 at 09:18 -0700, Chris Stockton wrote:
On Thu, Apr 17, 2008 at 9:01 AM, Sam Barrow [EMAIL PROTECTED] wrote:
I like this alot better too, the only downside is compatibility
problems.
Can you explain, I understand; in partial the problem but I am curious what
can
On Thu, 2008-04-17 at 08:54 -0700, Chris Stockton wrote:
I like this patch, it adds a feature which a lot of companies and code base
would surely implement without breaking anything. The only thing I do not
like has already been mentioned, numeric and scalar are not included.
The one thing I
On Thu, 2008-04-17 at 10:06 -0700, Chris Stockton wrote:
On Thu, Apr 17, 2008 at 9:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by failing
the
On Thu, 2008-04-17 at 10:06 -0700, Stanislav Malyshev wrote:
Hi!
The problem with this is that there's not much point in converting the
value. PHP will do that anyway, making this kind of pointless.
There would be a point since PHP might convert to different type that
you intended.
On Thu, 2008-04-17 at 10:23 -0700, Chris Stockton wrote:
On Thu, Apr 17, 2008 at 10:11 AM, Sam Barrow [EMAIL PROTECTED]
wrote:
Actually, is_numeric checks for strings that contain numeric
values,
it's not the same as is_bool, is_int, is_float, etc, which
check
On Thu, 2008-04-17 at 11:43 -0700, Stanislav Malyshev wrote:
Hi!
Scalar is useful if you DON'T want an array or object - but don't care
if you get an int/string/whatnot
When you can use string but not object with __toString?
my patch does that
--
Stanislav Malyshev, Zend Software
If somebody does have a patch for this or is working on one let me know.
Whether this will be implemented or not I would like to assist with this patch
so I can use it for personal use at the very least.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I have a scalar type hinting patch on my blog at www.sambarrow.com
On Mon, 2008-04-07 at 10:57 -0300, Felipe Pena wrote:
I don't thought this before!
Sure, i'll try provide a patch.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, 2008-03-30 at 16:05 -0400, Edward Z. Yang wrote:
Christian Schmidt wrote:
What do you think of the general idea of being able to unset
headers?
And what do you think of my patch?
If you need this kind of flexibility, I recommend you make an
HttpHeaders class which manages these
Not bringing the issue back up on the list, I was just wondering if
there is a supporter of type hinting that would be willing to help me
implement an automatic conversion of objects with a __tostring() method
to strings if the object was passed as an argument with a string type
hint.
--
PHP
On Fri, 2008-02-08 at 10:42 -0600, Brian Moon wrote:
Richard Quadling wrote:
Aren't some things just worth the BC break?
Having never used them, I can quite happily say bomb the bastards!
Agreed. For Phorum will just change our code from:
if ( get_magic_quotes_gpc() ) {
to:
if
On Fri, 2008-02-08 at 13:48 +0100, Pierre Joye wrote:
On Feb 8, 2008 1:26 PM, Tomas Kuliavas [EMAIL PROTECTED] wrote:
So I guess I'm -1: Restore them, always return false, and throw
E_DEPRECATED.
But this was about them being in PHP 6, not PHP 5..
If magic_quotes_* is gone, so
On Thu, 2008-02-07 at 02:17 -0800, Rasmus Lerdorf wrote:
Jani Taskinen wrote:
On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote:
Jani Taskinen wrote:
On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote:
Stanislav Malyshev wrote:
The proposal(s):
1. One way to fix it is to
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Steph Fox wrote:
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same
.
-Chris
On Feb 6, 2008 6:20 AM, Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should
On Wed, 2008-02-06 at 15:31 +0100, Pierre Joye wrote:
HI Sam,
On Feb 6, 2008 2:33 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 14:20 +0100, Derick Rethans wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote
On Wed, 2008-02-06 at 10:09 -0500, Elizabeth M Smith wrote:
Wow, you guys sure are a bit harsh
Here's the problem - there's a group of people who really want true (I
might say javaish) type-hints for scalar values - int, bool, string,
float, and won't settle for anything less.
On Wed, 2008-02-06 at 16:39 -0800, Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do
On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote:
Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
Good point. Either way the argument against it is even weaker now that
all it has are the scalar and resource types. It is now fully compliant
with PHP's type juggling system. Anyone who disagrees with a scalar
hint should probably also disagree with the array hint.
On Wed, 2008-02-06 at 01:02
On Tue, 2008-02-05 at 23:19 +, Richard Quadling wrote:
On 05/02/2008, Tomi Kaistila [EMAIL PROTECTED] wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there
On Wed, 2008-02-06 at 00:27 +0100, Markus Fischer wrote:
Tomi Kaistila wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point.
I'm sorry I misunderstood. If specifying like $var ?: 5 then it should
throw an E_NOTICE, as this is a conditional that checks the value of a
variable ($var).
Sebastian, for assigning of a default value is a variable is not set, I
would recommend using something like this (this is what I use):
I don't think throwing a E_NOTICE is appropriate. The isset() construct
doesn't throw an E_NOTICE, this shouldn't either.
On Sat, 2008-01-26 at 17:30 +0100, Sebastian wrote:
hi,
i just found the new ifsetor like construction in php6. It left me the
question why php has to throw an E_NOTICE
On Sat, 2008-01-26 at 22:13 +0100, Lars Strojny wrote:
Hi,
Am Samstag, den 26.01.2008, 12:17 -0500 schrieb Sam Barrow:
I don't think throwing a E_NOTICE is appropriate. The isset() construct
doesn't throw an E_NOTICE, this shouldn't either.
As far as I understand it is just
PHP has ZIP, GZip, and BZ2 support, but nothing for tar archives. Is
anyone interested in working on a tar extension?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 2008-01-12 at 00:52 +0300, Antony Dovgal wrote:
On 11.01.2008 22:13, Sam Barrow wrote:
input from many people is great, moreover - it is necessary. However, it
is not the same as deciding by arithmetical majority of votes of whoever
cares to vote on technical questions.
Which
+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
On Fri, 2008-01-11 at 19:27 +0100, Pierre wrote:
On Jan 11, 2008 7:24 PM, Johannes Schlüter [EMAIL PROTECTED] wrote:
But well in my results I have a problem: For Rasmus's vote I've counted
a -1 while as such this syntax is appropriate I think has to be
counted as +1.
There is more than
On Fri, 2008-01-11 at 14:06 -0500, Olivier Hill wrote:
On Jan 11, 2008 1:47 PM, Sam Barrow [EMAIL PROTECTED] wrote:
True. No one's vote is worth more than anyone else's, everybody should
have equal say. Some people may know more about the PHP core, but we are
all users and developers
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.
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
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 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 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 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 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
1 - 100 of 190 matches
Mail list logo
