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 pa
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
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 consid
t; whole and would 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
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
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 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
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
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
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 ha
id number 1 is the most likely.
>
> David
>
>
>
>
>
> Am 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 atlea
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
> >
00, Pierre 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
> >
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 t
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 no
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 paramet
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 wi
5, 2008 at 12: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 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, t
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.
> >
> >
> >
>
> T
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
> 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 Inter
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
ble?
What I'm trying to acheive is this:
function a($arg1, $arg2) return 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
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 met
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 and
On Fri, 2008-04-18 at 11:42 -0700, Stanislav Malyshev wrote:
> Hi!
>
> > $result = new myObject -> myMethod();
> >
> > Is there a technical reason as to why this can't be done? If not can
> > this be changed?
>
> I think this can not be parsed unambiguously. This could be new
> (expression with
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);
> }
>
> $rang
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 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 clearf
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 So
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
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 inten
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
> >
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 thi
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
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
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 11:4
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_* f
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: http://www
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.p
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
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 In
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() ) {
>
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
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.
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
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
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 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:
> > >
> >
a hack is my opinion.
Why is a scalar type hint not acceptable if an array type hint is?
That's what I really want to know.
> -Chris
>
> On Feb 6, 2008 6:20 AM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Wed, 6 Feb 2008, Sam Barrow wrote:
> >
> > > On
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
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 paranoi
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 p
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 bec
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 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.
>
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_NOTI
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
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.
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 P
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
+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
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 w
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 easi
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 c
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 lan
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 at
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
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 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
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 t
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 m
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 s
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 loo
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 alre
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 typ
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
> proble
On Sun, 2008-01-06 at 22:41 +0100, Pierre wrote:
> On Jan 6, 2008 9:55 PM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> > Pierre schrieb:
> > > When a method or function uses the strict typing, it is on purpose. It
> > > is documented (self documented and hopefully using normal docs). There
> > > i
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 li
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
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
> > f
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 :
>
>
> function foo(int $a) {}
>
> foo('5');
>
> ?>
>
> Raises an error, and is rejected because is not a v
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
> > ap
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.
> >
>
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 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 dealin
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 c
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 patc
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 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
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!
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
1 - 100 of 201 matches
Mail list logo
