Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Posted by Fleshgrinder 
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 06:20PM
On 12/29/2017 4:09 PM, lists@rhsoft.net wrote:
>
> Am 29.12.2017 um 13:08 schrieb Fleshgrinder:
>> What is the use case for `int|float`? I mean, if f is able to process a
>> `float` than f is able to process an `int` and since `int` is already
>> automatically changed to a `float`, well, you're done
>
> just read the mass of bugreports caused by float answered with the
> default paragraph below and you know why you don't want your int-values
> silently converted to a float
>
> 7 may become to 7.000000000000000001 or something similar and "$x === 7"
> may also fail wile the argument was int 7
> ________________________
>
> Floating point values have a limited precision. Hence a value might
> not have the same string representation after any processing. That also
> includes writing a floating point value in your script and directly
> printing it without any mathematical operations.
>
> If you would like to know more about "floats" and what IEEE
> 754 is, read this:
> http://www.floating-point-gui.de/
>

Obviously but this does not answer anything. You expect an int or a
float, hence, you need to be prepared to handle floats. Your 7 example
is the best illustration. You need to handle those situations in your
script with the appropriate strategy for your domain (rounding,
truncation, floor, ...).

--
Richard "Fleshgrinder" Fussenegger

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 29.12.2017 um 18:18 schrieb Fleshgrinder:
> On 12/29/2017 4:09 PM, lists@rhsoft.net wrote:
>>
>> Am 29.12.2017 um 13:08 schrieb Fleshgrinder:
>>> What is the use case for `int|float`? I mean, if f is able to process a
>>> `float` than f is able to process an `int` and since `int` is already
>>> automatically changed to a `float`, well, you're done
>>
>> just read the mass of bugreports caused by float answered with the
>> default paragraph below and you know why you don't want your int-values
>> silently converted to a float
>>
>> 7 may become to 7.000000000000000001 or something similar and "$x === 7"
>> may also fail wile the argument was int 7
>> ________________________
>>
>> Floating point values have a limited precision. Hence a value might
>> not have the same string representation after any processing. That also
>> includes writing a floating point value in your script and directly
>> printing it without any mathematical operations.
>>
>> If you would like to know more about "floats" and what IEEE
>> 754 is, read this:
>> http://www.floating-point-gui.de/
>
> Obviously but this does not answer anything. You expect an int or a
> float, hence, you need to be prepared to handle floats. Your 7 example
> is the best illustration. You need to handle those situations in your
> script with the appropriate strategy for your domain (rounding,
> truncation, floor, ...)

no, when i accept "int|float" i don't get something converted at all and
i can handle the cases different - when it#s silently casted to a float
i have no way to know it was a int at call time

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 29.12.2017 um 18:13 schrieb Fleshgrinder:
> Why exactly is it necessary to support weak mode together with unions
> and intersections? It is obviously unclear in many situations what
> should happen, so why not simply bail like in strict mode?

is also a good enough way to handle it now as we have the problem that a
type-hinted param don't accept NULL and cast it to 0 anyways even in
weak mode

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 06:30PM
On 12/29/2017 6:21 PM, lists@rhsoft.net wrote:
> no, when i accept "int|float" i don't get something converted at all and
> i can handle the cases different - when it#s silently casted to a float
> i have no way to know it was a int at call time
>

Again, obviously, the question remains, why would you care? Please
provide convincing arguments as this would become the body of the
corresponding RFC. Adding that type is super simple, the question is why
is it so super handy?

PS: Despite union and intersection types, they automatically allow this
form and I repeat that I am totally in favor of them. The question is
truly about `number` only which would accept `int` and `float` (no
`string`).

--
Richard "Fleshgrinder" Fussenegger

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Markus Fischer
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 06:40PM
Hi all,

On 26.12.17 16:56, Sebastian Bergmann wrote:
> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net:
>> would you mind to explain this?
>
> "Foo|Bar", "array|string", etc. (still) make no sense to me.
>
> "scalar" makes sense to me although it is but an alias for
> "bool|float|int|string".

I followed the discussion and found it interesting how strong the focus
shifted about the discussion of the practical use cases. I would be for
union types or scalars in ab instant, but I never had reason to scan our
code-base and figure what would make really sense.

Mind you this is a private codebase (Laravel based, as can be seen by
some of the class names) but one where we tend to be very explicit about
documenting everything, thus I knew I could just go ahead and extract
the type hints using the '|' character and get back a pretty complete
picture:

$ grep -r '@param' *|grep \| | awk '{ print $4 }'|sort -u
Attachment[]|Collection
Attachment[]|null
Builder|null
Channel|Post|int|null
Channel|int|null
ClientInterface|null
Client|int|null
Collection|Attachment[]
Collection|Channel[]
Collection|Comment[]
Collection|JsonapiModel[]
Collection|Model[]
Collection|Post[]
DateTime|Carbon|string|null
Dispatcher|null
EloquentCollection|JsonapiModel[]
Exception|null
Group|Group[]|Client|Client[]|Channel|Channel[]|null
Group|int|null
JsonapiModel|null
Model|int|null
Post[]|null
Post|int|null
Profile|int|null
ResponseInterface|null
Throwable|null
User|int|null
\ArrayAccess|array|JsonapiModel[]|null
array|false
array|null
int[]|int
int|int[]
int|null
mixed|null
null|LoggerInterface
null|Model
null|Model[]|Collection
null|string
string[]|Expression[]
string|int
string|null

