2008/4/15, Felipe Pena [EMAIL PROTECTED]:
Em Ter, 2008-04-15 às 01:05 -0400, Sam Barrow escreveu:
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
Thouse who are asking about type hinting for function args are right. It is
logical to implement return type hinting with arg type hinting.
They should work either independantly (you can specify any on them or all
together) or if you declare return type - declare arg types too (then we
should have
Christian Schneider
We have 2 possibilities.
* Throw an error
* Make type conversion
What to select is PHP developers team prerogative.
About example - that's MySQL who is very tollerant, other databases may not
threat well things like passing an ID to numeric field as string. That's bad
style
Em Ter, 2008-04-15 às 01:05 -0400, Sam Barrow escreveu:
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.
I already made two separated
I already made two separated patches for param. and return value type
hints. I'll create a new thread and start discussion ASAP.
Why not put it to the wiki?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP
Chris Stockton schrieb:
Why on earth would you have int, string, resource, etc return type hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; //
You are missing the point, why be strict on return types, and liberal on
parameters? Be strict consistently or be liberal consistently. Or, keep php,
php. I could care less as long as things are consistent, although I think
only supporting scalar is silly regardless of type juggling.
-Chris
On
On 14.04.2008, at 19:49, Christian Schneider wrote:
Am 14.04.2008 um 19:04 schrieb Chris Stockton:
You are missing the point, why be strict on return types, and
liberal on parameters? Be strict
Because IMHO a function can easily specify what it is returning but
should be flexible in what
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:
On 08.04.2008, at 12:13, Krister Karlström wrote:
Yes indeed you can implement it using the __call method, but it
would be more readable if the language structure itself would
support it. I suggested this just because I think that this is the
most common way of using overloading, thus this
On 07.04.2008, at 19:59, Stanislav Malyshev wrote:
Hi!
Right if at all I would agree on having a type hint scalar, but
not a separate one per type.
IMO (as already was discussed like 10 times?) scalar makes no
sense. It doesn't save you any checks, and doesn't provide any
useful
Why on earth would you have int, string, resource, etc return type hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; // lol
}
Em, you have __call method in classes - via it you could implement ANY logic
for overloading. It's written in manual here:
http://www.php.net/manual/en/language.oop5.overloading.php
KISS should be followed - no C++ style overloading is needed, PHP is a
script language without strict type hinting.
Yes it does, and not only for VB developers.
I'm plain PHP developer (with some small Pascal and Delphi background) and I
faced quite a lot situations when named parameters would give me a lot. In
stead had to write some nasty code like
myFunc($param1, $param2, array(), null, $paramX);
Actually nothing could support my point about giving the wrong signals
better than these two postings: They are IMHO on the wrong track on how
to make an interface better.
Krister Karlström wrote:
This is maybe getting a bit out of topic now, but what about
function/method overloading using
Yes indeed you can implement it using the __call method, but it would be
more readable if the language structure itself would support it. I
suggested this just because I think that this is the most common way of
using overloading, thus this probably would make sense to lot of users
out there.
Hi!
This is maybe getting a bit out of topic now, but what about
function/method overloading using type hinting:
function myfunc(string $data) { }
function myfunc(int $data) { }
function myfunc(myClass $data) { }
This currently causes an error in PHP 5.2.5 that function myfunc() can't
be
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases. Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null,
On 07/04/2008, Timothy Chandler [EMAIL PROTECTED] wrote:
I guess I should say it before anyone else does...
It's not the PHP way
- Timothy Chandler
Simple Site Solutions
And before PHP6 neither was native Unicode.
And before PHP5 neither was a lot of the cool features of OOP (yeah
PHP4
Em Seg, 2008-04-07 às 15:48 +1000, Timothy Chandler escreveu:
I guess I should say it before anyone else does...
It's not the PHP way
Do you mean the way that i initially suggest?
Anyway return type hints (probably)? will implemented,
at least it was accepted in 'Minutes PHP Developers
Em Seg, 2008-04-07 às 01:32 -0700, [EMAIL PROTECTED] escreveu:
:: Question
- Weird syntax?|
The syntax with the type casting seems abit weird as I've wrote above, I
would suggest perhaps
On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena [EMAIL PROTECTED] wrote:
class test {
static public function +Itest testing($instance) {
return $instance;
}
}
A more sane syntax, might be something like:
class test {
static function testing($instance) : Itest
Or something like this would be nice too, please avoid using +TYPE or
(TYPE).
class test {
public static Itest function testing($instance) {
return $instance;
}
}
troels knak-nielsen wrote:
On Mon, Apr 7, 2008 at 2:28 PM, Felipe Pena [EMAIL PROTECTED] wrote:
class test {
Hello,
Em Seg, 2008-04-07 às 10:15 -0300, Jarismar Chaves da Silva escreveu:
Or something like this would be nice too, please avoid using +TYPE
or (TYPE).
class test {
public static Itest function testing($instance) {
return $instance;
}
}
troels knak-nielsen wrote:
On Sun, 6 Apr 2008, Mike Lively wrote:
On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena [EMAIL PROTECTED] wrote:
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...)
Em Seg, 2008-04-07 às 15:44 +0200, Derick Rethans escreveu:
On Sun, 6 Apr 2008, Mike Lively wrote:
On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena [EMAIL PROTECTED] wrote:
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
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 4/7/08 9:15 AM, Jarismar Chaves da Silva wrote:
Or something like this would be nice too, please avoid using +TYPE or
(TYPE).
class test {
public static Itest function testing($instance) {
return $instance;
}
}
I think this is the most intuitive approach. However, this means
Stanislav Malyshev wrote:
I'm not sure I understand - how array_reduce is related to having type
hints? You could make array_reduce to do additional things, but that
doesn't require introducing strong typing into php.
The relation between array_reduce and scalar type hints is that API
start to
On 07.04.2008, at 18:49, Christian Schneider wrote:
Felipe Pena wrote:
Right, this shouldn't even be on the agenda before we have scalar
type
hints. So, perhaps you can make a patch for that first Felipe?
I don't thought this before!
Sure, i'll try provide a patch.
Just so this side was
On 07.04.2008, at 18:57, Stanislav Malyshev wrote:
Hi!
I just ran into this (IMHO unnecessary) limitation with array_reduce:
Why should it only reduce to an int? Why not a string or an array? I
plan on submitting a patch for PHP 6 to allow other types too.
I'm not sure I understand - how
Hi!
Right if at all I would agree on having a type hint scalar, but not a
separate one per type.
IMO (as already was discussed like 10 times?) scalar makes no sense.
It doesn't save you any checks, and doesn't provide any useful
information and can't perform any useful conversions, etc. for
On 07/04/2008, Christian Schneider [EMAIL PROTECTED] wrote:
Just so this side was mentioned once again too: There are people who
consider type hints and especially scalar type hints A Bad Thing(tm) as
it is contrary to the PHP strength of dynamic typing and automatic type
conversion.
We
Richard Quadling schrieb:
Type juggling just doesn't seem to fit well with me.
You seem to live in a completely different PHP world. Because in our
case we use (yes, knowingly use) the PHP type juggling and it safes us
lots of manual type conversions.
We get input from all different
Hello ladies and gentlemen,
I made a patch that implements an experimental return type hint,
therefore we need discuss much about this yet, right? :)
My idea uses (php-type) and +className as notation, see below.
- PHP types
function (string) foo(...) { } // Unicode string too
function
Felipe Pena escribió:
Hello ladies and gentlemen,
I made a patch that implements an experimental return type hint,
therefore we need discuss much about this yet, right? :)
Thanks for raising this issue !!
function(int) foo(...) { } // Accepts numeric string
function (double) foo(...) {
On Sun, Apr 6, 2008 at 8:41 PM, Felipe Pena [EMAIL PROTECTED] wrote:
- PHP types
function (string) foo(...) { } // Unicode string too
function (object) foo(...) { } // Strict
function (array) foo(...) { } // Strict
function (bool) foo(...) { } // Strict
function(int) foo(...) { } //
I guess I should say it before anyone else does...
It's not the PHP way
- Timothy Chandler
Simple Site Solutions
Felipe Pena wrote:
Hello ladies and gentlemen,
I made a patch that implements an experimental return type hint,
therefore we need discuss much about this yet, right? :)
My idea
On Wed, September 13, 2006 4:57 am, Terje Slettebø wrote:
I'd say that's debatable. :) Yes, it can make it more convenient to
handle
data coming from outside the script (such as forms), but it can also
hide
bugs. While it can be argued that conversions between, say, arithmetic
types
(int
On Wed, September 13, 2006 6:01 am, Richard Quadling wrote:
The issue then becomes what would happen to a value of the wrong type?
You either have the option of using PHP's own internal casting
mechanism, so f(int $i_int_expected) would internally cast the
supplied parameter as an int or you
When would the constructor be called automatically? I've used Delphi
and you use the inherit verb (or inherited - long time ago - can't
remember exactly). In PHP parent::__construct (though I think
parent::__METHOD__ would be cleaner as this removes ambiguity on the
actual name for all
From: Marcus Boerger [EMAIL PROTECTED]
PHP is not C++ and speaking of constructors and destrcutors PHP goes
morethe
Delphi way.
I'd also like to know _why_ constructors/destructors are less fit for PHP,
than these other languages? How can you be sure that objects of a class are
properly
Well, PHP is a loosely typed language. You have much more freedom when you
write a code. Constructors are not an exception. It is very convinient that
you may not call the parent constructor and many people do it, believe me!
And also the flag for the internal classes that has been discussed is
From: Marian Kostadinov [EMAIL PROTECTED]
Well, PHP is a loosely typed language. You have much more freedom when you
write a code. Constructors are not an exception. It is very convinient that
you may not call the parent constructor and many people do it, believe me!
Why would you not call the
On 9/15/06, Terje Slettebø [EMAIL PROTECTED] wrote:
From: Marcus Boerger [EMAIL PROTECTED]
PHP is not C++ and speaking of constructors and destrcutors PHP goes
morethe
Delphi way.
I'd also like to know _why_ constructors/destructors are less fit for PHP,
than these other languages?
Nobody
Terje Slettebø wrote:
The above was a contrived example, meant to illustrate the point. What's
so
bad about it? That it doesn't check the return value?
I am not worried about the return value of the method. I am concerned
that $this-something is unset yet does not throw a notice. This is
(This went to me privately, but in order for this to benefit the discussion,
I reply to the list, as well. Besides, there's now another thread for this,
too)
Hi Richard.
When would the constructor be called automatically? I've used Delphi
and you use the inherit verb (or inherited - long time
Hello Terje,
Thursday, September 14, 2006, 9:47:20 PM, you wrote:
(This went to me privately, but in order for this to benefit the discussion,
I reply to the list, as well. Besides, there's now another thread for this,
too)
Hi Richard.
When would the constructor be called automatically?
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
One of the good things about PHP is the loose typing (1.00 == 1 == 1
sort of thing as I understand it). This has been useful.
But one of the first things we are told
From: Richard Quadling [EMAIL PROTECTED]
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
One of the good things about PHP is the loose typing (1.00 == 1 == 1
sort of thing as I understand it). This has been
On 13/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
From: Richard Quadling [EMAIL PROTECTED]
On 12/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
function f(Something $value) /** @return SomethingElse */
{
// ...
}
But one of the first things we are told about using PHP ITRW is
Richard Quadling [EMAIL PROTECTED] schreef in bericht
news:[EMAIL PROTECTED]
On 13/09/06, Terje Slettebø [EMAIL PROTECTED] wrote:
..
The issue then becomes what would happen to a value of the wrong type?
You either have the option of using PHP's own internal casting
mechanism, so
Terje Slettebø wrote:
I'd say that's debatable. :) Yes, it can make it more convenient to handle
data coming from outside the script (such as forms), but it can also hide
bugs. While it can be argued that conversions between, say, arithmetic types
(int and floats) may be useful, allowing
Terje Slettebø wrote:
I'd say that's debatable. :) Yes, it can make it more convenient to
handle
data coming from outside the script (such as forms), but it can also
hide
bugs. While it can be argued that conversions between, say, arithmetic
types
(int and floats) may be useful, allowing
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
error_reporting(E_ALL);
$something=new Something;
echo $something-f()+10; // Prints
From: Brian Moon [EMAIL PROTECTED]
--- Start ---
class Something
{
public function __construct()
{
// Oops, forgot to initialise $this-something...
}
public function f()
{
return $this-something;
}
private $something;
}
Hi again.
To something different: I've read [1] that return type hints for functions
have been considered for PHP 6, possibly even planned. In [1], it says: We
will add support for type-hinted return values.
I've searched the archives, but haven't found much on this since about a
year ago. Does
Hello Terje,
at some point i might find time to do something. I guess all others who
could do something in that area are occupied either by unicode or
namespaces. This means we still have this on the todo. We are only open
source and all do stuff in our free time
best regards
marcus
PROTECTED]
To: Terje Slettebø [EMAIL PROTECTED]
Cc: internals@lists.php.net
Sent: Tuesday, September 12, 2006 11:00 PM
Subject: Re: [PHP-DEV] Return type hints
Hello Terje,
at some point i might find time to do something. I guess all others who
could do something in that area are occupied
59 matches
Mail list logo
