>
> This is a potential concern if the aliases for scalar were included (bool,
> int, float, string), as Anthony mentioned, although merely implementing the
> first part of the proposal (scalar type hinting) wouldn't cause any trouble.
>
Yes, exactly. I was only talking about this specific aspect.
On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou wrote:
> Of note, the scalar type hinting I've outlined does not automatically
>> perform casts...
>
>
> Thank you for your answer. Maybe, this exact fact is what I don't like
> about your suggestion. Please read the following RFC, where Lukas S
>
> Of note, the scalar type hinting I've outlined does not automatically
> perform casts...
Thank you for your answer. Maybe, this exact fact is what I don't like
about your suggestion. Please read the following RFC, where Lukas Smith and
Zeev Suraski explain very well why strict type checking w
Adam,
Sure. Basically, if you alias the int hint to scalar:
function foo(int $i) {
}
The following are all valid values for $i:
$i = 1;
$i = 1.5;
$i = "1.9"
$i = "foo"
$i = true
$i = fopen($file);
So, in the future, if we wanted to implement loss-less casting
(casting if possible without loosi
On Thu, Mar 1, 2012 at 8:55 AM, Anthony Ferrara wrote:
> Please do not implement int, float, etc as an alias to scalar. That's
> going to cause nothing but trouble later on. It will instantly close
> the door to any type of casting magic (due to BC concerns), be
> completely non-obvious ("I hin
On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou wrote:
> Yes, I agree, the casting (or the failing to cast) has to happen on entry,
> for the reasons that you have very well explained.
>
> However, I cannot understand what it means to cast an object to a scalar.
> Does it always mean casting to
Please do not implement int, float, etc as an alias to scalar. That's
going to cause nothing but trouble later on. It will instantly close
the door to any type of casting magic (due to BC concerns), be
completely non-obvious ("I hinted for int, why is it a boolean?"), and
cause nothing but confus
Yes, I agree, the casting (or the failing to cast) has to happen on entry,
for the reasons that you have very well explained.
However, I cannot understand what it means to cast an object to a scalar.
Does it always mean casting to string? Wouldn't that be slow in many cases?
Simple example:
clas
On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou wrote:
> And, *what if PHP added the following aliases for the hint scalar*:
>
> - bool
>
> - int
>
> - float
>
> - string
>>
>
> If an object has a __toString method, does it qualify as a valid value to
> be passed to a scalar argument? In my opi
On Thu, Mar 1, 2012 at 10:39 AM, Sebastian Bergmann wrote:
> On 03/01/2012 04:13 AM, Pierre Joye wrote:
>>
>> However, following your logic, class type hinting was a mistake?
>
>
> The Type Hinting we currently have for arrays, callables, classes, and
> interfaces is not a mistake. Why? Because
Pierre Joye wrote:
On Thu, Mar 1, 2012 at 3:36 AM, Sebastian Bergmann wrote:
usually does not work.
>
>2) What you want to achieve is already possible through docblocks.
I am not saying that I like the idea of scalar type arguments, but you
keep saying that docblocks solve such issue. Th
On 03/01/2012 04:13 AM, Pierre Joye wrote:
However, following your logic, class type hinting was a mistake?
The Type Hinting we currently have for arrays, callables, classes, and
interfaces is not a mistake. Why? Because the types in question are not
affected by the "type juggling".
--
Seba
>
> And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
>
If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.
Your suggestion has a future compatibility problem. The i
hi Sebastian,
On Thu, Mar 1, 2012 at 3:36 AM, Sebastian Bergmann wrote:
usually does not work.
>
> 2) What you want to achieve is already possible through docblocks.
I am not saying that I like the idea of scalar type arguments, but you
keep saying that docblocks solve such issue. They are tot
On Wed, Feb 29, 2012 at 09:01:05PM -0500, Adam Jon Richardson wrote:
> However, the lack of scalar hinting does limit the ability of a developer
> to declare his/her intentions for function/method parameters. A non-hinted
> parameter expecting a scalar could be sent an object or an array, breaking
Hi, Adam
I just get the feeling that this is exactly what we're currently discovered
in some other threads in this mailing-list.
We're now getting more and more closer to what we really want and a good
way to write it the PHP-way.
Please try to get a rough overview over the last messages we wrote
First, phpunit is a fantastic tool! I'm thankful for your contributions to
all of the PHP community (especially with the code coverage capabilities.)
I speak to your 2 points inline below:
On Wed, Feb 29, 2012 at 9:36 PM, Sebastian Bergmann wrote:
> On 02/29/2012 09:01 PM, Adam Jon Richardson wr
On 02/29/2012 09:01 PM, Adam Jon Richardson wrote:
However, the aliases would allow developers to better communicate
intentions AND provide more information for IDE's and static analyses
tools.
1) You are trying to solve a social problem through technology. That
usually does not work.
2)
PHP currently allows users to provide type hints for functions and methods,
although the type hints are currently limited to objects and arrays:
http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
Restricting the type hinting to arrays and objects makes sense, as PHP's
type j
19 matches
Mail list logo