This is extracted from a codebase with ~400 files and ~43k LOC (incl.
comments). I'm not saying anything like this is relevant codebase, but
it's a project whose code quality I know well and I know the reason for
every piece there.

Since the discussion focuses on scalars here and ignoring all the
nullables (they're auto-documented that way via PhpStorm) as well as
ignoring the pseudo array-type hints, this leaves us really with only:

- array|false
Only 1 occurrence, used for crafting a remote HTTP call which has an
interface which accepts either an array or false
Am 29.12.2017 um 18:24 schrieb Fleshgrinder:
> On 12/29/2017 6:21 PM, lists@rhsoft.net wrote:
>> no, when i accept "int|float" i don't get something converted at all and
>> i can handle the cases different - when it#s silently casted to a float
>> i have no way to know it was a int at call time
>>
>
> Again, obviously, the question remains, why would you care? Please
> provide convincing arguments as this would become the body of the
> corresponding RFC. Adding that type is super simple, the question is why
> is it so super handy?

beause i can insert the value to a int field of a database without
additional costs, because i can write faster code-paths dealing with
integers which don't have all the magic problems of floats and so on

> PS: Despite union and intersection types, they automatically allow this
> form and I repeat that I am totally in favor of them. The question is
> truly about `number` only which would accept `int` and `float` (no
> `string`)

nobody needs "number" - the problem is that people downvoted the union
RFC for no good reasons and "i don't see a benefit, i don't like it" are
no valid reasons to do so - and to the other guy which asked why someone
should up-vote for something he don't understand - nobody says that - i
didn't know that voting for each and any RFC is mandatory - so just
ignore it when you don#t care instead downvote

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 29.12.2017 um 18:29 schrieb Markus Fischer:
> On 26.12.17 16:56, Sebastian Bergmann wrote:
>> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net:
>>> would you mind to explain this?
>>
>> "Foo|Bar", "array|string", etc. (still) make no sense to me.
>>
>> "scalar" makes sense to me although it is but an alias for
>> "bool|float|int|string".
>
> I followed the discussion and found it interesting how strong the focus
> shifted about the discussion of the practical use cases

because a lot of people demand that instead realize that with
union-types all that discussions would have ended because it's totally
on the application side written in PHP after that

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stephen Reay
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 07:40PM
> On 30 Dec 2017, at 00:24, Fleshgrinder <[email protected]> wrote:
>
> Again, obviously, the question remains, why would you care?

Really, that's what's obvious to you?

What's obvious to *me* is that if a method accepts two different types of parameters, you'd want to know which was passed in.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 30, 2017 10:20AM
wrote in message news:[email protected]
>
>
>
>Am 29.12.2017 um 09:04 schrieb Tony Marston:
>> wrote in message news:[email protected]
>>>
>>> Am 29.12.2017 um 00:21 schrieb Larry Garfield:
>>>> Correct. Union types I've always seen presented as offering both union
>>>> and
>>>> intersection. There are cases where union is great, and where it's
>>>> kinda
>>>> silly. There are cases where intersect is great, and where it's kinda
>>>> silly.
>>>>
>>>> Most of the anti- arguments I've seen for "union types" have fixated on
>>>> "int &&
>>>> string is meaningless, and Foo || Bar is bad design, so union types are
>>>> bad!"
>>>> Entirely ignoring the flip side, which is int || string (valid use
>>>> cases) and
>>>> Foo && Bar (many many valid use cases)
>>>
>>> well, that explains why the same person which hase a usecase for a
>>> "scalar" pseudo-type donw-votes https://wiki.php.net/rfc/union_types but
>>> it makes his vote not logical at all
>>>
>>> frankly the only valid reasons to down-vote something should be
>>> technical ones which matters for the PHP core itself and not "i don't
>>> understand a feature hence nobody should have it"
>>
>> You are missing the point. If an RFC is so badly written that someone
>> does not understand it, or understand what benefits it is supposed to
>> provide, then there is no point in up-voting it
>
>if i don't undrstand it i don't vote at all - that's the point
>
>not up
>not down

If you can't understand it then you cannot tell what benefit it gives to the
greater PHP community, and if you cannot see that it provides any benefit
then you should vote it DOWN. Common sense should dictate that you only vote
it UP when you are convinced that it will provide something of benefit. If
you don't vote at all you are admitting that you are clueless, or don't
care, in which case you are not preventing a bad idea from being accepted.
If it later turns out that it was a crock of sh*t then you will be partly to
blame because you didn't have the intelligence to see it as such and didn't
speak up. If you don't understand an RFC then not only do you not understand
the benefits that it can provide, you also don't understand the damage that
it can cause.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 30.12.2017 um 10:16 schrieb Tony Marston:
> wrote in message news:[email protected]
>>> You are missing the point. If an RFC is so badly written that someone
>>> does not understand it, or understand what benefits it is supposed to
>>> provide, then there is no point in up-voting it
>>
>> if i don't undrstand it i don't vote at all - that's the point
>>
>> not up
>> not down
>
> If you can't understand it then you cannot tell what benefit it gives to
> the greater PHP community, and if you cannot see that it provides any
> benefit then you should vote it DOWN. Common sense should dictate that
> you only vote it UP when you are convinced that it will provide
> something of benefit. If you don't vote at all you are admitting that
> you are clueless, or don't care, in which case you are not preventing a
> bad idea from being accepted. If it later turns out that it was a crock
> of sh*t then you will be partly to blame because you didn't have the
> intelligence to see it as such and didn't speak up. If you don't
> understand an RFC then not only do you not understand the benefits that
> it can provide, you also don't understand the damage that it can cause.

frankly, in the real world when you don't understand what some people
are talking about you don't join and say "no, you are wrong" - you
either shut up or ask again but you don't step in yelling "no!"

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 30, 2017 11:40AM
On 30/12/17 09:16, Tony Marston wrote:
>>> You are missing the point. If an RFC is so badly written that someone
>>> does not understand it, or understand what benefits it is supposed to
>>> provide, then there is no point in up-voting it
>>
>> if i don't undrstand it i don't vote at all - that's the point
>>
>> not up
>> not down
>
> If you can't understand it then you cannot tell what benefit it gives to
> the greater PHP community, and if you cannot see that it provides any
> benefit then you should vote it DOWN.

Not being able to vote, many of us have no option to complain about the
way things are going. Currently there seems to be several styles of PHP
form the nice and simple untyped version I moved to from very strictly
typed hard compiled code I'd been using up until then, through to
current code which is reliant on third party things like PSR and
Composer and expects only strictly typed PHP.

The 'greater PHP community' I continue to support is still only looking
for a simply life, but each iteration of PHP7 is just making things more
and more complex, which is why I STILL have not switched off PHP5 and
5.4 and earlier is still running a large percentage of sites. Just what
percentage of the wider community thinks that strict typing is giving an
essential benefit? If there was a groundswell for typing then perhaps we
would not have this continual debate on just how to jam a little more of
a move that way and get on with a version of PHP that is only typed.
Then for one can simply avoid it ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 30.12.2017 um 11:37 schrieb Lester Caine:
> On 30/12/17 09:16, Tony Marston wrote:
>>>> You are missing the point. If an RFC is so badly written that someone
>>>> does not understand it, or understand what benefits it is supposed to
>>>> provide, then there is no point in up-voting it
>>>
>>> if i don't undrstand it i don't vote at all - that's the point
>>>
>>> not up
>>> not down
>>
>> If you can't understand it then you cannot tell what benefit it gives to
>> the greater PHP community, and if you cannot see that it provides any
>> benefit then you should vote it DOWN.
>
> The 'greater PHP community' I continue to support is still only looking
> for a simply life, but each iteration of PHP7 is just making things more
> and more complex, which is why I STILL have not switched off PHP5 and
> 5.4 and earlier is still running a large percentage of sites. Just what
> percentage of the wider community thinks that strict typing is giving an
> essential benefit? If there was a groundswell for typing then perhaps we
> would not have this continual debate on just how to jam a little more of
> a move that way and get on with a version of PHP that is only typed.
> Then for one can simply avoid it ...

who thinks it don't give you a benefit?

for new code it's the best you can do do get it as bugfree as possible
and fro old code you still are not forec to any typehints and for
migration you have weak types too

sorry, but discuss end of 2017 if types was a goof d idea and talk about
the 'greater community' but still run PHP5? in the meantime I have
changed *everything* written in the last 15 yeas to strict_types=1 and
type hints everywhere - you find so much potential bugs that it's worth

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 30, 2017 04:20PM
On 29.12.2017 at 16:37, Nikita Popov wrote:

> On Fri, Dec 29, 2017 at 1:08 PM, Fleshgrinder <[email protected]> wrote:
>
>> What is the use case for `int|float`? I mean, if f is able to process a
>> `float` than f is able to process an `int` and since `int` is already
>> automatically changed to a `float`, well, you're done.
>
> int|float is the natural type of numeric operations in PHP. Integers
> automatically overflow into floating point numbers, so signatures using int
> in conjunction with numeric operations are somewhat problematic.

In my humble opinion, introducing `int|float` or `number` types would
not solve the real problem, namely that overflowing to float easily
causes unexpected behavior. For instance:

PHP_INT_MAX + 1 > PHP_INT_MAX // => false (64bit arch)

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 30, 2017 06:20PM
Am 29.12.2017 um 18:30 schrieb lists@rhsoft.net:
> "i don't see a benefit, i don't like it" are no valid reasons to do so

I strongly disagree. If a majority of people do not see the benefit of a
syntax change then the syntax should not be changed. A change to the
syntax of PHP has a ripple effect throughout the library and tools
ecosystem of PHP. This is a cost. This cost needs to be justified by a
benefit.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 30, 2017 06:20PM
Am 29.12.2017 um 16:37 schrieb Nikita Popov:
> Having an explicit number type also goes well with an explicit number cast.
> PHP internally has a notion of a number cast (which is the basis for
> arithmetic operations), but currently does not expose it. As such, number
> casts currently have to be simulated using workarounds like +$x.

PHP also already has is_numeric().

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 30.12.2017 um 18:15 schrieb Sebastian Bergmann:
> Am 29.12.2017 um 18:30 schrieb lists@rhsoft.net:
>> "i don't see a benefit, i don't like it" are no valid reasons to do so
>
> I strongly disagree. If a majority of people do not see the benefit of a
> syntax change then the syntax should not be changed. A change to the
> syntax of PHP has a ripple effect throughout the library and tools
> ecosystem of PHP. This is a cost. This cost needs to be justified by a
> benefit.

which costs do a new feature without BC break have for the ecosystem?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Michael Morris
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 30, 2017 11:00PM
On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <[email protected]> wrote:

>
> Not being able to vote, many of us have no option to complain about the
> way things are going. Currently there seems to be several styles of PHP
> form the nice and simple untyped version I moved to from very strictly
> typed hard compiled code I'd been using up until then, through to
> current code which is reliant on third party things like PSR and
> Composer and expects only strictly typed PHP.
>
>

This is born of the fact that while ignoring datatype makes learning PHP
easier, it makes using it harder - especially when testing.

Mark me as against union types. First, it places the burden of getting the
type right on the calling programmer. Stock PHP code doesn't do this and if
popular 3rd party libraries start doing this too much it makes the language
harder to learn.

Second it blocks this proposal, which is a way to give people who want to
control types the ability to do so in their own code without creating BC
breaks in PHP or interoperability problems with other libraries. Doing this
requires declaring variable types as an OPTION. The default type of a
variable will be scalar.

Under what I propose putting what is now a type hint on the function line
will become a type declaration, and a casting operation will result if the
wrong type is passed in. So

function foo( int $a ) {}

Obviously this path becomes unavailable to us with union types - and by
comparison union types is an ineffective band-aid. The above is a shorthand
for this

function foo ( $arg ) {
var int $a = $arg;
}

When a variable is declared this way it will autocast any assignment to the
declared type. The only way to get around this is redeclare the type.

Now some might be wondering, why not use this shorter statement:

int $a = 3;

The reason is this - I propose that syntax will lock the type down, but it
won't autocast assignments - it iwll instead throw a TypeError if the
assignment type doesn't match.

Anyway, there is one BC break - see it?

function foo( int $a ) {
$a = 'hi';
}

Currently $a becomes a string of 'hi'. Under this proposal $a remains an it
and it is assigned the cast result of 'hi', which I believe is 0. Since the
format is relatively new - PHP 7 - changing it in 8 won't be as disruptive
as something that's been around a long time. Also, changing a var type
deliberately after declaring it is a bad practice, further reducing the
scope of code affected, but it's certainly not 0, so this is PHP 8.0
minimum.

Now next, class instance creation.

SomeClass $a = new SomeClass();

Doing this locks $a to SomeClass, and trying to assign it to something else
will trip a type error.

var SomeClass $a = new SomeClass();

Since there's no way to cast arbitrary arguments to SomeClass I'm not sure
how this should be handled.

Within classes..

class SomeClass {

public $a = null; // Creates a scalar.

public var int $b = 3; // Creates an autocasting int

protected int $c = 5; // Creates an int. Errors will pitch on bad assign.

protected OtherClass $b;

}

This syntax locks down, or *really* locks down types, but it's entirely
opt-in. If we're going to go down the road of sticter types this has to be
done. It's also an example of why pasting in functionality without an
over-arching plan is a bad idea. If Union types is included part of this
solution will be forever lost since it's likely incompatible with union
types (or at least union types with scalars - union types with objects
wouldn't be affected).
Am 30.12.2017 um 22:55 schrieb Michael Morris:
> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <[email protected]> wrote:
>
>>
>> Not being able to vote, many of us have no option to complain about the
>> way things are going. Currently there seems to be several styles of PHP
>> form the nice and simple untyped version I moved to from very strictly
>> typed hard compiled code I'd been using up until then, through to
>> current code which is reliant on third party things like PSR and
>> Composer and expects only strictly typed PHP.
>
> This is born of the fact that while ignoring datatype makes learning PHP
> easier, it makes using it harder - especially when testing.

and using type hints is completly opt-in at all

> Mark me as against union types. First, it places the burden of getting the
> type right on the calling programmer. Stock PHP code doesn't do this and if
> popular 3rd party libraries start doing this too much it makes the language
> harder to learn.

but the outcome is way cleaner because errors are not silently as it is
now without using type-hints - anyways, you are not forced to use any
type hints at all but the people which know how bad code works without
care about are able to do so and without unnions that all is very limited

> Second it blocks this proposal, which is a way to give people who want to
> control types the ability to do so in their own code without creating BC
> breaks in PHP or interoperability problems with other libraries. Doing this
> requires declaring variable types as an OPTION. The default type of a
> variable will be scalar.

that is not true - even if the syntax would be BC compatible the
behavior won#t

> Under what I propose putting what is now a type hint on the function line
> will become a type declaration, and a casting operation will result if the
> wrong type is passed in. So
>
> function foo( int $a ) {}
>
> Obviously this path becomes unavailable to us with union types - and by
> comparison union types is an ineffective band-aid. The above is a shorthand
> for this
>
> function foo ( $arg ) {
> var int $a = $arg;
> }
>
> When a variable is declared this way it will autocast any assignment to the
> declared type. The only way to get around this is redeclare the type

this is hard to optimize - just look at the optimizations of PHP 7.1

also this ship has sailed long ago as we now have type hints (and i did
not understand at all why they where intoruced in 5.3 only for arrays
and objects)

the point of union types is that you are not limited to "int or float or
string" but can say "int or string both are OK, i hanlde that in my
code" and so you can use strict_types with GET/POST or database results
which are by defintion string but don't accept objects or arrays you
can't handle proper

function test(int|string $x)
{
$x = (int)$x;
}

currently without type-hints you have a "array to string conversion"
insead fail and fix that at the caller where *obvisouly* nobody did
realize that any random var froma request could be any array

this has to be checked *before* call a function with such invalid data

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 31, 2017 11:20AM
wrote in message news:[email protected]
>
>
>
>Am 30.12.2017 um 10:16 schrieb Tony Marston:
>> wrote in message news:[email protected]
>>>> You are missing the point. If an RFC is so badly written that someone
>>>> does not understand it, or understand what benefits it is supposed to
>>>> provide, then there is no point in up-voting it
>>>
>>> if i don't undrstand it i don't vote at all - that's the point
>>>
>>> not up
>>> not down
>>
>> If you can't understand it then you cannot tell what benefit it gives to
>> the greater PHP community, and if you cannot see that it provides any
>> benefit then you should vote it DOWN. Common sense should dictate that
>> you only vote it UP when you are convinced that it will provide something
>> of benefit. If you don't vote at all you are admitting that you are
>> clueless, or don't care, in which case you are not preventing a bad idea
>> from being accepted. If it later turns out that it was a crock of sh*t
>> then you will be partly to blame because you didn't have the intelligence
>> to see it as such and didn't speak up. If you don't understand an RFC
>> then not only do you not understand the benefits that it can provide, you
>> also don't understand the damage that it can cause.
>
>frankly, in the real world when you don't understand what some people are
>talking about you don't join and say "no, you are wrong" - you either shut
>up or ask again but you don't step in yelling "no!"

It is not about an idea being right or wrong, it is about adding something
new to the language. If you are not convinced that it will add value to the
language then you should vote it down. Not voting either way because you
don't understand the RFC or its proposed benefits just shows that you aren't
qualified to vote on anything.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 31, 2017 11:30AM
wrote in message news:[email protected]
>
>
>
>Am 30.12.2017 um 11:37 schrieb Lester Caine:
>> On 30/12/17 09:16, Tony Marston wrote:
>>>>> You are missing the point. If an RFC is so badly written that someone
>>>>> does not understand it, or understand what benefits it is supposed to
>>>>> provide, then there is no point in up-voting it
>>>>
>>>> if i don't undrstand it i don't vote at all - that's the point
>>>>
>>>> not up
>>>> not down
>>>
>>> If you can't understand it then you cannot tell what benefit it gives to
>>> the greater PHP community, and if you cannot see that it provides any
>>> benefit then you should vote it DOWN.
>>
>> The 'greater PHP community' I continue to support is still only looking
>> for a simply life, but each iteration of PHP7 is just making things more
>> and more complex, which is why I STILL have not switched off PHP5 and
>> 5.4 and earlier is still running a large percentage of sites. Just what
>> percentage of the wider community thinks that strict typing is giving an
>> essential benefit? If there was a groundswell for typing then perhaps we
>> would not have this continual debate on just how to jam a little more of
>> a move that way and get on with a version of PHP that is only typed.
>> Then for one can simply avoid it ...
>
>who thinks it don't give you a benefit?
>
>for new code it's the best you can do do get it as bugfree as possible and
>fro old code you still are not forec to any typehints and for migration you
>have weak types too
>
>sorry, but discuss end of 2017 if types was a goof d idea and talk about
>the 'greater community' but still run PHP5? in the meantime I have changed
>*everything* written in the last 15 yeas to strict_types=1 and type hints
>everywhere - you find so much potential bugs that it's worth

Some of us are clever enough to write code that doesn't have those types of
bug in the first place. I developed my framework in PHP4 before type hints
even existed, and I developed a large enterprise application with that
framework which is now being sold to large corporations all over the world.
That codebase has moved from PHP 4 through all versions of PHP 5 and is now
running on PHP 7.1. During these upgrades I have only changed my code to
deal with what has been deprecated, and I have never bothered with any of
those new optional extras (such as typehints) unless I have been convinced
that the effort of changing my code has measureable benefits.

The idea that typehints provide benefits to the whole PHP community is
completely bogus. It only provides apparent benefits to those programmers
who have moved from a strictly type language to PHP and who feel lost
without the crutch that a strongly typed language seems to provide. I work
faster with a dynamically and weakly typed language, so speed of development
is far more important to me. Any so-called bugs are detected and fixed
during the testing phase, so I don't want the language being slowed down
performing checks that I don't want.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 31, 2017 11:30AM
"Michael Morris" wrote in message
news:[email protected]om...
>
>On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <[email protected]> wrote:
>
>>
>> Not being able to vote, many of us have no option to complain about the
>> way things are going. Currently there seems to be several styles of PHP
>> form the nice and simple untyped version I moved to from very strictly
>> typed hard compiled code I'd been using up until then, through to
>> current code which is reliant on third party things like PSR and
>> Composer and expects only strictly typed PHP.
>>
>>
>
>This is born of the fact that while ignoring datatype makes learning PHP
>easier, it makes using it harder - especially when testing.

I strongly disagree. I have been using PHP since 2001 and I have never used
type hinting in any form whasoever. Does it make testing more difficult? No,
it does not.

<snip>

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 31, 2017 12:10PM
On 31/12/17 10:24, Tony Marston wrote:
> wrote in message news:[email protected]
>>
>>
>>
>> Am 30.12.2017 um 11:37 schrieb Lester Caine:
>>> On 30/12/17 09:16, Tony Marston wrote:
>>>>>> You are missing the point. If an RFC is so badly written that someone
>>>>>> does not understand it, or understand what benefits it is supposed to
>>>>>> provide, then there is no point in up-voting it
>>>>>
>>>>> if i don't undrstand it i don't vote at all - that's the point
>>>>>
>>>>> not up
>>>>> not down
>>>>
>>>> If you can't understand it then you cannot tell what benefit it
>>>> gives to
>>>> the greater PHP community, and if you cannot see that it provides any
>>>> benefit then you should vote it DOWN.
>>>
>>> The 'greater PHP community' I continue to support is still only looking
>>> for a simply life, but each iteration of PHP7 is just making things more
>>> and more complex, which is why I STILL have not switched off PHP5 and
>>> 5.4 and earlier is still running a large percentage of sites. Just what
>>> percentage of the wider community thinks that strict typing is giving an
>>> essential benefit? If there was a groundswell for typing then perhaps we
>>> would not have this continual debate on just how to jam a little more of
>>> a move that way and get on with a version of PHP that is only typed.
>>> Then for one can simply avoid it ...
>>
>> who thinks it don't give you a benefit?
>>
>> for new code it's the best you can do do get it as bugfree as possible
>> and fro old code you still are not forec to any typehints and for
>> migration you have weak types too
>>
>> sorry, but discuss end of 2017 if types was a goof d idea and talk
>> about the 'greater community' but still run PHP5? in the meantime I
>> have changed *everything* written in the last 15 yeas to
>> strict_types=1 and type hints everywhere - you find so much potential
>> bugs that it's worth
>
> Some of us are clever enough to write code that doesn't have those types
> of bug in the first place. I developed my framework in PHP4 before type
> hints even existed, and I developed a large enterprise application with
> that framework which is now being sold to large corporations all over
> the world. That codebase has moved from PHP 4 through all versions of
> PHP 5 and is now running on PHP 7.1. During these upgrades I have only
> changed my code to deal with what has been deprecated, and I have never
> bothered with any of those new optional extras (such as typehints)
> unless I have been convinced that the effort of changing my code has
> measureable benefits.
>
> The idea that typehints provide benefits to the whole PHP community is
> completely bogus. It only provides apparent benefits to those
> programmers who have moved from a strictly type language to PHP and who
> feel lost without the crutch that a strongly typed language seems to
> provide. I work faster with a dynamically and weakly typed language, so
> speed of development is far more important to me.  Any so-called bugs
> are detected and fixed during the testing phase, so I don't want the
> language being slowed down performing checks that I don't want.

Thanks for that Tony ... almost exactly where I am as well ... I started
just as PHP5 came to final betas - from C++ - and never had a problem
with the flexibility that provided.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 31.12.2017 um 11:24 schrieb Tony Marston:
> Some of us are clever enough to write code that doesn't have those types
> of bug in the first place. I developed my framework in PHP4 before type
> hints even existed, and I developed a large enterprise application with
> that framework which is now being sold to large corporations all over
> the world. That codebase has moved from PHP 4 through all versions of
> PHP 5 and is now running on PHP 7.1. During these upgrades I have only
> changed my code to deal with what has been deprecated, and I have never
> bothered with any of those new optional extras (such as typehints)
> unless I have been convinced that the effort of changing my code has
> measureable benefits.

well my codebase dates back to 2002 but is stricted-typed in the
meantime - and now?

> The idea that typehints provide benefits to the whole PHP community is
> completely bogus. It only provides apparent benefits to those
> programmers who have moved from a strictly type language to PHP and who
> feel lost without the crutch that a strongly typed language seems to
> provide. I work faster with a dynamically and weakly typed language, so
> speed of development is far more important to me.  Any so-called bugs
> are detected and fixed during the testing phase, so I don't want the
> language being slowed down performing checks that I don't want.
nosense - after 15 years PHP andmoved everything to strict_types in 2017
(the current year) you can't accuse me that i have recebtly moved from a
strongly typed language to PHP and felt lost all the years before

you think you work faster because you even don't realize small bugs
until they become large enough that you sit there and debug for hours
while a type-error with a stacktrace would have shown the mistake at the
begin including the root cause


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 31.12.2017 um 11:27 schrieb Tony Marston:
> "Michael Morris"  wrote in message
> news:[email protected]om...
>>
>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <[email protected]> wrote:
>>
>>>
>>> Not being able to vote, many of us have no option to complain about the
>>> way things are going. Currently there seems to be several styles of PHP
>>> form the nice and simple untyped version I moved to from very strictly
>>> typed hard compiled code I'd been using up until then, through to
>>> current code which is reliant on third party things like PSR and
>>> Composer and expects only strictly typed PHP.
>>
>> This is born of the fact that while ignoring datatype makes learning PHP
>> easier, it makes using it harder - especially when testing.
>
> I strongly disagree. I have been using PHP since 2001 and I have never
> used type hinting in any form whasoever. Does it make testing more
> difficult? No, it does not

"I have never used type hinting in any form whasoever" - so how can you
be qualified at all to tell anything about the difference how it would
be if you would have used it?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dustin Wheeler
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 31, 2017 08:20PM
>
> On Dec 31, 2017, at 10:33 AM, "[email protected]" <[email protected]> wrote:
>
>
>
>> Am 31.12.2017 um 11:27 schrieb Tony Marston:
>> "Michael Morris" wrote in message news:[email protected]om...
>>>
>>>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <[email protected]> wrote:
>>>>
>>>>
>>>> Not being able to vote, many of us have no option to complain about the
>>>> way things are going. Currently there seems to be several styles of PHP
>>>> form the nice and simple untyped version I moved to from very strictly
>>>> typed hard compiled code I'd been using up until then, through to
>>>> current code which is reliant on third party things like PSR and
>>>> Composer and expects only strictly typed PHP.
>>>
>>> This is born of the fact that while ignoring datatype makes learning PHP
>>> easier, it makes using it harder - especially when testing.
>> I strongly disagree. I have been using PHP since 2001 and I have never used type hinting in any form whasoever. Does it make testing more difficult? No, it does not
>
> "I have never used type hinting in any form whasoever" - so how can you be qualified at all to tell anything about the difference how it would be if you would have used it?

Could the discussion be re-centered around the RFC at-hand rather than measuring "ego"? It seems that any thread that has both rhsoft and Tony involved devolves into a competition of opinion without much attempt to meet in the middle or understand one another.

Thanks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
January 01, 2018 10:20AM
wrote in message news:[email protected]
>
>
>
>Am 31.12.2017 um 11:24 schrieb Tony Marston:
>> Some of us are clever enough to write code that doesn't have those types
>> of bug in the first place. I developed my framework in PHP4 before type
>> hints even existed, and I developed a large enterprise application with
>> that framework which is now being sold to large corporations all over the
>> world. That codebase has moved from PHP 4 through all versions of PHP 5
>> and is now running on PHP 7.1. During these upgrades I have only changed
>> my code to deal with what has been deprecated, and I have never bothered
>> with any of those new optional extras (such as typehints) unless I have
>> been convinced that the effort of changing my code has measureable
>> benefits.
>
>well my codebase dates back to 2002 but is stricted-typed in the meantime -
>and now?

PHP was never strictly typed from the start, and I have always loved the
flexibility that this provided. I have never felt the urge to use typehints
(or type enforcement that it has now become)and any potential bugs that this
may create are quickly identified and resolved during my testing.

>> The idea that typehints provide benefits to the whole PHP community is
>> completely bogus. It only provides apparent benefits to those programmers
>> who have moved from a strictly type language to PHP and who feel lost
>> without the crutch that a strongly typed language seems to provide. I
>> work faster with a dynamically and weakly typed language, so speed of
>> development is far more important to me. Any so-called bugs are detected
>> and fixed during the testing phase, so I don't want the language being
>> slowed down performing checks that I don't want.
>
>nosense - after 15 years PHP andmoved everything to strict_types in 2017
>(the current year) you can't accuse me that i have recebtly moved from a
>strongly typed language to PHP and felt lost all the years before

Just because a whole load of new features have been added to the language
does not mean that I should use them. They are entirely optional, and I
choose NOT to use them unless I am convinced that the benefits are worth the
effort.

>you think you work faster because you even don't realize small bugs until
>they become large enough that you sit there and debug for hours while a
>type-error with a stacktrace would have shown the mistake at the begin
>including the root cause

As I said previously, any such errors that may be caused by not using a
strictly typed language are detected and fixed when I test my code. My main
application has been in live use since 2008, and you can count on one hand
the number of bugs which are reported each year.

--
Tony Marston



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
January 01, 2018 10:20AM
wrote in message news:[email protected]
>
>
>
>Am 31.12.2017 um 11:27 schrieb Tony Marston:
>> "Michael Morris" wrote in message
>> news:[email protected]om...
>>>
>>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <[email protected]>
>>> wrote:
>>>
>>>>
>>>> Not being able to vote, many of us have no option to complain about the
>>>> way things are going. Currently there seems to be several styles of PHP
>>>> form the nice and simple untyped version I moved to from very strictly
>>>> typed hard compiled code I'd been using up until then, through to
>>>> current code which is reliant on third party things like PSR and
>>>> Composer and expects only strictly typed PHP.
>>>
>>> This is born of the fact that while ignoring datatype makes learning PHP
>>> easier, it makes using it harder - especially when testing.
>>
>> I strongly disagree. I have been using PHP since 2001 and I have never
>> used type hinting in any form whasoever. Does it make testing more
>> difficult? No, it does not
>
>"I have never used type hinting in any form whasoever" - so how can you be
>qualified at all to tell anything about the difference how it would be if
>you would have used it?

I know that it would take a HUGE amount of effort to go through my massive
code base to put typehints on every function and method, but for what
benefit? Unless I can measure a definite performance gain then the lack of
benefits would not justify the cost.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
January 01, 2018 10:30AM
"Dustin Wheeler" wrote in message
news:[email protected]
>
>>
>> On Dec 31, 2017, at 10:33 AM, "[email protected]" <[email protected]>
>> wrote:
>>
>>
>>
>>> Am 31.12.2017 um 11:27 schrieb Tony Marston:
>>> "Michael Morris" wrote in message
>>> news:[email protected]om...
>>>>
>>>>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <[email protected]>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Not being able to vote, many of us have no option to complain about
>>>>> the
>>>>> way things are going. Currently there seems to be several styles of
>>>>> PHP
>>>>> form the nice and simple untyped version I moved to from very strictly
>>>>> typed hard compiled code I'd been using up until then, through to
>>>>> current code which is reliant on third party things like PSR and
>>>>> Composer and expects only strictly typed PHP.
>>>>
>>>> This is born of the fact that while ignoring datatype makes learning
>>>> PHP
>>>> easier, it makes using it harder - especially when testing.
>>> I strongly disagree. I have been using PHP since 2001 and I have never
>>> used type hinting in any form whasoever. Does it make testing more
>>> difficult? No, it does not
>>
>> "I have never used type hinting in any form whasoever" - so how can you
>> be qualified at all to tell anything about the difference how it would be
>> if you would have used it?
>
>Could the discussion be re-centered around the RFC at-hand rather than
>measuring "ego"? It seems that any thread that has both rhsoft and Tony
>involved devolves into a competition of opinion without much attempt to
>meet in the middle or understand one another.
>
>Thanks. =

Any attempt to make typehinting (or type enforcement as it has now become)
is simply adding complications to the language which do not provide benefits
to the greater PHP community, just a minority of poor coders who want the
language to trap the bugs that they create in their code. There are some of
us out there who are capable of writing bug-free code without type
enforcement, so this RFC (and anything else connected with type
hinting/enforcement) is something we don't need to use, therefore it has no
benefits for us.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
January 01, 2018 12:10PM
On 31/12/17 22:45, Michael Morris wrote:
> Please do not quote large swaths of Tony Marston's crap.  He's an
> unrepentant liar, braggart and trouble maker that most of the list has
> on ignore since the admins can't be bothered to do their job and kick him.

I'll ignore the slander ... but perhaps now it the time that I simply
cut my poor clients loose and leave it up to them to keep their websites
working. Certainly the amount of time wasted coping with CRAP windows
updates such as happened last week, the minefield these days of keeping
Linux servers actually working and the problems of prioritising just
where to spend the remaining time to just keep currently live sites
working leaves no time to do any NEW work! OH and the bastards in the US
who steal .com domains for porn crap and ICANN does nothing to protect
us from !!! At least non US controlled domains are honest when we PAY to
renew! Another job to waste time on this week :( So NO I DON'T NEED
STRICT TYING ... THE DATABASE INTERFACE TAKES CARE OF LIMITS AND VALUES
THAT int DOES TOTALLY NOTHING FOR !!!!

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Michael Morris
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
January 01, 2018 12:20PM
This was supposed to go to the list as well.

On Mon, Jan 1, 2018 at 6:15 AM Michael Morris <[email protected]> wrote:

> On Mon, Jan 1, 2018 at 6:01 AM Lester Caine <[email protected]> wrote:
>
>> On 31/12/17 22:45, Michael Morris wrote:
>> > Please do not quote large swaths of Tony Marston's crap. He's an
>> > unrepentant liar, braggart and trouble maker that most of the list has
>> > on ignore since the admins can't be bothered to do their job and kick
>> him.
>>
>> I'll ignore the slander ...
>>
>
> Before the admins come yelling at me over list rules I want to point out
> that was sent to you personally, not to the list as a whole.
>
> As for the rest of your reply, for both backwards compatibility and ease
> of learning reasons it is impossible to change PHP into a strongly typed
> language. No one has proposed that, at least not me. What I and several
> others have proposed is making strong typing available to those who want it
> in a manner that is backwards compatible. Argue against that if you must.
>
>>
>>
>>
Sorry, only registered users may post in this forum.

Click here to login