[RFC] Enum proposal (yet another)

14 years ago by Samuel Deal — view source — reply

unread

Hi all,

I really missed enums in PHP,
So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks

Samuel Déal
samuel.deal@gmail.com

14 years ago by Laruence — view source — reply

unread

Hi all,

I really missed enums in PHP,
Why? we have class constant.

thanks

So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks

Samuel Déal
samuel.deal@gmail.com

--
Laruence Xinchen Hui
http://www.laruence.com/

14 years ago by Charlie Somerville — view source — reply

unread

Right, but enums could possibly be a lot richer than class constants are
now.

They could be a type where the only values are what's defined in the enum.
This could be used with type hinting:

enum Foo {
    A,
    B,
    C
}

function bar(Foo $x) {
    // ...
}

There'd be no need to do any manual checking that $x is a valid value.

Perhaps enum values could also be casted back to strings:

(string)Foo::B; // "B"

Sure, this is the kind of stuff that's possible in other ways already, but
first class support always helps.

On Wed, Feb 22, 2012 at 12:45 PM, Samuel Deal samuel.deal@gmail.com
wrote:

Hi all,

I really missed enums in PHP,
Why? we have class constant.

thanks

So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks

Samuel Déal
samuel.deal@gmail.com

--
Laruence Xinchen Hui
http://www.laruence.com/

14 years ago by Sebastian Krebs — view source — reply

unread

2012/2/22 Charlie Somerville charlie@charliesomerville.com

Right, but enums could possibly be a lot richer than class constants are
now.

They could be a type where the only values are what's defined in the enum.
This could be used with type hinting:

enum Foo {
A,
B,
C
}

function bar(Foo $x) {
// ...
}

class MyEnum {
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this->value = $value;
}
public function __toString () { return $this->value; }
}

function doSomething (MyEnum $foo) { /* code */ }

What I wanted to say: I don't see, what is not possible already?

There'd be no need to do any manual checking that $x is a valid value.

Perhaps enum values could also be casted back to strings:

(string)Foo::B; // "B"

Sure, this is the kind of stuff that's possible in other ways already, but
first class support always helps.

On Wed, Feb 22, 2012 at 12:45 PM, Samuel Deal samuel.deal@gmail.com
wrote:

Hi all,

I really missed enums in PHP,
Why? we have class constant.

thanks

So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks

Samuel Déal
samuel.deal@gmail.com

--
Laruence Xinchen Hui
http://www.laruence.com/

14 years ago by Charlie Somerville — view source — reply

unread

My point is that although it's certainly possible to do almost everything I want already, I should not have to write all that boilerplate for each enum.

I would much prefer to write something like 'enum { A, B, C }' rather than write a full class for the enum, duplicate each enum value multiple times (your example repeats 'foo' and 'bar' three times each), overload the __toString() magic method, do manual error handling in the constructor, etc.

Since PHP provides no way to overload the equality operator, any solution that tries to emulate enums as Samuel or I have written about will be flawed.

2012/2/22 Charlie Somerville <charlie@charliesomerville.com (mailto:charlie@charliesomerville.com)>

Right, but enums could possibly be a lot richer than class constants are
now.

They could be a type where the only values are what's defined in the enum.
This could be used with type hinting:

enum Foo {
A,
B,
C
}

function bar(Foo $x) {
// ...
}

class MyEnum {
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this->value = $value;
}
public function __toString () { return $this->value; }
}

function doSomething (MyEnum $foo) { /* code */ }

What I wanted to say: I don't see, what is not possible already?

There'd be no need to do any manual checking that $x is a valid value.

Perhaps enum values could also be casted back to strings:

(string)Foo::B; // "B"

Sure, this is the kind of stuff that's possible in other ways already, but
first class support always helps.

On Wed, Feb 22, 2012 at 12:45 PM, Samuel Deal <samuel.deal@gmail.com (mailto:samuel.deal@gmail.com)>
wrote:

Hi all,

I really missed enums in PHP,
Why? we have class constant.

thanks

So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks

Samuel Déal
samuel.deal@gmail.com (mailto:samuel.deal@gmail.com)

--
Laruence Xinchen Hui
http://www.laruence.com/

14 years ago by keisial@gmail.com — view source — reply

unread

class MyEnum {
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this->value = $value;
}
public function __toString () { return $this->value; }
}

function doSomething (MyEnum $foo) { /* code */ }

What I wanted to say: I don't see, what is not possible already?

I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
not doSomething(new MyEnum(MyEnum::FOO));

+1 for adding enums (although I'm open to variations from that exact
proposal).

14 years ago by Nikita Popov — view source — reply

unread

What about SplEnum? (http://php.net/splenum)

It's part of the SPL types extension, but it could probably be also
moved to core.

Nikita

Hi all,

I really missed enums in PHP,
So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks

Samuel Déal
samuel.deal@gmail.com

14 years ago by Eitan Mosenkis — view source — reply

unread

I think that your proposal looks good, but I'd like to suggest a few
changes. First of all, I'd like to see the association with integers
removed. An enum instance shouldn't just be a name for an integer, it
should be more like a singleton instance of a special kind of class
that can only ever have a predefined set of named instances. There
should be no value associated with it.

Secondly, there already exists the capacity for arbitrary classes to
be used in foreach and count you just have to implement Iterator and
Countable. Other interfaces that all enums might want to implement
automatically are ArrayAccess and Serializable. This would just
require the enum itself to be an object (maybe of type enum or
something) such that it can implement the relevant methods.

http://www.php.net/manual/en/class.iterator.php
http://php.net/manual/en/class.countable.php

Hi all,

I really missed enums in PHP,
So after reading I tryed to synthetise the various views.

You can find a draft here :
https://github.com/SamNrique/php-src/wiki/RFC-draft
(I can't write on the wiki, and perhaps it's better to finish the
discussion first)

There's an implementation with this draft.
I'd love to have feedbacks because it's my first php-core hack.

Thanks

Samuel Déal
samuel.deal@gmail.com

14 years ago by Arvids Godjuks — view source — reply

unread

Hello, i should point out that it is all unicorns and rainbows for building
inernal apis and libraries. But in PHP you work with the world out there.
And that means you process GET, POST, xml, json and bunch of other data,
witch comes to you as text. Even db requests usually retirn text even with
numeric data. It all works great and easy now because PHP handles the
conversion, just have to check if the data is correct. So what will happen
with strict typing if i define an int and external data gives me a numeric
string? Or some ass tries to send me an array. Code just breaks into fatal
error? You can build a safe code that handles that, but if you write jist a
bunch of pretty strait forward scripts and you don't need all that complex
code with a framework type handling, sanitizing and so on.

Sure, inernal apis would be strictier and so on, but hell even now i think
it will make so much pain to make sure to convert all the data and params -
every db row, get params, xml data, etc. Duck typing is what makes php a
great tool for web development. And type hinting should be weak, trying to
convert data if is a now brainer and fail on real mistakes, like now
honting that you expect an array and a string is passed. But expecting an
int and passing a string containing int number should go smooth

14 years ago by John Crenshaw — view source — reply

unread

From: Arvids Godjuks [mailto:arvids.godjuks@gmail.com]

Hello, i should point out that it is all unicorns and rainbows for building inernal apis and libraries. But in PHP you work with the world out there.
And that means you process GET, POST, xml, json and bunch of other data, witch comes to you as text. Even db requests usually retirn text even with numeric data. It all works great and easy now because PHP handles the conversion, just have to check if the data is correct. So what will happen with strict typing if i define an int and external data gives me a numeric string? Or some ass tries to send me an array. Code just breaks into fatal error? You can build a safe code that handles that, but if you write jist a bunch of pretty strait forward scripts and you don't need all that complex code with a framework type handling, sanitizing and so on.

Sure, inernal apis would be strictier and so on, but hell even now i think it will make so much pain to make sure to convert all the data and params - every db row, get params, xml data, etc. Duck typing is what makes php a great tool for web development. And type hinting should be weak, trying to convert data if is a now brainer and fail on real mistakes, like now honting that you expect an array and a string is passed. But expecting an int and passing a string containing int number should go smooth

Nobody really wants typing as strict as what you are implying above. Even C++ (some of the strictest typing available) does implicit conversions where appropriate. All of the following should be perfectly valid:
(function(integer $n){})('1');
(function(string $s){})(1);
(function(float $f){})(1);
(function(integer $n){})(1.0);
(function(string $s){})(1);
(function(boolean $b){})($foo);
(function(string $s){})($some_object_with_a___tostring_magic_method);

As far as unconvertible inputs, here's the thing; most logic needs to know roughly what it is working with and only works with a limited range of valid inputs. For example, consider substr(), which will never make any sense unless you pass a string and an integer. If you try to call substr('foo', 'bar') it's going to have to fail, the only question is at what level and how. So called "strict typing" doesn't cause new errors, it gives structure to a ubiquitous set of existing error conditions.

John Crenshaw
Priacta, Inc.

14 years ago by Dmitri Snytkine — view source — reply

unread

For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum, and
why certain things are better with enums.

http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

I think enums will be beneficial to php, but will add one more features that
people not familiar with it will have to learn about.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Sebastian Krebs [mailto:krebs.seb@googlemail.com]
Sent: Wednesday, February 22, 2012 4:31 PM
To: PHP internals list
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Am 22.02.2012 22:22, schrieb Ángel González:

class MyEnum {
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this->value = $value;
}
public function __toString () { return $this->value; }
}

function doSomething (MyEnum $foo) { /* code */ }

What I wanted to say: I don't see, what is not possible already?

I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
not doSomething(new MyEnum(MyEnum::FOO));

// The class file
class MyEnum {
public static $FOO;
public static $BAR;
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this->value = $value;
}
public function __toString () { return $this->value; }
}
/* static code block */ {
// As long as PHP doesn't support "constant references" (;))
// (--> constants with objects or arrays)
MyEnum::$FOO = new MyEnum(MyEnum::FOO);
MyEnum::$BAR = new MyEnum(MyEnum::BAR);
}
// End class file

// Somewhere deep within some other code
doSomething (MyEnum::$FOO);

However, I can't see, what is the big thing, that isn't currently not
possible (except any "I want"-argumentation :X)

Sidenote, according your examples above on how you want call functions:
Considered using normal constants?

+1 for adding enums (although I'm open to variations from that exact
proposal).

14 years ago by Kris Craig — view source — reply

unread

While I'm a huge fan of Github, why did you decide to host your RFC there
instead of on the PHP wiki? I realize there's an older proposal there
right now, but that's from 2010 and seems to be dead in the water. Even if
yours is just a draft, the wiki is designed to be able to accommodate
progressive revisions.

I only mention this because I think it definitely helps to have one central
place where all the RFCs can be looked at, including the draft ones. At
very least, could you add a link to your RFC on the wiki page? I'd also
like to throw another idea out there: Should we consider amending the RFC
procedures to allow for expiration of old RFCs that have never been moved
to the voting stage? I was wondering because that older enum RFC is still
"Under Discussion" and last modified nearly a year ago; actually proposed
nearly 2 years ago. It seems to have been abandoned so I'm just curious if
maybe we should have some process in place to categorize that.

Regarding this particular RFC, personally I've never seen the need to use
enums, but it certainly does sound like something that would add
convenience and make that one less feature other languages have that PHP
doesn't. So I don't personally have any objection so long as the
implementation is solid.

--Kris

On Wed, Feb 22, 2012 at 1:43 PM, Dmitri Snytkine <
dsnytkine@ultralogistics.com> wrote:

For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum, and
why certain things are better with enums.

http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

I think enums will be beneficial to php, but will add one more features
that
people not familiar with it will have to learn about.

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Sebastian Krebs [mailto:krebs.seb@googlemail.com]
Sent: Wednesday, February 22, 2012 4:31 PM
To: PHP internals list
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Am 22.02.2012 22:22, schrieb Ángel González:

class MyEnum {
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this->value = $value;
}
public function __toString () { return $this->value; }
}

function doSomething (MyEnum $foo) { /* code */ }

What I wanted to say: I don't see, what is not possible already?

I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
not doSomething(new MyEnum(MyEnum::FOO));

// The class file
class MyEnum {
public static $FOO;
public static $BAR;
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedValueException;
$this->value = $value;
}
public function __toString () { return $this->value; }
}
/* static code block */ {
// As long as PHP doesn't support "constant references" (;))
// (--> constants with objects or arrays)
MyEnum::$FOO = new MyEnum(MyEnum::FOO);
MyEnum::$BAR = new MyEnum(MyEnum::BAR);
}
// End class file

// Somewhere deep within some other code
doSomething (MyEnum::$FOO);

However, I can't see, what is the big thing, that isn't currently not
possible (except any "I want"-argumentation :X)

Sidenote, according your examples above on how you want call functions:
Considered using normal constants?

+1 for adding enums (although I'm open to variations from that exact
proposal).

14 years ago by keisial@gmail.com — view source — reply

unread

While I'm a huge fan of Github, why did you decide to host your RFC there
instead of on the PHP wiki? (...)
Samuel doesn't have a wiki accout.
I agree he should get one and continue the proposal there.

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum, and
why certain things are better with enums.

http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

One note here: Java is a statically typed compiled language. PHP is not.
So many arguments regarding type safety, etc. which are completely valid
in regards to Java have no validity in regard to PHP. I understand that
some people want to import some bits from strictly typed languages,
imagining that this will provide them with benefits that statically
typed languages have, namely compile-time safety checks, etc. This does
not work as well in dynamic languages. Note for example that neither
Ruby nor Python have enums, though you can do similar things there.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

Sidenote, according your examples above on how you want call
functions: Considered using normal constants?
How can I do type hinting with them?

You should not. PHP is not a strictly typed language, so if you want
strictly typed function you'll get in trouble, for the same reasons why
strict scalar typing wasn't a good idea - you may want to re-read these
discussions.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Samuel Deal — view source — reply

unread

Hi !

First, thanks for all your replies.

I'll try to answer all questions, it'll be long.

#1. Should PHP have an enum implementation (not especially mine) ?

I think yes. We do not require it, there's nothing we can't do without.
However I think we need an intuitive and expressive syntax for this common
concept, a kind of syntax sugar, like "++" operator.

There's a lot of (beginners) php devs who tried to express this concept
with serialized constants or other ugly practices.
I don't say we must provide a language native structure for everything
those devs make bad, they need to learn.
Just, any devs I know, who came to PHP from another language, soon thought
"How can I emulate enums"

We do not have to copy other language; if someone has an expressive syntax
for a more advanced concept, I'm in.

Pros and cons:

expressiveness
performance for enum built-in functions

another keyword
(very very) little engine slowdown
work to do (but it could be a small hack, easy to maintains, and I'm ok
do it)

#2. Enum values should be objects or scalars ?

I choose scalars for several reasons:

more in "à la PHP" style, not strictly typed (but we can provide built-in
functions to do checks)
it's easier to communicate (to save into db, to retrieve from http post
queries, etc...)
serialization is faster an shorter
it's easier to migrate from existing PHP code based on class constant to
enum.
less memory consuming

I didn't see real drawbacks of using scalars instead of objects.
Except if you wanna have a really really strict typing.
( By strict typing I mean something like that:
myEnum::foo == 1 // => false
myEnum::foo == myEnum(1) // => true
)

#3. Enum values: int or string ? Do we need an explicit values syntax ?

I chose int, because:
Most of time, in our code, we would write enum names ("myEnum::foo").
Code would be expressive, with a shorter memory footprint.
You don't have to provide any value if you didn't need it.
Less often you'll need string representation, but you can easily get it
(in foreach or with enum built-in functions, myEnum::name($value) in my
proposal)

In addition, sometime you have to deal with other programs which required
numeric values.
In that case you can use explicit numeric values without writing a mapping
function?

Issues happened when you have to change the enum declaration, and have
somewhere (database, session, etc...) values stored you can't easily change.
If it's INT-based:
when you add or remove a value, you have to be careful not to change
auto-incremented values.
That's why providing an explicit value syntax is useful.
If it's STRING-based:
when a functionality is bad-named ("We agree about this, I won't change it"
-- the client --), you're stuck with this old name all over your code
forever.

#4. What's wrong with class constants ?

Nothing.
My proposal is only a syntactic sugar to declare, iterate and manipulate a
kind of class constants.

#5. What about SplEnum ?

I think it's a good alternative. If finally my RFC is rejected, I hope this
will be include in official php version.
But it's a strictly typed approach, and I prefer the other one (see #2)

#6. Why didn't you push this RFC on the wiki.

First, I had a lot of respect for work done, and I didn't want to override
previous RFC
Then, I'm new here, and there's no explanations in that situation in the
RFC about RFCs.
Finally, I don't have rights for that.

Tell me what you want me to do about this.

I hope I haven't forgotten a question.

Thanks for reading this long post.
Thanks for arguing.

Regards

Samuel DEAL
samuel.deal@gmail.com

14 years ago by keisial@gmail.com — view source — reply

unread

Hi!

Sidenote, according your examples above on how you want call
functions: Considered using normal constants?
How can I do type hinting with them?

You should not. PHP is not a strictly typed language, so if you want
strictly typed function you'll get in trouble, for the same reasons
why strict scalar typing wasn't a good idea - you may want to re-read
these discussions.
I disagree.
It is arguable whether having

enum Databases { MySQL, Postgres, Oracle }
enum Colors { Red, Green, Blue }

database_select(Colors::Red, $sql);

should give an error for a Databases type hint on the first parameter,
as it can be converted (that's a soft vs strict typing issue).

However, such typehint should avoid a call like:

database_select(1024, $sql);

with which the function can't do anything sensible with (other than
returning an error if it does its own checking).

Best regards

14 years ago by Dmitri Snytkine — view source — reply

unread

True but it will have with type hinting, making code more 'bullet proof'

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Wednesday, February 22, 2012 6:07 PM
To: Dmitri Snytkine
Cc: 'Sebastian Krebs'; 'PHP internals list'
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Hi!

For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum,
and
why certain things are better with enums.

http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

One note here: Java is a statically typed compiled language. PHP is not.
So many arguments regarding type safety, etc. which are completely valid
in regards to Java have no validity in regard to PHP. I understand that
some people want to import some bits from strictly typed languages,
imagining that this will provide them with benefits that statically
typed languages have, namely compile-time safety checks, etc. This does
not work as well in dynamic languages. Note for example that neither
Ruby nor Python have enums, though you can do similar things there.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Anthony Ferrara — view source — reply

unread

If you're going to go that far, why not make a flyweight enum type?
(Basically what's described here: http://c2.com/cgi/wiki?FlyweightEnum
)...

Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit). If you used a flyweight, you could literally type-hint.

It's 100% possible right now to do it that way, as demonstrated here:
https://gist.github.com/1893073

But with the lack of const object references, we have to resort to a
few dirty tricks (such as using __callStatic). Additionally, it
requires hard-coding the values in two places (one as a class, and the
other as the reference in the new lines).

It also has the benefit of working with the object system that is already built.

Perhaps it would be worth while adding syntactic sugar to the parser
to convert the enum declaration into something like this, so that the
changes would be localized...

enum MyEnum {
MyFirstValue,
MySecondValue,
MyThirdValue
}

Which would then be converted into basically what I have in that gist,
a class internally which would then work with traditional OO system to
produce the flyweight enum for us (so we wouldn't have to write all
that boiler plate every time we wanted an enum)...

Just a thought...

Anthony

On Thu, Feb 23, 2012 at 8:39 AM, Dmitri Snytkine
dsnytkine@ultralogistics.com wrote:

True but it will have with type hinting, making code more 'bullet proof'

Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Wednesday, February 22, 2012 6:07 PM
To: Dmitri Snytkine
Cc: 'Sebastian Krebs'; 'PHP internals list'
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Hi!

For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum,
and
why certain things are better with enums.

http://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html

One note here: Java is a statically typed compiled language. PHP is not.
So many arguments regarding type safety, etc. which are completely valid
in regards to Java have no validity in regard to PHP. I understand that
some people want to import some bits from strictly typed languages,
imagining that this will provide them with benefits that statically
typed languages have, namely compile-time safety checks, etc. This does
not work as well in dynamic languages. Note for example that neither
Ruby nor Python have enums, though you can do similar things there.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

If you're going to go that far, why not make a flyweight enum type?
(Basically what's described here: http://c2.com/cgi/wiki?FlyweightEnum
)...

Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit). If you used a flyweight, you could literally type-hint.

Again, it looks like you are trying to introduce strict typing into PHP.
I do not think it's a good idea, for the reasons I described at length
in previous discussions, but you're free to try.
However, I don't see how changing the language to make it easier to do
partial backdoor strict typing is a good idea. Bringing Java as an
example only supports this point.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Kris Craig — view source — reply

unread

Hmm I think Stas makes a good point. One of the allures of PHP,
particularly for web developers without any programming experience, is its
flexibility. Strict typing would certainly negate that.

If I may be so bold, should we perhaps expand the scope of this discussion
to address the larger question of whether or not strict typing should be
introduced into PHP, and if so, in what form and to what extent? It seems
to me that we must answer that question before we can answer the enum one.

Specifically, these are the questions that come to mind:

Is strict typing something that we should seriously consider
implementing at some point in the foreseeable future?
If "yes", should it be an "always on" type of thing or a toggleable
thing?
If toggleable, should this be defined at the config level, the script
level, or both?
Depending on your answers to 1 - 3, what would be the advantages to
this approach?
Depending on your answers to 1 - 3, what would be the disadvantages
to this approach?

If y'all wouldn't mind humoring me, would you be willing to send your
answers to these questions in your next reply? I think it would help us to
bring some objective clarity to this issue as well as guage what the
current consensus is, if there is one.

As such, here are the answers that come to my mind:

Yes, I think the idea has enough merit for further consideration.
Definitely toggleable! It would probably have to be "off" by default
for the sake of backwards compatibility.
I'm not sure, but my inclination would be both. Perhaps an INI value
that can easily be set at the script level, similar to max_execution_time.
Advantages:
- Strictly-typed code is much easier to read and follow.
- Programmers experienced in other languages like C# and Java would
  find PHP much more appealing.
- It would allow for much more simplified code with fewer sanity
  checks at the script-level.
  - For example, I've been working on a Drupal-based project that
    was written by another person (it's work-related so I'm distorting the
    details so as not to breach the NDA). This person had the
    annoying habit
    of "sending" variables (JSON-encoded/decoded from a remote
    hub that he also
    wrote) with inconsistent types. For example, the "progress"
    key could be a
    multidimensional array, a string, NULL, a boolean, and in one
    rare case
    even an object pointer. But MOST of the time, it's an array,
    and the way
    the architecture is setup, there's no way to anticipate what
    type it will
    be except to test for it. So, rather than simply being able
    to check for
    something like, $progress["percent"], I instead have to do a
    ton of sanity
    checks to first make sure it's the type of variable I'm
    looking for at any
    particular moment.
- Frequently requested features, like enums, would no longer be
  impractical.
- Seasoned PHP developers who want to venture into compiled
  programming languages could first enable strict typing as a
  stepping stone,
  reducing the learning curve.
Disadvantages:
- It would probably be a fairly large undertaking to implement.
- This could result in a sort of pseudo-parallel set of languages
  emerging within PHP core, since some things, like enums, would presumably
  be dependent upon strict typing being enabled.
- Though it would allow for simpler, easier to follow code, it
  probably(?) wouldn't actually add any practical functionality in terms of
  what PHP can actually do that it doesn't have already in other
  forms.

Those are my thoughts. It's too early for me to draw any conclusions on
whether this should be implemented or not. I'd like to see what the rest
of you have to say on the subject.

If you wouldn't mind jumping through my hoops and answering the above
questions as I just did, I think that would help us all to quantify this
from different angles and arrive at a much clearer understanding as to the
implications involved. =)

--Kris

On Thu, Feb 23, 2012 at 10:34 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

If you're going to go that far, why not make a flyweight enum type?

(Basically what's described here: http://c2.com/cgi/wiki?**FlyweightEnum http://c2.com/cgi/wiki?FlyweightEnum
)...

Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit). If you used a flyweight, you could literally type-hint.

Again, it looks like you are trying to introduce strict typing into PHP. I
do not think it's a good idea, for the reasons I described at length in
previous discussions, but you're free to try.
However, I don't see how changing the language to make it easier to do
partial backdoor strict typing is a good idea. Bringing Java as an example
only supports this point.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by John LeSueur — view source — reply

unread

Previous discussions have covered the probability that strict typing and
dynamic typing can't coexist, because strict typing ends up pushing itself
further up the call tree. An ini setting to change from one to the other
will not solve that problem. Not sure that it says anything about enums,
but strict vs. dynamic typing is a hot topic that probably won't get any
agreement here. The previous discussions are just too recent, and it's not
likely anyone has changed their mind.

Hmm I think Stas makes a good point. One of the allures of PHP,
particularly for web developers without any programming experience, is its
flexibility. Strict typing would certainly negate that.

If I may be so bold, should we perhaps expand the scope of this discussion
to address the larger question of whether or not strict typing should be
introduced into PHP, and if so, in what form and to what extent? It seems
to me that we must answer that question before we can answer the enum one.

Specifically, these are the questions that come to mind:

Is strict typing something that we should seriously consider
implementing at some point in the foreseeable future?

If "yes", should it be an "always on" type of thing or a toggleable
thing?

If toggleable, should this be defined at the config level, the script
level, or both?

Depending on your answers to 1 - 3, what would be the advantages to
this approach?

Depending on your answers to 1 - 3, what would be the disadvantages
to this approach?

If y'all wouldn't mind humoring me, would you be willing to send your
answers to these questions in your next reply? I think it would help us to
bring some objective clarity to this issue as well as guage what the
current consensus is, if there is one.

As such, here are the answers that come to my mind:

Yes, I think the idea has enough merit for further consideration.

Definitely toggleable! It would probably have to be "off" by default
for the sake of backwards compatibility.

I'm not sure, but my inclination would be both. Perhaps an INI value
that can easily be set at the script level, similar to
max_execution_time.

Advantages:

Strictly-typed code is much easier to read and follow.

Programmers experienced in other languages like C# and Java would
find PHP much more appealing.

It would allow for much more simplified code with fewer sanity
checks at the script-level.

For example, I've been working on a Drupal-based project that
was written by another person (it's work-related so I'm distorting
the
details so as not to breach the NDA). This person had the
annoying habit
of "sending" variables (JSON-encoded/decoded from a remote
hub that he also
wrote) with inconsistent types. For example, the "progress"
key could be a
multidimensional array, a string, NULL, a boolean, and in one
rare case
even an object pointer. But MOST of the time, it's an array,
and the way
the architecture is setup, there's no way to anticipate what
type it will
be except to test for it. So, rather than simply being able
to check for
something like, $progress["percent"], I instead have to do a
ton of sanity
checks to first make sure it's the type of variable I'm
looking for at any
particular moment.

Frequently requested features, like enums, would no longer be
impractical.

Seasoned PHP developers who want to venture into compiled
programming languages could first enable strict typing as a
stepping stone,
reducing the learning curve.

Disadvantages:

It would probably be a fairly large undertaking to implement.

This could result in a sort of pseudo-parallel set of languages
emerging within PHP core, since some things, like enums, would
presumably
be dependent upon strict typing being enabled.

Though it would allow for simpler, easier to follow code, it
probably(?) wouldn't actually add any practical functionality in
terms of
what PHP can actually do that it doesn't have already in other
forms.

Those are my thoughts. It's too early for me to draw any conclusions on
whether this should be implemented or not. I'd like to see what the rest
of you have to say on the subject.

If you wouldn't mind jumping through my hoops and answering the above
questions as I just did, I think that would help us all to quantify this
from different angles and arrive at a much clearer understanding as to the
implications involved. =)

--Kris

On Thu, Feb 23, 2012 at 10:34 AM, Stas Malyshev <smalyshev@sugarcrm.com

wrote:

Hi!

If you're going to go that far, why not make a flyweight enum type?

(Basically what's described here:
http://c2.com/cgi/wiki?**FlyweightEnum<;
http://c2.com/cgi/wiki?FlyweightEnum>;
)...

Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit). If you used a flyweight, you could literally type-hint.

Again, it looks like you are trying to introduce strict typing into PHP.
I
do not think it's a good idea, for the reasons I described at length in
previous discussions, but you're free to try.
However, I don't see how changing the language to make it easier to do
partial backdoor strict typing is a good idea. Bringing Java as an
example
only supports this point.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Kris Craig — view source — reply

unread

Could you elaborate on this? So long as that setting cannot be changed
midway through a script or its includes (i.e. the stack must be "all
strict" or "all dynamic"), I can't think of any reason why that would not
be feasible.

At some point, it probably wouldn't hurt for us to at least start thinking
about what will be going into PHP 6. Seems to me that something
fundamental like this would be an appropriate starting point, much like the
shift from procedural to OO focus largely defined PHP 5.

--Kris

On Thu, Feb 23, 2012 at 11:37 AM, John LeSueur john.lesueur@gmail.comwrote:

Previous discussions have covered the probability that strict typing and
dynamic typing can't coexist, because strict typing ends up pushing itself
further up the call tree. An ini setting to change from one to the other
will not solve that problem. Not sure that it says anything about enums,
but strict vs. dynamic typing is a hot topic that probably won't get any
agreement here. The previous discussions are just too recent, and it's not
likely anyone has changed their mind.

Hmm I think Stas makes a good point. One of the allures of PHP,
particularly for web developers without any programming experience, is its
flexibility. Strict typing would certainly negate that.

If I may be so bold, should we perhaps expand the scope of this discussion
to address the larger question of whether or not strict typing should be
introduced into PHP, and if so, in what form and to what extent? It seems
to me that we must answer that question before we can answer the enum one.

Specifically, these are the questions that come to mind:

Is strict typing something that we should seriously consider

implementing at some point in the foreseeable future?

If "yes", should it be an "always on" type of thing or a toggleable
thing?

If toggleable, should this be defined at the config level, the script
level, or both?

Depending on your answers to 1 - 3, what would be the advantages to
this approach?

Depending on your answers to 1 - 3, what would be the disadvantages

to this approach?

If y'all wouldn't mind humoring me, would you be willing to send your
answers to these questions in your next reply? I think it would help us
to
bring some objective clarity to this issue as well as guage what the
current consensus is, if there is one.

As such, here are the answers that come to my mind:

Yes, I think the idea has enough merit for further consideration.

Definitely toggleable! It would probably have to be "off" by default

for the sake of backwards compatibility.

I'm not sure, but my inclination would be both. Perhaps an INI value

that can easily be set at the script level, similar to
max_execution_time.

Advantages:

Strictly-typed code is much easier to read and follow.

Programmers experienced in other languages like C# and Java would

find PHP much more appealing.

It would allow for much more simplified code with fewer sanity
checks at the script-level.

For example, I've been working on a Drupal-based project that

was written by another person (it's work-related so I'm
distorting the
details so as not to breach the NDA). This person had the
annoying habit
of "sending" variables (JSON-encoded/decoded from a remote
hub that he also
wrote) with inconsistent types. For example, the "progress"
key could be a
multidimensional array, a string, NULL, a boolean, and in one
rare case
even an object pointer. But MOST of the time, it's an array,
and the way
the architecture is setup, there's no way to anticipate what
type it will
be except to test for it. So, rather than simply being able
to check for
something like, $progress["percent"], I instead have to do a
ton of sanity
checks to first make sure it's the type of variable I'm
looking for at any
particular moment.

Frequently requested features, like enums, would no longer be
impractical.

Seasoned PHP developers who want to venture into compiled

programming languages could first enable strict typing as a
stepping stone,
reducing the learning curve.

Disadvantages:

It would probably be a fairly large undertaking to implement.

This could result in a sort of pseudo-parallel set of languages

emerging within PHP core, since some things, like enums, would
presumably
be dependent upon strict typing being enabled.

Though it would allow for simpler, easier to follow code, it

probably(?) wouldn't actually add any practical functionality in
terms of
what PHP can actually do that it doesn't have already in other

forms.

Those are my thoughts. It's too early for me to draw any conclusions on
whether this should be implemented or not. I'd like to see what the rest
of you have to say on the subject.

If you wouldn't mind jumping through my hoops and answering the above
questions as I just did, I think that would help us all to quantify this
from different angles and arrive at a much clearer understanding as to the
implications involved. =)

--Kris

On Thu, Feb 23, 2012 at 10:34 AM, Stas Malyshev <smalyshev@sugarcrm.com

wrote:

Hi!

If you're going to go that far, why not make a flyweight enum type?

(Basically what's described here:
http://c2.com/cgi/wiki?**FlyweightEnum<;
http://c2.com/cgi/wiki?FlyweightEnum>;

)...

Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit). If you used a flyweight, you could literally type-hint.

Again, it looks like you are trying to introduce strict typing into
PHP. I
do not think it's a good idea, for the reasons I described at length in
previous discussions, but you're free to try.
However, I don't see how changing the language to make it easier to do
partial backdoor strict typing is a good idea. Bringing Java as an
example
only supports this point.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by keisial@gmail.com — view source — reply

unread

Could you elaborate on this? So long as that setting cannot be changed
midway through a script or its includes (i.e. the stack must be "all
strict" or "all dynamic"), I can't think of any reason why that would not
be feasible.

--Kris
I'm afraid that would create a split between code-for-config-A and
code-for-config-B.

14 years ago by Kris Craig — view source — reply

unread

Yeah I agree, that was one of the things I listed under "disadvantages" lol.

I guess my question is: Does this constitute a prohibitive problem, or is
it something that we can stomach?

I mean, if you think about it, that's really what we're talking about
anyway, right? After all, when you're writing any application, you're
either going to be writing it with strict typing or you're going to be
writing it with dynamic typing. The only difference here is that coders
with either preference will both find PHP accommodating to their style.

Similarly, a somewhat weaker argument could be made that, in PHP 5, you're
either coding for procedural design or for OO design (technically you could
do both, but I wouldn't wanna touch that codebase with a ten foot poll
lol). The only difference here is that there would be a config setting to
tell the interpreter which is which.

--Kris

2012/2/23 Ángel González keisial@gmail.com

Could you elaborate on this? So long as that setting cannot be changed
midway through a script or its includes (i.e. the stack must be "all
strict" or "all dynamic"), I can't think of any reason why that would not
be feasible.

--Kris
I'm afraid that would create a split between code-for-config-A and
code-for-config-B.

14 years ago by Matti Bickel — view source — reply

unread

[dynamic vs strict typing via config setting]

Yeah I agree, that was one of the things I listed under "disadvantages" lol.

I guess my question is: Does this constitute a prohibitive problem, or is
it something that we can stomach?

As a user of PHP: this would be totally confusing. To be honest that
feels like asking Haskell to become procedural on the push of a button.
It's a switch of paradigma. If I wanted that, I'd choose another language.

Also: what the last RFC on type checking
(https://wiki.php.net/rfc/typechecking and the ml) said.

14 years ago by keisial@gmail.com — view source — reply

unread

Yeah I agree, that was one of the things I listed under
"disadvantages" lol.

I guess my question is: Does this constitute a prohibitive problem,
or is it something that we can stomach?

I mean, if you think about it, that's really what we're talking about
anyway, right? After all, when you're writing any application, you're
either going to be writing it with strict typing or you're going to be
writing it with dynamic typing. The only difference here is that
coders with either preference will both find PHP accommodating to
their style.

Similarly, a somewhat weaker argument could be made that, in PHP 5,
you're either coding for procedural design or for OO design
(technically you could do both, but I wouldn't wanna touch that
codebase with a ten foot poll lol). The only difference here is that
there would be a config setting to tell the interpreter which is which.

--Kris
I think you would get developers coding for strict, and hostings set to
weak. Makes more sense to have it as a per file / per function
attribute, so the author can choose if they want the values passed to it
to be coerced or act as if they were doing a manual check and throwing
an exception.

14 years ago by Kris Craig — view source — reply

unread

Hmm that's a fascinating idea! So, and please correct me if I'm wrong,
you're saying that it might be a better approach to determine strict vs.
dynamic typing on a per file or function basis instead of on a per stack
basis? In other words, blah.php could contain two functions, one using
strict typing and the other using traditional dynamic typing?

Theoretically, I think that approach could work. Perhaps we'd have it
specified in the function declaration itself; i.e. "function whatever(
$text, $number )" would be a traditional, dynamically-typed PHP function,
whereas "strict function whatever( string $text, int $number )" would use
strict typing.

The obvious question then would be, what if dynamic function A makes a call
to dynamic function B, passing to it a dynamically-typed variable? There
are three viable approaches that come to mind: This count not be allowed;
this could be allowed but only if the variables being passed to function B
are cast first (i.e. B( (string) $text, (int) $number );); or, this could
be allowed without casting, in which case PHP would attempt to pass the
variable and then throw an exception if it cannot be parsed as the required
type. Personally, my vote would be for Option 2.

I know this would be potentially confusing to people who are used to the
existing language structure, but it's also worth noting that PHP has
already changed quite a bit over the years and we've all managed to adapt.
I'm thinking this would be perfect for PHP 6, since it would not be at all
unreasonable to assume that there would be significant language changes
that might require a slight learning curve at first, just as PHP 4 and 5
did.

This is perhaps the most common complaint I hear about PHP. There are many
programmers out there who think we're out of our minds (or just plain lazy)
for not acting on this. I'm not one of them, mind you, but I can certainly
see why they'd think that looking from the outside. I think it would be
really awesome if we decided to finally tackle this head-on, despite the
obvious discomfort that it would bring in the short-term; though I think
much of that could be mitigated if we simply targetted this for PHP 6.

--Kris

2012/2/23 Ángel González keisial@gmail.com

Yeah I agree, that was one of the things I listed under
"disadvantages" lol.

I guess my question is: Does this constitute a prohibitive problem,
or is it something that we can stomach?

I mean, if you think about it, that's really what we're talking about
anyway, right? After all, when you're writing any application, you're
either going to be writing it with strict typing or you're going to be
writing it with dynamic typing. The only difference here is that
coders with either preference will both find PHP accommodating to
their style.

Similarly, a somewhat weaker argument could be made that, in PHP 5,
you're either coding for procedural design or for OO design
(technically you could do both, but I wouldn't wanna touch that
codebase with a ten foot poll lol). The only difference here is that
there would be a config setting to tell the interpreter which is which.

--Kris
I think you would get developers coding for strict, and hostings set to
weak. Makes more sense to have it as a per file / per function
attribute, so the author can choose if they want the values passed to it
to be coerced or act as if they were doing a manual check and throwing
an exception.

14 years ago by Kris Craig — view source — reply

unread

Err typo correction: In my "what if" scenario, I meant to say, "what if
dynamic function A makes a call to static function B".

--Kris

2012/2/23 Kris Craig kris.craig@gmail.com

Hmm that's a fascinating idea! So, and please correct me if I'm wrong,
you're saying that it might be a better approach to determine strict vs.
dynamic typing on a per file or function basis instead of on a per stack
basis? In other words, blah.php could contain two functions, one using
strict typing and the other using traditional dynamic typing?

Theoretically, I think that approach could work. Perhaps we'd have it
specified in the function declaration itself; i.e. "function whatever(
$text, $number )" would be a traditional, dynamically-typed PHP function,
whereas "strict function whatever( string $text, int $number )" would use
strict typing.

The obvious question then would be, what if dynamic function A makes a
call to dynamic function B, passing to it a dynamically-typed variable?
There are three viable approaches that come to mind: This count not be
allowed; this could be allowed but only if the variables being passed to
function B are cast first (i.e. B( (string) $text, (int) $number );); or,
this could be allowed without casting, in which case PHP would attempt to
pass the variable and then throw an exception if it cannot be parsed as the
required type. Personally, my vote would be for Option 2.

I know this would be potentially confusing to people who are used to the
existing language structure, but it's also worth noting that PHP has
already changed quite a bit over the years and we've all managed to adapt.
I'm thinking this would be perfect for PHP 6, since it would not be at all
unreasonable to assume that there would be significant language changes
that might require a slight learning curve at first, just as PHP 4 and 5
did.

This is perhaps the most common complaint I hear about PHP. There are
many programmers out there who think we're out of our minds (or just plain
lazy) for not acting on this. I'm not one of them, mind you, but I can
certainly see why they'd think that looking from the outside. I think it
would be really awesome if we decided to finally tackle this head-on,
despite the obvious discomfort that it would bring in the short-term;
though I think much of that could be mitigated if we simply targetted this
for PHP 6.

--Kris

2012/2/23 Ángel González keisial@gmail.com

Yeah I agree, that was one of the things I listed under
"disadvantages" lol.

I guess my question is: Does this constitute a prohibitive problem,
or is it something that we can stomach?

I mean, if you think about it, that's really what we're talking about
anyway, right? After all, when you're writing any application, you're
either going to be writing it with strict typing or you're going to be
writing it with dynamic typing. The only difference here is that
coders with either preference will both find PHP accommodating to
their style.

Similarly, a somewhat weaker argument could be made that, in PHP 5,
you're either coding for procedural design or for OO design
(technically you could do both, but I wouldn't wanna touch that
codebase with a ten foot poll lol). The only difference here is that
there would be a config setting to tell the interpreter which is which.

--Kris
I think you would get developers coding for strict, and hostings set to
weak. Makes more sense to have it as a per file / per function
attribute, so the author can choose if they want the values passed to it
to be coerced or act as if they were doing a manual check and throwing
an exception.

14 years ago by keisial@gmail.com — view source — reply

unread

Hmm that's a fascinating idea! So, and please correct me if I'm
wrong, you're saying that it might be a better approach to determine
strict vs. dynamic typing on a per file or function basis instead of
on a per stack basis? In other words, blah.php could contain two
functions, one using strict typing and the other using traditional
dynamic typing?
Yes. Two functions in the same file with different conventions may be a
strange use case, I'd expect differences to come from eg. using two
libraries, each with different typing.

Theoretically, I think that approach could work. Perhaps we'd have it
specified in the function declaration itself; i.e. "function whatever(
$text, $number )" would be a traditional, dynamically-typed PHP
function, whereas "strict function whatever( string $text, int $number
)" would use strict typing.
I'm not keen with that syntax, but that could be discussed. I remember
something similar was already mentioned in another types thread, with
ideasl like string! or string? to mark the types as strict or weak.

The obvious question then would be, what if dynamic function A makes a
call to dynamic function B, passing to it a dynamically-typed
variable? There are three viable approaches that come to mind: This
count not be allowed; this could be allowed but only if the variables
being passed to function B are cast first (i.e. B( (string) $text,
(int) $number );); or, this could be allowed without casting, in which
case PHP would attempt to pass the variable and then throw an
exception if it cannot be parsed as the required type. Personally, my
vote would be for Option 2.
I was envisioning it just as an interface for the call. Thus, if funtion
A used strict or dynamic types would be irrelevant. You seem to be
bringing up another option however, which is that funcion A could
specify the behavior on functions it calls.
It can look appealing, but I don't think that's desirable. After all,
it's the callee interface what is important, not the kind of caller (you
could have a setting to force an stricter behavior, but that seems more
appropiate for an extension, like xdebug scream option).

14 years ago by Kris Craig — view source — reply

unread

Could you elaborate on that a little? I.e. "as an interface for the
call". I'm not sure what you mean by that. If you could provide a quick
example, that would be awesome! =)

--Kris

2012/2/24 Ángel González keisial@gmail.com

Hmm that's a fascinating idea! So, and please correct me if I'm
wrong, you're saying that it might be a better approach to determine
strict vs. dynamic typing on a per file or function basis instead of
on a per stack basis? In other words, blah.php could contain two
functions, one using strict typing and the other using traditional
dynamic typing?
Yes. Two functions in the same file with different conventions may be a
strange use case, I'd expect differences to come from eg. using two
libraries, each with different typing.

Theoretically, I think that approach could work. Perhaps we'd have it
specified in the function declaration itself; i.e. "function whatever(
$text, $number )" would be a traditional, dynamically-typed PHP
function, whereas "strict function whatever( string $text, int $number
)" would use strict typing.
I'm not keen with that syntax, but that could be discussed. I remember
something similar was already mentioned in another types thread, with
ideasl like string! or string? to mark the types as strict or weak.

The obvious question then would be, what if dynamic function A makes a
call to dynamic function B, passing to it a dynamically-typed
variable? There are three viable approaches that come to mind: This
count not be allowed; this could be allowed but only if the variables
being passed to function B are cast first (i.e. B( (string) $text,
(int) $number );); or, this could be allowed without casting, in which
case PHP would attempt to pass the variable and then throw an
exception if it cannot be parsed as the required type. Personally, my
vote would be for Option 2.
I was envisioning it just as an interface for the call. Thus, if funtion
A used strict or dynamic types would be irrelevant. You seem to be
bringing up another option however, which is that funcion A could
specify the behavior on functions it calls.
It can look appealing, but I don't think that's desirable. After all,
it's the callee interface what is important, not the kind of caller (you
could have a setting to force an stricter behavior, but that seems more
appropiate for an extension, like xdebug scream option).

14 years ago by Richard Lynch — view source — reply

unread

Is strict typing something that we should seriously consider
implementing at some point in the foreseeable future?

No.

If you want that, PHP is not the language for you, so just go use Java
and JSP.

I'm not being rude nor abusive: If anyone dislikes the way PHP works
at such a fundamental layer, they just shouldn't use it.

If toggleable, should this be defined at the config level, the
script
level, or both?

God no.

The insanity of dozens upon dozens of php.ini settings make
portability difficult enough already.

     of "sending" variables (JSON-encoded/decoded from a remote
hub that he also
wrote) with inconsistent types. For example, the "progress"
key could be a
multidimensional array, a string, NULL, a boolean, and in one
rare case
even an object pointer. But MOST of the time, it's an array,

switch (true){
case is_array($input): break;
case is_null($input): break;
case is_boolean($input): break;
case is_string($input): break;
default:
//There is no object pointer in PHP, so I dunno what you are
talking about...
break;
}

Was that really that tricky?

  - It would probably be a fairly large undertaking to implement.

Monstrously large.
But feel free to try it yourself. :-)

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

14 years ago by Lester Caine — view source — reply

unread

Richard Lynch wrote:

1. Is strict typing something that we should seriously consider
 implementing at some point in the foreseeable future?
No.

If you want that, PHP is not the language for you, so just go use Java
and JSP.

I'm not being rude nor abusive: If anyone dislikes the way PHP works
at such a fundamental layer, they just shouldn't use it.

Well said ....

--
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//
Firebird - http://www.firebirdsql.org/index.php

14 years ago by John Crenshaw — view source — reply

unread

-----Original Message-----
From: Lester Caine [mailto:lester@lsces.co.uk]

Richard Lynch wrote:
1. Is strict typing something that we should seriously consider
 implementing at some point in the foreseeable future?
No.

If you want that, PHP is not the language for you, so just go use Java
and JSP.

I'm not being rude nor abusive: If anyone dislikes the way PHP works
at such a fundamental layer, they just shouldn't use it.
Well said ....

--
Lester Caine - G8HFL

No, not really. This sort of attitude brings nothing to the table and leaves no room for level minded negotiation. It simply derides anyone who thinks differently in an attempt to bully other people into giving you your way. Claiming "I'm not being rude or abusive" doesn't make the comments any less so.

John Crenshaw
Priacta, Inc.

14 years ago by Kris Craig — view source — reply

unread

Woops that was a typo lol. I meant to put "and a" between the two.

I hear that a lot; i.e. "If you want static typing, use Java."

Unfortunately, that dismissive answer has not worked too well over the
years, has it? People are still clamoring for this, and I think making
some very valid arguments that shouldn't be so derisively and flippantly
brushed aside.

Besides, I don't see any rule listed anywhere that says PHP has to be a
pure dynamically-typed language. People have made some very viable
arguments as to why this would be beneficial. Your "but PHP doesn't
currently do this so screw it" rebuttal really doesn't add anything to the
discussion, IMHO. I'm not being rude or abusive: If anyone thinks PHP is
carved in stone and can never be changed or evolved, they just shouldn't
work on developing it. ;P

So no, sorry, but I don't think that's a valid argument. Your other
arguments do have merit, and some alternatives have already been floated to
address them. But the whole, "If you don't like it then just get the hell
out and use Java instead," attitude carries ZERO weight with me. =)

--Kris

Is strict typing something that we should seriously consider
implementing at some point in the foreseeable future?

No.

If you want that, PHP is not the language for you, so just go use Java
and JSP.

I'm not being rude nor abusive: If anyone dislikes the way PHP works
at such a fundamental layer, they just shouldn't use it.

If toggleable, should this be defined at the config level, the
script
level, or both?

God no.

The insanity of dozens upon dozens of php.ini settings make
portability difficult enough already.
     of "sending" variables (JSON-encoded/decoded from a remote
hub that he also
wrote) with inconsistent types. For example, the "progress"
key could be a
multidimensional array, a string, NULL, a boolean, and in one
rare case
even an object pointer. But MOST of the time, it's an array,
switch (true){
case is_array($input): break;
case is_null($input): break;
case is_boolean($input): break;
case is_string($input): break;
default:
//There is no object pointer in PHP, so I dunno what you are
talking about...
break;
}

Was that really that tricky?
  - It would probably be a fairly large undertaking to implement.
Monstrously large.
But feel free to try it yourself. :-)

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:

https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

14 years ago by Samuel Deal — view source — reply

unread

Hi,

Going to Strict tying it's really a major paradign shift.

To clarify my talk, When I say "strict typing", I'm talking about strict
scalar check, variable definition or return type check.
I'm ok with weak scalar type hinting.

We have type hinting, yes, but it's a kind of syntaxtic sugar for :
if(! arg1 instanceof MyClass){
throw new exception("How are you using my work ?!!");
}
Any check we make slow our execution time.
Before type hinting exists, we performed manualy this check, and it was
verbose and slower than same check done by PHP native code.

PHP is a script language. No compilation pass.
In all cases, because someone made a bad use of a function, it will break
at execution time.
So type hinting and strict typing will not make our code safer or faster.

We don't have to be ashamed of using a script language.
Thanks to this, we can do metaprogramming.
for instance, __call() allow us to do really awesome things
If we look at other script languages, Python, Ruby, Perl or Javascript
doesn't have srtict typing nor type hinting.

I love static languages.
I write code in C, C++, Java, As3 and C#.
They have good performance, stric typing, static checks at compilation time.
But it's a different technology, and their philosophy is allowed only
because there's a compilation phase.

That's why when facebook, with HHVM, tryied to make a faster PHP, it can
only work with a subset of what is realy PHP.
For this reason, it's really really difficult to make javascript a fast
language (v8 and sipermonkey are very complex).
For the same reason, now Adobe decide to give up with the dynamic part of
ActionScript (wich was limited compared to PHP) to speed up their VM.

So I think going to scrict typing only make sense if we want a static
language, with compilation phase and performances gains due.
But it would be more than a major compatibility.
A lot of things will be not only be broken, but will be impossible.

Finally, it would be a so big engine change that it would be better to
restart the engine from scratch.
And if we start from scratch without backward compatibility, is this still
PHP ?

And is there a language which already works as expected? Java ?

Just my 0.02$

--
Samuel DEAL
samuel.deal@gmail.com

14 years ago by Kris Craig — view source — reply

unread

There are advantages to strict typing other than speed and safety. The
biggest compliant I hear from people asking for this is that weak hinting
often leads to bulkier code that is much more difficult to read,
particularly for someone who frequently switches between PHP and compiled
languages like C++ and C#.

Therefore, allowing for strict typing, i.e. leaving it to the discretion of
the code author, would not necessitate converting PHP into a compiled
language or require anything close to a fundamental rewrite. Furthermore,
it would allow for 100% backwards compatibility with existing code. This
would essentially make PHP more flexible, not less. We'd simply be adding
a new dimension to it that has been overwhelmingly requested from the
outside for many years.

--Kris

Hi,

Going to Strict tying it's really a major paradign shift.

To clarify my talk, When I say "strict typing", I'm talking about strict
scalar check, variable definition or return type check.
I'm ok with weak scalar type hinting.

We have type hinting, yes, but it's a kind of syntaxtic sugar for :
if(! arg1 instanceof MyClass){
throw new exception("How are you using my work ?!!");
}
Any check we make slow our execution time.
Before type hinting exists, we performed manualy this check, and it was
verbose and slower than same check done by PHP native code.

PHP is a script language. No compilation pass.
In all cases, because someone made a bad use of a function, it will break
at execution time.
So type hinting and strict typing will not make our code safer or faster.

We don't have to be ashamed of using a script language.
Thanks to this, we can do metaprogramming.
for instance, __call() allow us to do really awesome things
If we look at other script languages, Python, Ruby, Perl or Javascript
doesn't have srtict typing nor type hinting.

I love static languages.
I write code in C, C++, Java, As3 and C#.
They have good performance, stric typing, static checks at compilation
time.
But it's a different technology, and their philosophy is allowed only
because there's a compilation phase.

That's why when facebook, with HHVM, tryied to make a faster PHP, it can
only work with a subset of what is realy PHP.
For this reason, it's really really difficult to make javascript a fast
language (v8 and sipermonkey are very complex).
For the same reason, now Adobe decide to give up with the dynamic part of
ActionScript (wich was limited compared to PHP) to speed up their VM.

So I think going to scrict typing only make sense if we want a static
language, with compilation phase and performances gains due.
But it would be more than a major compatibility.
A lot of things will be not only be broken, but will be impossible.

Finally, it would be a so big engine change that it would be better to
restart the engine from scratch.
And if we start from scratch without backward compatibility, is this still
PHP ?

And is there a language which already works as expected? Java ?

Just my 0.02$

--
Samuel DEAL
samuel.deal@gmail.com

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

There are advantages to strict typing other than speed and safety. The
biggest compliant I hear from people asking for this is that weak
hinting often leads to bulkier code that is much more difficult to read,
particularly for someone who frequently switches between PHP and
compiled languages like C++ and C#.

If somebody finds PHP much more difficult to read than C++, well, he
obviously has a very different concept of reading than the rest of the
humankind. As for other points, I don't think it really makes sense to
discuss making PHP into C++ or any kind of strict typed language. If one
needs strict typed compiled language, one knows where to find plenty of
them.

Therefore, allowing for strict typing, i.e. leaving it to the discretion
of the code author, would not necessitate converting PHP into a compiled

I would really wish when we have this annual strict typing discussion
people would bother to read past ones. Partial strict typing does not
work, and in general strict typing in non-compiled language is asking
for trouble. We talked about it many times.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Kris Craig — view source — reply

unread

I'm well aware that this has been discussed before, Stas. However, you're
mischaracterizing those previous conversations. It has never been proven
that optional strict typing doesn't work. You've made the same arguments
against it, but those arguments have counter-arguments that are also viable.

If anything, I think the fact that this keeps coming up is something that
you should be the one to take note of. It keeps coming up because people
keep asking for it. It keeps coming up because, despite belittling and
dismissive comments made by yourself and a few others, people continue to
see that there is, in fact, a valid argument for implementing this. It
shows that you have never been able to convince those who don't already
agree with you that this is impossible.

You're also imploying some logical fallacies. For example, you guys have
repeatedly tried to mischaracterize this as an attempt to "rewrite" PHP
into a clone of C++ or Java. Nobody is proposing anything even remotely
like that. On the contrary, the PHP language would remain largely
unchanged; we'd merely be adding a new element to it.

Furthermore, I have spoken to numerous people who have complained about PHP
code being overly bulky and/or difficult to read due to its mandatory
dynamic typing. Your counter-argument to that was, essentially, "Yeah,
well they're all stupid!" No, they're not. They have a valid point. PHP
can be bulky and it can be hard to read is certain circumstances--
situations where strict typing would make it much easier to read. Your
dismissive attitude does not constitute a constructive argument IMHO. It's
just juvenile and disrespectful of those who happen to disagree with you.

And again, you're using the, "If you don't like PHP, then get the hell out
and use a different language," argument (i.e. "If one needs strict typed
compiled language, one knows where to find plenty of them."). As I said in
a previous post, that argument carries ZERO weight with me, and I'm not the
only one who feels that way.

Like it or not, we're talking about this now. We're talking about it
because people are still interested and still eager for this to happen,
despite previous discussions in which they're often demeaned or ridiculed.
Whether or not it will actually happen is something neither of us can
predict, but the discussion is happening right now and we're not going to
stop talking about it just because you don't think it should be discussed.
So let's drop the arrogant, "We've already talked about this stupid thing
before," crap right here and now because it's not going to change anything.

Regarding Arvids' comment, that's a valid concern. There are instances
where the data coming in may not be predictable. But in those cases, you
could simply not use strict typing. What we're proposing would be
optional, probably on a per-function and/or per-script basis. This would
be an expansion of PHP's existing feature set, in a manner of speaking.
Existing scripts would continue to function as they do now. Also, John
was correct in pointing out that even C++ supports implicit conversions.

This is obviously a topic that people are passionate about on both sides.
However, if we could make more of an effort to be respectful of others and
their viewpoints, this discussion can be had without animosity or insults
being hurled about. I came into this largely on the fence, but I'm more
and more becoming convinced that this in fact would be a good idea. Both
sides have valid arguments and, like it or not, this issue is NOT going to
go away.

--Kris

On Sat, Feb 25, 2012 at 3:00 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

There are advantages to strict typing other than speed and safety. The

biggest compliant I hear from people asking for this is that weak
hinting often leads to bulkier code that is much more difficult to read,
particularly for someone who frequently switches between PHP and
compiled languages like C++ and C#.

If somebody finds PHP much more difficult to read than C++, well, he
obviously has a very different concept of reading than the rest of the
humankind. As for other points, I don't think it really makes sense to
discuss making PHP into C++ or any kind of strict typed language. If one
needs strict typed compiled language, one knows where to find plenty of
them.

Therefore, allowing for strict typing, i.e. leaving it to the discretion
of the code author, would not necessitate converting PHP into a compiled

I would really wish when we have this annual strict typing discussion
people would bother to read past ones. Partial strict typing does not work,
and in general strict typing in non-compiled language is asking for
trouble. We talked about it many times.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Stas Malyshev — view source — reply

unread

Hi!

I'm well aware that this has been discussed before, Stas. However,
you're mischaracterizing those previous conversations. It has never
been proven that optional strict typing doesn't work. You've made the
same arguments against it, but those arguments have counter-arguments
that are also viable.

I'm not sure what you mean by "proven". You expect rigorous mathematical
proof? You're not getting one. If you have something new to say with
regard to the arguments that were brought up 10 times already - ok, go
ahead. But please read them first.

people keep asking for it. It keeps coming up because, despite
belittling and dismissive comments made by yourself and a few others,
people continue to see that there is, in fact, a valid argument for
implementing this. It shows that you have never been able to convince
those who don't already agree with you that this is impossible.

Or it's coming up because people don't bother to read past discussions
and think they are first who thought "let's put strict typing in PHP"
and only reason why it's not there because nobody was smart enough to
think about it. It's not so. It was repeatedly discussed and
rediscussed. If you have new argument - fine, we'd all be happy to hear
it. So far I didn't hear one though. Please let us hear it.

remotely like that. On the contrary, the PHP language would remain
largely unchanged; we'd merely be adding a new element to it.

It doesn't work that way. Language is a complex construct, with all
parts influencing each other, thinking you can just add strict typing
somewhere in the corner and nothing changes is a dangerous illusion. It
would not work. If you type function arguments, you should also type all
the variables that could end up as the function arguments, all the
functions returning into those arguments and all the operators and
functions that do any transformations over those things. Otherwise it is
guaranteed to blow up in runtime. After doing that, you've got yourself
a strictly typed language. Absent compiler, though, such language would
be quite hard to operate - how do you know your code correctly uses all
the types some library wants? How do you know next version doesn't
change any types without you noticing? etc., etc.

Furthermore, I have spoken to numerous people who have complained about
PHP code being overly bulky and/or difficult to read due to its
mandatory dynamic typing. Your counter-argument to that was,

I think these people are mistaken. PHP code, as in any language, may be
well written or purely written, however this has nothing to do with
dynamic typing. There are dynamically and statically typed languages,
both have their uses. Static typing is well fit for compiled languages
since compiling allows pre-execution type control and thus ensures no
surprises in runtime.
If you would like to explain yourself more in detail and specifically
describe which code is "bulky and hard to read" due to dynamic typing -
please do so.

essentially, "Yeah, well they're all stupid!" No, they're not. They

If you're going to distort my words and assign me things that I never
said I would just stop this discussion and instead will silently delete
everything you send. No sane discussion can be held in this manner, so
please show respect to yourself and everybody participating and never do
this again.

And again, you're using the, "If you don't like PHP, then get the hell
out and use a different language," argument (i.e. "If one needs strict
typed compiled language, one knows where to find plenty of them."). As
I said in a previous post, that argument carries ZERO weight with me,
and I'm not the only one who feels that way.

PHP is built on a certain principles, and people that build and maintain
PHP would like to continue developing it along these principles. You
think the proper language should be based on different set of principles

it is your right, however this language would not be PHP. There's
nothing wrong with that, and pointing out that fact is not "dismissive".
It is just a reminder that each language should have some principles. If
you want to discuss why these principles are there - fine, but I mus
warn you that it is rather unlikely that these principles will be thrown
out and replaced with entirely new ones.

should be discussed. So let's drop the arrogant, "We've already talked
about this stupid thing before," crap right here and now because it's
not going to change anything.

I would also ask you to please amend your tone and avoid name-calling,
swearing and otherwise rude expressions on the list. I understand that
some topics can make one passionate, however I think remaining within
the bounds of polite and civilized tone of discussion is not too much to
ask.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Kris Craig — view source — reply

unread

Inline, we go....

--Kris

On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

I'm well aware that this has been discussed before, Stas. However,

you're mischaracterizing those previous conversations. It has never
been proven that optional strict typing doesn't work. You've made the
same arguments against it, but those arguments have counter-arguments
that are also viable.

I'm not sure what you mean by "proven". You expect rigorous mathematical
proof? You're not getting one. If you have something new to say with regard
to the arguments that were brought up 10 times already - ok, go ahead. But
please read them first.

Another logical fallacy. Cognitive dissonance. Either there is "rigorous
mathematical proof" or a statement is completely unproven (and/or cannot be
proven).

In fact, you haven't proven your point by any standard, rigorous or
otherwise. There is no basis for suggesting that it cannot be done.
You've clearly stated that you don't think it should be done, but you
haven't viably demonstrated that it can't be done, or that it would
"break" PHP as we know it.

people keep asking for it. It keeps coming up because, despite

belittling and dismissive comments made by yourself and a few others,
people continue to see that there is, in fact, a valid argument for
implementing this. It shows that you have never been able to convince
those who don't already agree with you that this is impossible.

Or it's coming up because people don't bother to read past discussions and
think they are first who thought "let's put strict typing in PHP" and only
reason why it's not there because nobody was smart enough to think about
it. It's not so. It was repeatedly discussed and rediscussed. If you have
new argument - fine, we'd all be happy to hear it. So far I didn't hear one
though. Please let us hear it.

No, it's coming up because people have read these past discussions and
still think it's a reasonable goal that deserves further consideration.
Your assumption that anyone who disagrees with you must not have read or
even be aware of the existence of previous threads on this topic is a good
example of your arrogant belittling of and disrespect toward them.

Your premise seems to rely on the notion that, since this was previously
discussed but not implemented, this idea was resoundingly rejected. On the
contrary, it looks to me more like it either fizzled or was punted each
time, but no consensus was ever reached. Therefore, further discussion is
warranted. The fact that this was discussed previously does not make this
topic any less legitimate.

remotely like that. On the contrary, the PHP language would remain

largely unchanged; we'd merely be adding a new element to it.

It doesn't work that way. Language is a complex construct, with all parts
influencing each other, thinking you can just add strict typing somewhere
in the corner and nothing changes is a dangerous illusion. It would not
work. If you type function arguments, you should also type all the
variables that could end up as the function arguments, all the functions
returning into those arguments and all the operators and functions that do
any transformations over those things. Otherwise it is guaranteed to blow
up in runtime. After doing that, you've got yourself a strictly typed
language. Absent compiler, though, such language would be quite hard to
operate - how do you know your code correctly uses all the types some
library wants? How do you know next version doesn't change any types
without you noticing? etc., etc.

You're operating on a number of unfounded assumptions here (a "house of
cards" if you will). First, nobody is saying that this wouldn't be a
significant undertaking at the core development level. We all agree that
it would be. However, you're once again introducing cognitive dissonance
into this. The same logic you're using could be used to say that solid OO
classes shouldn't be implemented because it would then render procedural
scripting impossible. After all, "all parts influence each other," as you
put it. However, everything didn't blow up when PHP 5 was released.
People can still write purely procedural code just like they did before.

Language is complex, yes; but it is also flexible. We've already discussed
previously in this thread how these interactions between strinct and
dynamic functions could take place.

So, your argument that this would be "guaranteed to blow up in runtime" and
that, therefore, we would be stuck with a purely strict-typed language is
based on a faulty premise. The house of cards collapses.

Don't get me wrong; there are plenty of fine details that would need to be
figured out. But again, complexity != impossibility. It can be done, and
it can be done in a way that won't cause the world to come to an end.

Furthermore, I have spoken to numerous people who have complained about

PHP code being overly bulky and/or difficult to read due to its
mandatory dynamic typing. Your counter-argument to that was,

I think these people are mistaken. PHP code, as in any language, may be
well written or purely written, however this has nothing to do with dynamic
typing. There are dynamically and statically typed languages, both have
their uses. Static typing is well fit for compiled languages since
compiling allows pre-execution type control and thus ensures no surprises
in runtime.
If you would like to explain yourself more in detail and specifically
describe which code is "bulky and hard to read" due to dynamic typing -
please do so.

PHP may not be compiled, but it does plenty of "pre-runtime" sanity checks.
That's when things like parse errors are caught.

As for an example, please refer to earlier posts on this thread, as that
has already been provided.

essentially, "Yeah, well they're all stupid!" No, they're not. They

If you're going to distort my words and assign me things that I never said
I would just stop this discussion and instead will silently delete
everything you send. No sane discussion can be held in this manner, so
please show respect to yourself and everybody participating and never do
this again.

You should re-read your statements before you accuse others of distorting
them. Here's the exact quote of what you said:

"If somebody finds PHP much more difficult to read than C++, well, he
obviously has a very different concept of reading than the rest of the
humankind."

In other words, anyone who think PHP is harder to read is obviously not as
smart as the rest of the human race (at least when it comes to reading
comprehension). So yes, you were basically saying that these people are
stupid. You've been consistently belittling those who disagree with you,
like accusing all of them of being ignorant of previous threads on this
topic, etc.

I stand by what I said. Much of your rhetoric consists of you looking down
your nose at everyone who disagrees with you. Don't dish it out of you
can't take it. ;P

And again, you're using the, "If you don't like PHP, then get the hell

out and use a different language," argument (i.e. "If one needs strict
typed compiled language, one knows where to find plenty of them."). As
I said in a previous post, that argument carries ZERO weight with me,
and I'm not the only one who feels that way.

PHP is built on a certain principles, and people that build and maintain
PHP would like to continue developing it along these principles. You think
the proper language should be based on different set of principles - it is
your right, however this language would not be PHP. There's nothing wrong
with that, and pointing out that fact is not "dismissive". It is just a
reminder that each language should have some principles. If you want to
discuss why these principles are there - fine, but I mus warn you that it
is rather unlikely that these principles will be thrown out and replaced
with entirely new ones.

Another logical fallacy. You're attempting to redefine the debate on the
grounds that mandatory dynamic typing is one of the founding "principles"
that PHP stnads for, even though you have zero basis for making that claim
other than the fact that PHP in its current form does not support strict
typing (that same argument could be used to reject any new feature to PHP
that touches the language). That would be like saying that English is no
longer English because we've added some new words to the dictionary and
modified some of the grammar rules (Oxford Comma, anyone?).

So no, we're not talking about turning PHP into a different language.
We're not tearing everything down and starting from scratch. Hell, what
we're talking about wouldn't even break compatibility with existing
scripts! This sort of radical hyperbole does not justify being dismissive
of those who are making a legitimate argument that you happen to disagree
with. It's not constructive, and it's probably hyperbole like this that
makes people less likely to continue discussion threads on this topic.
After all, I'm sure nobody here would like the idea of being seen as
trying to "kill PHP".

should be discussed. So let's drop the arrogant, "We've already talked

about this stupid thing before," crap right here and now because it's
not going to change anything.

I would also ask you to please amend your tone and avoid name-calling,
swearing and otherwise rude expressions on the list. I understand that some
topics can make one passionate, however I think remaining within the bounds
of polite and civilized tone of discussion is not too much to ask.

What name-calling, exactly? The word "arrogant" is an adjective, not a
noun.

It sounds like you're trying to imploy the old, "I'm rubber, you're glue"
approach; i.e. hoping to cancel-out my criticism of your disrespectful tone
by repeated the same accusation toward me. I could then counter with the
classic, "Well you started it!" but that wouldn't serve any purpose, now
would it?

Like I said before, if you are dismissive and disrespectful of the other
side, they in turn will develop a more hostile tone toward you. It's basic
human nature and perfectly understandable. If you've suddenly come around
and decided you want to have a respectful conversation, I'm all for it!
But you need to take responsibility for your own attitude and remember
that the opinions of those who disagree with you are no less valid than
your own.

I'd really prefer that this thread not devolve into a cliche flame war.
That's probably what killed some of the past discussions. However, we've
procrastinated on this long enough IMHO. These extremely prevelent
concerns are not going to just "go away" and ignoring them or belittling
them won't change that. The status quo is rarely a blueprint for
perfection. =)

--Kris

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Arvids Godjuks — view source — reply

unread

Kris Craig

I usually just read the list, sometimes add if I have something to say and
I had voiced my opinion on typehinting before. And you know, just from the
stand of a userland developer who has 7-8 years of experience and devoting
myself to the excelence at PHP, i see this discussion about adding strict
typehinting to PHP as ridicilous. I cannot express my thrustration, because
i would probably be kicked out of the list permanently.
The problem is that those, who are actually advocating for this, come from
all sorts of languages (or have moved to them some time ago) and now what
to "make php better". Sorry folks, but I have picked up a script language
not because it has strict type hinting, but actually because it does not
have it. And because in web we are working with text. Almost any data we
get is text and in critical places we just check that data we have is
actually a number and not a random string. Or is an object of certain type.
Or is an array. Or a valid string. And we let the PHP to handle routine
conversions. And it's good because there can be tons of them per single
script call. String to number and vice-verse conversions are all over the
place in almost any script. They are so common, that if you would add
strict typehinting - you would probably need a type conversion on every
function/method call.

PHP had (and i have to believe it still has, but people started to really
forget it) a principle called KISS. And strict typehinting is NOT simple.
It really complicates things, a lot. And really, in a scripting language?!
Are people going nuts because of 2012? Has to be, because i just can't
explain what is happening with the typehinting rfc discussions for the last
year.
The way i see it, there is two types of people. The PHP crowd, that says
that optional weak type hinting could be helpfull and strict-type hinting
crowd witch has come to PHP from different languages or had moved from PHP
to them, but ocasionaly returns to it.

What i thing is that core devs should really look at what the php is, on
what principles it is built and based. Remember what it was built for and
why it's popular. And that if you handle it correctly - it's a powerful
tool, and works great. And that we do not need other python, perl or ruby.
PHP always had it's own way and it should. My vote is for optional weak
typehinting that will do what the most want - to write a more solid library
code with less annoing checks and does not put additional restraints on the
userland code. Because if you give people something like strict typing - it
just will get abused to such extreme by some people, that it will create
more negative than good in the long run.

PHP is not the easiest language out there. Yes, it's easy to start with,
but it's not that easy to master and strike the right balance between
simplicity and complexity. And people tend to go overcomplex forgetting the
KISS. I'd rather see the PDO getting a major kick, or dumped allready and
work gone into db drivers and unicode support improvement - these are far
more important than strict type hinting.

14 years ago by Kris Craig — view source — reply

unread

Arvids,

I can only speak for myself of course, but you should never feel as though
you're not welcome to express yourself here freely and openly.
Frustration, anger, bickering, etc; so long as it's not ad spam or just
completely off-topic, I personally think it's all fair game. Of course, I
disagree with a number of your points and I'll get to that, but I just
first wanted to put that out there. Like you, I've monitored the list
(including Internals) for years but only recently started posting to it
myself. And, like you, I would shudder at the thought of being censored or
"kicked-out" for speaking my mind. So as much as I disagree with you, I
hope you won't hesitate to speak your mind without reservation! If anyone
tries to tell you that you can't, I'll have your back (for whatever that's
worth lol).

Ok, now that that's out of the way.... I think you're operating under some
fundamental misconceptions about this debate. Specifically, there are two
in particular that I feel compelled to address (quoted text is
paraphrasing):

"The people advocating strict type hinting are people who either
abandoned PHP long ago or came to PHP from other languages. Those of us
who are the pure, loyal PHP developers don't support this at all."

I first dabbled in PHP about 12 years ago, back when .php3 files were still
the norm. About 10 years ago (PHP 4) was when I really started doing
everything in PHP. I've been using it ever since and it continues to be my
favorite language, in no small part because of its inherent flexibility.

That said, I also have experience in a number of other languages; this
listserv shouldn't be used as my personal resume so I'll spare you the
details lol. Sufficeth to say, I'd like to think I have a rather
well-rounded background. But the overwhelming majority of the work I've
done has always been in PHP (at least since 2000) and I don't see that
changing anytime soon.

I also know and have worked with many people who, like me, are die-hard PHP
fans but also believe, like me, that there's still a lot of room for
improvement. We can live in denial and deride everyone who criticizes our
favorite code as crazy or stupid, but we're only hurting ourselves if we do
that.

So no, this isn't an "us vs. them" situation. We're all in this together.
We all have unique backgrounds, each of which enriches the whole by
offering a different perspective. I don't believe that's a bad thing.
I've criticized veteran programmers for looking down their noses at
hard-core PHP developers on numerous occasions (and I'm often in the
minority for doing so). But while their attitudes and conclusions may be
wrong, they do reference some valid points. Likewise, you've seen me in
this very thread criticizing a PHP developer for looking down his nose at
people with different perspectives. Some rivalry can be healthy, but I
think there's a lot of unhealthy derision on both sides that just makes it
more difficult for us to have these important conversations.

I'm a veteran PHP developer and proud of it, just as you are. And the more
I think about it and hear all the arguments, the more I'm convinced that
the introduction of optional strict typing into PHP 6 is the right way to
go.

"Strict type hinting would eliminate PHP's flexibility and take away its
unique simplicity."

I respectfully disagree. Again, let me remind you that we are not talking
about *converting *PHP to strict type hinting. Instead, we're merely
talking about allowing PHP developers to choose whether or not to make a
given function use dynamic or strict type hinting. The default behavior
will remain dynamic, just as it is now. But there are situations where
strict type hinting, even in a PHP script, would make more sense. There
are many PHP developers, myself among them, who see considerable benefit in
being able to make a function more condensed and streamlined without having
to waste so much time on sanity checks that could instead be handled at a
lower level in the core.

This would not make PHP any less simple. On the contrary, we would be
making it more accessible to people who come from different backgrounds.
Under the right circumstances, strict type hinting would actually make PHP
more simple, not less. This would not be an abandonment of KISS. I would
never have even considered supporting it if it was.

This idea produces a lot of anxiety among some veteran PHP developers.
That's understandable. After all, if you've generally avoided dealing
with languages that use strict typing, the thought of PHP supporting it
could seem very intimidating. But remember, this is something that would
be an option, at the discretion of the developer (i.e. you). You would be
the one choosing whether or not to use it in any of your functions, just as
you are the one who chooses whether to structure your code using OO classes
or stick to traditional procedural code. OO concepts can also be very
intimidating to someone who's accustomed to procedural languages. But PHP
decided to bridge that gap, and we all survived. Just as it will survive
by one again bridging an accessibility gap.

There are other important things to work on, but we've always been able to
walk and chew gum at the same time before. PHP 6 won't be happening
anytime soon anyway, so I think it might be good if we all just took a deep
breath and relax for a moment. Now is a good time to be having this
conversation. I don't think we should punt it any further and I will try
to push back against that reflex at least a little bit. But either way,
this issue isn't going to go away; the fact that it still hasn't gone away
I think proves that well enough.

I don't think anybody is crazy as far as this debate goes. Both sides have
valid points that need to be addressed with thought and care. But
dismissing it out of hand or simply ignoring it hasn't worked because
people are still asking for it, so I will be pushing back against that this
time and advocate for a continued, ongoing dialogue on this until a true
consensus can finally be reached. Avoiding it isn't the answer IMHO.

--Kris

On Sat, Feb 25, 2012 at 8:11 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

Kris Craig

I usually just read the list, sometimes add if I have something to say and
I had voiced my opinion on typehinting before. And you know, just from the
stand of a userland developer who has 7-8 years of experience and devoting
myself to the excelence at PHP, i see this discussion about adding strict
typehinting to PHP as ridicilous. I cannot express my thrustration, because
i would probably be kicked out of the list permanently.
The problem is that those, who are actually advocating for this, come from
all sorts of languages (or have moved to them some time ago) and now what
to "make php better". Sorry folks, but I have picked up a script language
not because it has strict type hinting, but actually because it does not
have it. And because in web we are working with text. Almost any data we
get is text and in critical places we just check that data we have is
actually a number and not a random string. Or is an object of certain type.
Or is an array. Or a valid string. And we let the PHP to handle routine
conversions. And it's good because there can be tons of them per single
script call. String to number and vice-verse conversions are all over the
place in almost any script. They are so common, that if you would add
strict typehinting - you would probably need a type conversion on every
function/method call.

PHP had (and i have to believe it still has, but people started to really
forget it) a principle called KISS. And strict typehinting is NOT simple.
It really complicates things, a lot. And really, in a scripting language?!
Are people going nuts because of 2012? Has to be, because i just can't
explain what is happening with the typehinting rfc discussions for the last
year.
The way i see it, there is two types of people. The PHP crowd, that says
that optional weak type hinting could be helpfull and strict-type hinting
crowd witch has come to PHP from different languages or had moved from PHP
to them, but ocasionaly returns to it.

What i thing is that core devs should really look at what the php is, on
what principles it is built and based. Remember what it was built for and
why it's popular. And that if you handle it correctly - it's a powerful
tool, and works great. And that we do not need other python, perl or ruby.
PHP always had it's own way and it should. My vote is for optional weak
typehinting that will do what the most want - to write a more solid library
code with less annoing checks and does not put additional restraints on the
userland code. Because if you give people something like strict typing - it
just will get abused to such extreme by some people, that it will create
more negative than good in the long run.

PHP is not the easiest language out there. Yes, it's easy to start with,
but it's not that easy to master and strike the right balance between
simplicity and complexity. And people tend to go overcomplex forgetting the
KISS. I'd rather see the PDO getting a major kick, or dumped allready and
work gone into db drivers and unicode support improvement - these are far
more important than strict type hinting.

14 years ago by John LeSueur — view source — reply

unread

[trim]

"Strict type hinting would eliminate PHP's flexibility and take away its
unique simplicity."

I respectfully disagree. Again, let me remind you that we are not
talking
about *converting *PHP to strict type hinting. Instead, we're merely
talking about allowing PHP developers to choose whether or not to make a
given function use dynamic or strict type hinting. The default behavior
will remain dynamic, just as it is now. But there are situations where
strict type hinting, even in a PHP script, would make more sense. There
are many PHP developers, myself among them, who see considerable benefit in
being able to make a function more condensed and streamlined without having
to waste so much time on sanity checks that could instead be handled at a
lower level in the core.

So this is the argument that those who object to strict type hinting don't
agree with. Take the following:

function strictTypes(/int/ $var)
{
//this is what the engine does if we have strict type checking
if(!is_int($var)) trigger_error();
}

function weakTypes(/int/ $var)
{
//this is what the engine does if we have weak type hinting, or
something similar.
if(!is_numeric($var) || (int)$var != $var) trigger_error();
else $var = (int)$var;
}

function dynamicTypes($var)
{
strictTypes((int) $var);
//if $var is not an int, we just made it 0, and hid the type error.
//to avoid this mistake we have to do:
strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$var ==
$var) ? (int)$var : trigger_error());
//or something like it.
weakTypes($var);
//we'll get an error if $var can't be converted to an int without data
loss.
}

By calling the strictTypes() function, the dynamicTypes() function inherits
the problem of validating the type of $var. Well, if I'm writing the
dynamicTypes function, I don't want that work, so I push it up the chain,
and change my dynamicTypes function to statically typed. If you're into
static types, then you say, that's great, someone should make sure that
$var has the right type when they got it from the user. But if you're not
into static types, you were just forced to do type checking, either in your
code, or passing it up the call chain for someone else to do the type
checking. That's what is meant when we say dynamic typing can't really
coexist with strict typing. For those into dynamic types, weak type hinting
is much more palatable, because it doesn't require callers to adopt the
same philosophy.

If you want type hinting, you'll have to specify which kind you want,
strict or weak. If it's strict type hinting, you'll need to convince even
those who think dynamic typing is a guiding principle of PHP that it can be
done without forcing strict typing up the call chain. Weak type hinting is
a softer sell, but requires a lot of thought(much of which has been done,
if you look in previous discussions) , about how and when to convert values.

14 years ago by Arvids Godjuks — view source — reply

unread

I absolutely agree with this. The hurdle with the strict type hinting is
pictured very well. Strict is strict - either the whole codebase follows
it, or it doesn't follow it at all. If a part of the code uses it - means
all the code comunicating with that part has to use, or at least has to be
written with the strict type hinting in mind.

Oh, and i remembered a case where strict type hinting would be highly
questionable - the "mixed" variant. Right now we document thouse with the
phpdoc comments, but its quite common use in php to accept a null or an
array for example. I can't imagine strict type hinting in this case, but
weak type hints can work.
27.02.2012 0:51 пользователь "John LeSueur" john.lesueur@gmail.com
написал:

[trim]

"Strict type hinting would eliminate PHP's flexibility and take away
its
unique simplicity."

I respectfully disagree. Again, let me remind you that we are not
talking
about *converting *PHP to strict type hinting. Instead, we're merely
talking about allowing PHP developers to choose whether or not to make a
given function use dynamic or strict type hinting. The default behavior
will remain dynamic, just as it is now. But there are situations where
strict type hinting, even in a PHP script, would make more sense. There
are many PHP developers, myself among them, who see considerable benefit
in
being able to make a function more condensed and streamlined without
having
to waste so much time on sanity checks that could instead be handled at a
lower level in the core.

So this is the argument that those who object to strict type hinting don't
agree with. Take the following:

function strictTypes(/int/ $var)
{
//this is what the engine does if we have strict type checking
if(!is_int($var)) trigger_error();
}

function weakTypes(/int/ $var)
{
//this is what the engine does if we have weak type hinting, or
something similar.
if(!is_numeric($var) || (int)$var != $var) trigger_error();
else $var = (int)$var;
}

function dynamicTypes($var)
{
strictTypes((int) $var);
//if $var is not an int, we just made it 0, and hid the type error.
//to avoid this mistake we have to do:
strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$var ==
$var) ? (int)$var : trigger_error());
//or something like it.
weakTypes($var);
//we'll get an error if $var can't be converted to an int without data
loss.
}

By calling the strictTypes() function, the dynamicTypes() function
inherits the problem of validating the type of $var. Well, if I'm writing
the dynamicTypes function, I don't want that work, so I push it up the
chain, and change my dynamicTypes function to statically typed. If you're
into static types, then you say, that's great, someone should make sure
that $var has the right type when they got it from the user. But if you're
not into static types, you were just forced to do type checking, either in
your code, or passing it up the call chain for someone else to do the type
checking. That's what is meant when we say dynamic typing can't really
coexist with strict typing. For those into dynamic types, weak type hinting
is much more palatable, because it doesn't require callers to adopt the
same philosophy.

If you want type hinting, you'll have to specify which kind you want,
strict or weak. If it's strict type hinting, you'll need to convince even
those who think dynamic typing is a guiding principle of PHP that it can be
done without forcing strict typing up the call chain. Weak type hinting is
a softer sell, but requires a lot of thought(much of which has been done,
if you look in previous discussions) , about how and when to convert values.

14 years ago by Kris Craig — view source — reply

unread

I actually agree as well. Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating. So to clarify, I'm referring to optional non-dynamic
typing vs purely dynamic typing as we have now. Strict typing would
require some global or config setting as I originally proposed; a
function-by-function approach obviously would only work with weak typing.
Looks like I got a bit dyslexic on you guys so I apologize for the
confusion.

That being said, I do believe that optional strict typing on a global scale
is worthy of further discussion, though I remain on the fence as far as
whether or not we should actually go forward with that idea. But the
function-by-function approach (by which I mean weak typing lol) is
something that I'm increasingly convinced is a good idea.

--Kris

On Sun, Feb 26, 2012 at 4:09 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

I absolutely agree with this. The hurdle with the strict type hinting is
pictured very well. Strict is strict - either the whole codebase follows
it, or it doesn't follow it at all. If a part of the code uses it - means
all the code comunicating with that part has to use, or at least has to be
written with the strict type hinting in mind.

Oh, and i remembered a case where strict type hinting would be highly
questionable - the "mixed" variant. Right now we document thouse with the
phpdoc comments, but its quite common use in php to accept a null or an
array for example. I can't imagine strict type hinting in this case, but
weak type hints can work.
27.02.2012 0:51 пользователь "John LeSueur" john.lesueur@gmail.com
написал:

[trim]

"Strict type hinting would eliminate PHP's flexibility and take away
its
unique simplicity."

I respectfully disagree. Again, let me remind you that we are not
talking
about *converting *PHP to strict type hinting. Instead, we're merely
talking about allowing PHP developers to choose whether or not to
make a
given function use dynamic or strict type hinting. The default behavior
will remain dynamic, just as it is now. But there are situations where
strict type hinting, even in a PHP script, would make more sense. There
are many PHP developers, myself among them, who see considerable benefit
in
being able to make a function more condensed and streamlined without
having
to waste so much time on sanity checks that could instead be handled at
a
lower level in the core.

So this is the argument that those who object to strict type hinting
don't
agree with. Take the following:

function strictTypes(/int/ $var)
{
//this is what the engine does if we have strict type checking
if(!is_int($var)) trigger_error();
}

function weakTypes(/int/ $var)
{
//this is what the engine does if we have weak type hinting, or
something similar.
if(!is_numeric($var) || (int)$var != $var) trigger_error();
else $var = (int)$var;
}

function dynamicTypes($var)
{
strictTypes((int) $var);
//if $var is not an int, we just made it 0, and hid the type error.
//to avoid this mistake we have to do:
strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$var ==
$var) ? (int)$var : trigger_error());
//or something like it.
weakTypes($var);
//we'll get an error if $var can't be converted to an int without
data
loss.
}

By calling the strictTypes() function, the dynamicTypes() function
inherits the problem of validating the type of $var. Well, if I'm writing
the dynamicTypes function, I don't want that work, so I push it up the
chain, and change my dynamicTypes function to statically typed. If you're
into static types, then you say, that's great, someone should make sure
that $var has the right type when they got it from the user. But if
you're
not into static types, you were just forced to do type checking, either
in
your code, or passing it up the call chain for someone else to do the
type
checking. That's what is meant when we say dynamic typing can't really
coexist with strict typing. For those into dynamic types, weak type
hinting
is much more palatable, because it doesn't require callers to adopt the
same philosophy.

If you want type hinting, you'll have to specify which kind you want,
strict or weak. If it's strict type hinting, you'll need to convince even
those who think dynamic typing is a guiding principle of PHP that it can
be
done without forcing strict typing up the call chain. Weak type hinting
is
a softer sell, but requires a lot of thought(much of which has been done,
if you look in previous discussions) , about how and when to convert
values.

14 years ago by Tom Boutell — view source — reply

unread

There's no such thing as optional global anything, if you're a library
or framework developer who has to cope with what's turned on wherever
their code may wind up.

I actually agree as well. Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating. So to clarify, I'm referring to optional non-dynamic
typing vs purely dynamic typing as we have now. Strict typing would
require some global or config setting as I originally proposed; a
function-by-function approach obviously would only work with weak typing.
Looks like I got a bit dyslexic on you guys so I apologize for the
confusion.

That being said, I do believe that optional strict typing on a global scale
is worthy of further discussion, though I remain on the fence as far as
whether or not we should actually go forward with that idea. But the
function-by-function approach (by which I mean weak typing lol) is
something that I'm increasingly convinced is a good idea.

--Kris

On Sun, Feb 26, 2012 at 4:09 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

I absolutely agree with this. The hurdle with the strict type hinting is
pictured very well. Strict is strict - either the whole codebase follows
it, or it doesn't follow it at all. If a part of the code uses it - means
all the code comunicating with that part has to use, or at least has to be
written with the strict type hinting in mind.

Oh, and i remembered a case where strict type hinting would be highly
questionable - the "mixed" variant. Right now we document thouse with the
phpdoc comments, but its quite common use in php to accept a null or an
array for example. I can't imagine strict type hinting in this case, but
weak type hints can work.
27.02.2012 0:51 пользователь "John LeSueur" john.lesueur@gmail.com
написал:

[trim]

"Strict type hinting would eliminate PHP's flexibility and take away
its
unique simplicity."

I respectfully disagree. Again, let me remind you that we are not
talking
about *converting *PHP to strict type hinting. Instead, we're merely
talking about allowing PHP developers to choose whether or not to
make a
given function use dynamic or strict type hinting. The default behavior
will remain dynamic, just as it is now. But there are situations where
strict type hinting, even in a PHP script, would make more sense. There
are many PHP developers, myself among them, who see considerable benefit
in
being able to make a function more condensed and streamlined without
having
to waste so much time on sanity checks that could instead be handled at
a
lower level in the core.

So this is the argument that those who object to strict type hinting
don't
agree with. Take the following:

function strictTypes(/int/ $var)
{
//this is what the engine does if we have strict type checking
if(!is_int($var)) trigger_error();
}

function weakTypes(/int/ $var)
{
//this is what the engine does if we have weak type hinting, or
something similar.
if(!is_numeric($var) || (int)$var != $var) trigger_error();
else $var = (int)$var;
}

function dynamicTypes($var)
{
strictTypes((int) $var);
//if $var is not an int, we just made it 0, and hid the type error.
//to avoid this mistake we have to do:
strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$var ==
$var) ? (int)$var : trigger_error());
//or something like it.
weakTypes($var);
//we'll get an error if $var can't be converted to an int without
data
loss.
}

By calling the strictTypes() function, the dynamicTypes() function
inherits the problem of validating the type of $var. Well, if I'm writing
the dynamicTypes function, I don't want that work, so I push it up the
chain, and change my dynamicTypes function to statically typed. If you're
into static types, then you say, that's great, someone should make sure
that $var has the right type when they got it from the user. But if
you're
not into static types, you were just forced to do type checking, either
in
your code, or passing it up the call chain for someone else to do the
type
checking. That's what is meant when we say dynamic typing can't really
coexist with strict typing. For those into dynamic types, weak type
hinting
is much more palatable, because it doesn't require callers to adopt the
same philosophy.

If you want type hinting, you'll have to specify which kind you want,
strict or weak. If it's strict type hinting, you'll need to convince even
those who think dynamic typing is a guiding principle of PHP that it can
be
done without forcing strict typing up the call chain. Weak type hinting
is
a softer sell, but requires a lot of thought(much of which has been done,
if you look in previous discussions) , about how and when to convert
values.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

14 years ago by Kris Craig — view source — reply

unread

Exactly, hence why I'm still on the fence with that. I was hoping for some
further discussion though to see if anyone can think of a way around that,
though admittedly nothing comes to my mind.

--Kris

2012/2/26 Tom Boutell tom@punkave.com

There's no such thing as optional global anything, if you're a library
or framework developer who has to cope with what's turned on wherever
their code may wind up.

I actually agree as well. Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating. So to clarify, I'm referring to optional non-dynamic
typing vs purely dynamic typing as we have now. Strict typing would
require some global or config setting as I originally proposed; a
function-by-function approach obviously would only work with weak typing.
Looks like I got a bit dyslexic on you guys so I apologize for the
confusion.

That being said, I do believe that optional strict typing on a global
scale
is worthy of further discussion, though I remain on the fence as far as
whether or not we should actually go forward with that idea. But the
function-by-function approach (by which I mean weak typing lol) is
something that I'm increasingly convinced is a good idea.

--Kris

On Sun, Feb 26, 2012 at 4:09 PM, Arvids Godjuks <
arvids.godjuks@gmail.com>wrote:

I absolutely agree with this. The hurdle with the strict type hinting is
pictured very well. Strict is strict - either the whole codebase follows
it, or it doesn't follow it at all. If a part of the code uses it -
means
all the code comunicating with that part has to use, or at least has to
be
written with the strict type hinting in mind.

Oh, and i remembered a case where strict type hinting would be highly
questionable - the "mixed" variant. Right now we document thouse with
the
phpdoc comments, but its quite common use in php to accept a null or an
array for example. I can't imagine strict type hinting in this case, but
weak type hints can work.
27.02.2012 0:51 пользователь "John LeSueur" john.lesueur@gmail.com
написал:

[trim]

"Strict type hinting would eliminate PHP's flexibility and take
away
its
unique simplicity."

I respectfully disagree. Again, let me remind you that we are not
talking
about *converting *PHP to strict type hinting. Instead, we're merely
talking about allowing PHP developers to choose whether or not to
make a
given function use dynamic or strict type hinting. The default
behavior
will remain dynamic, just as it is now. But there are situations
where
strict type hinting, even in a PHP script, would make more sense.
There
are many PHP developers, myself among them, who see considerable
benefit
in
being able to make a function more condensed and streamlined without
having
to waste so much time on sanity checks that could instead be handled
at
a
lower level in the core.

So this is the argument that those who object to strict type hinting
don't
agree with. Take the following:

function strictTypes(/int/ $var)
{
//this is what the engine does if we have strict type checking
if(!is_int($var)) trigger_error();
}

function weakTypes(/int/ $var)
{
//this is what the engine does if we have weak type hinting, or
something similar.
if(!is_numeric($var) || (int)$var != $var) trigger_error();
else $var = (int)$var;
}

function dynamicTypes($var)
{
strictTypes((int) $var);
//if $var is not an int, we just made it 0, and hid the type
error.
//to avoid this mistake we have to do:
strictTypes(is_int($var) ? $var : ((is_numeric($var) && (int)$var
==
$var) ? (int)$var : trigger_error());
//or something like it.
weakTypes($var);
//we'll get an error if $var can't be converted to an int without
data
loss.
}

By calling the strictTypes() function, the dynamicTypes() function
inherits the problem of validating the type of $var. Well, if I'm
writing
the dynamicTypes function, I don't want that work, so I push it up the
chain, and change my dynamicTypes function to statically typed. If
you're
into static types, then you say, that's great, someone should make
sure
that $var has the right type when they got it from the user. But if
you're
not into static types, you were just forced to do type checking,
either
in
your code, or passing it up the call chain for someone else to do the
type
checking. That's what is meant when we say dynamic typing can't really
coexist with strict typing. For those into dynamic types, weak type
hinting
is much more palatable, because it doesn't require callers to adopt
the
same philosophy.

If you want type hinting, you'll have to specify which kind you want,
strict or weak. If it's strict type hinting, you'll need to convince
even
those who think dynamic typing is a guiding principle of PHP that it
can
be
done without forcing strict typing up the call chain. Weak type
hinting
is
a softer sell, but requires a lot of thought(much of which has been
done,
if you look in previous discussions) , about how and when to convert
values.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

14 years ago by keisial@gmail.com — view source — reply

unread

Exactly, hence why I'm still on the fence with that. I was hoping for some
further discussion though to see if anyone can think of a way around that,
though admittedly nothing comes to my mind.

--Kris
That's why I mentioned the possibility of having such option per file.

declare(stricttypes=1) {
// Code here
}

Or just
declare(stricttypes=1);
to apply to the whole file

14 years ago by John Crenshaw — view source — reply

unread

From: Kris Craig [mailto:kris.craig@gmail.com]

I actually agree as well. Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating.

Honestly, this is the biggest problem that the typing debates have had. Someone advocates "strict typing" when they really mean "weak typing" (as opposed to the current "dynamic typing") but there's always a group of people that assume they mean "strict strict strict typing like the old C days". People then panic and get frustrated because the plethora of problems with adding this level of restriction to PHP have already been discussed extensively. Discussion then devolves into denigration and then finally disintegrates completely.

If we can agree on some basic terminology I think it would move things forward considerably. I propose these terms:

"Strict Typing" means the super strict old C style typing that has been proven to be ridiculous in this environment because of the obvious problems inherent in the fact that almost every input is a string.
"Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".)
"No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)

In addition, if someone potentially new expresses support for "Strict Typing", let's assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Politely clarify terminology so that everyone can be on the same page. If someone still insists that they want "Strict Typing", point them to the prior discussions on the topic which explain exactly what the problems with this are.

It might be wise to maintain a wiki article to keep track of the 3 different levels of typing, as well as a summary of the typical arguments pro and con for each of the 3. If people agree that this would be helpful, I'm willing to dig through the archives and try to put this together.

John Crenshaw
Priacta, Inc.

14 years ago by Kris Craig — view source — reply

unread

Well said, John! I think that's a terrific idea!

--Kris

On Sun, Feb 26, 2012 at 5:44 PM, John Crenshaw johncrenshaw@priacta.comwrote:

From: Kris Craig [mailto:kris.craig@gmail.com]

I actually agree as well. Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating.

Honestly, this is the biggest problem that the typing debates have had.
Someone advocates "strict typing" when they really mean "weak typing" (as
opposed to the current "dynamic typing") but there's always a group of
people that assume they mean "strict strict strict typing like the old C
days". People then panic and get frustrated because the plethora of
problems with adding this level of restriction to PHP have already been
discussed extensively. Discussion then devolves into denigration and then
finally disintegrates completely.

If we can agree on some basic terminology I think it would move things
forward considerably. I propose these terms:

"Strict Typing" means the super strict old C style typing that has been
proven to be ridiculous in this environment because of the obvious problems
inherent in the fact that almost every input is a string.

"Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".)

"No Scalar Typing" should be used to indicate the current system (where
there is no provision for hinting at scalar types.)

In addition, if someone potentially new expresses support for "Strict
Typing", let's assume that they really mean weak typing unless proven
otherwise (this is by far the more likely intent.) Politely clarify
terminology so that everyone can be on the same page. If someone still
insists that they want "Strict Typing", point them to the prior discussions
on the topic which explain exactly what the problems with this are.

It might be wise to maintain a wiki article to keep track of the 3
different levels of typing, as well as a summary of the typical arguments
pro and con for each of the 3. If people agree that this would be helpful,
I'm willing to dig through the archives and try to put this together.

John Crenshaw
Priacta, Inc.

14 years ago by Clint M Priest — view source — reply

unread

+1 for that as well.

-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Sunday, February 26, 2012 7:48 PM
To: John Crenshaw
Cc: Arvids Godjuks; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Well said, John! I think that's a terrific idea!

--Kris

On Sun, Feb 26, 2012 at 5:44 PM, John Crenshaw johncrenshaw@priacta.comwrote:

From: Kris Craig [mailto:kris.craig@gmail.com]

I actually agree as well. Looking back in the thread, I think my
overly broad use of the word "strict" might have led to some
confusion over what I'm advocating.

Honestly, this is the biggest problem that the typing debates have had.
Someone advocates "strict typing" when they really mean "weak typing"
(as opposed to the current "dynamic typing") but there's always a
group of people that assume they mean "strict strict strict typing
like the old C days". People then panic and get frustrated because the
plethora of problems with adding this level of restriction to PHP have
already been discussed extensively. Discussion then devolves into
denigration and then finally disintegrates completely.

If we can agree on some basic terminology I think it would move things
forward considerably. I propose these terms:

"Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the
obvious problems inherent in the fact that almost every input is a string.

"Weak Typing" means types in the same sense that the PHP
documentation uses types (for example, the docs indicate
substr(string, integer), and substr(12345, "2") == "345".)

"No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)

In addition, if someone potentially new expresses support for "Strict
Typing", let's assume that they really mean weak typing unless proven
otherwise (this is by far the more likely intent.) Politely clarify
terminology so that everyone can be on the same page. If someone still
insists that they want "Strict Typing", point them to the prior
discussions on the topic which explain exactly what the problems with this are.

It might be wise to maintain a wiki article to keep track of the 3
different levels of typing, as well as a summary of the typical
arguments pro and con for each of the 3. If people agree that this
would be helpful, I'm willing to dig through the archives and try to put this together.

John Crenshaw
Priacta, Inc.

14 years ago by Samuel Deal — view source — reply

unread

+1 as well,

I start a new thread for that.
This debate is major for PHP's futur.

I'm little frustrated about this thread,
I don't have any new argument for or against the enum proposal.

2012/2/27 Clint M Priest cpriest@zerocue.com

+1 for that as well.

-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Sunday, February 26, 2012 7:48 PM
To: John Crenshaw
Cc: Arvids Godjuks; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)

Well said, John! I think that's a terrific idea!

--Kris

On Sun, Feb 26, 2012 at 5:44 PM, John Crenshaw <johncrenshaw@priacta.com

wrote:

From: Kris Craig [mailto:kris.craig@gmail.com]

I actually agree as well. Looking back in the thread, I think my
overly broad use of the word "strict" might have led to some
confusion over what I'm advocating.

Honestly, this is the biggest problem that the typing debates have had.
Someone advocates "strict typing" when they really mean "weak typing"
(as opposed to the current "dynamic typing") but there's always a
group of people that assume they mean "strict strict strict typing
like the old C days". People then panic and get frustrated because the
plethora of problems with adding this level of restriction to PHP have
already been discussed extensively. Discussion then devolves into
denigration and then finally disintegrates completely.

If we can agree on some basic terminology I think it would move things
forward considerably. I propose these terms:

"Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the
obvious problems inherent in the fact that almost every input is a
string.

"Weak Typing" means types in the same sense that the PHP
documentation uses types (for example, the docs indicate
substr(string, integer), and substr(12345, "2") == "345".)

"No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)

In addition, if someone potentially new expresses support for "Strict
Typing", let's assume that they really mean weak typing unless proven
otherwise (this is by far the more likely intent.) Politely clarify
terminology so that everyone can be on the same page. If someone still
insists that they want "Strict Typing", point them to the prior
discussions on the topic which explain exactly what the problems with
this are.

It might be wise to maintain a wiki article to keep track of the 3
different levels of typing, as well as a summary of the typical
arguments pro and con for each of the 3. If people agree that this
would be helpful, I'm willing to dig through the archives and try to put
this together.

John Crenshaw
Priacta, Inc.

--

--
Samuel DEAL
samuel.deal@gmail.com
Tél : +36 (0) 6.01.29.75.85
Adresse : 44, rue Jean Jaurès
92170 Vanves

14 years ago by keisial@gmail.com — view source — reply

unread

If we can agree on some basic terminology I think it would move things forward considerably. I propose these terms:

"Strict Typing" means the super strict old C style typing that has been proven to be ridiculous in this environment because of the obvious problems inherent in the fact that almost every input is a string.

"Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".)

"No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)
I'd add a fourth class, in between weak and strict typing, where a
diagnostic is issued when the requested conversion doesn't make sense.
Let's call it sane weak typing. The following would work:

function score(int $number) {
global $points, $total;
$points += $number;
$total++;
}

score(42);
score(1.0);
score("7");

but these would generate a diagnostic:
score(" Mary had a little lamb");
score( array(3, 27, 45) );
score( new stdclass );
score( fopen("myfile.txt", "w") );

(note that in some of these cases, the += operator would already produce
a fatal error)

14 years ago by keisial@gmail.com — view source — reply

unread

Kris Craig

I usually just read the list, sometimes add if I have something to say and
I had voiced my opinion on typehinting before. And you know, just from the
stand of a userland developer who has 7-8 years of experience and devoting
myself to the excelence at PHP, i see this discussion about adding strict
typehinting to PHP as ridicilous. I cannot express my thrustration, because
i would probably be kicked out of the list permanently.
The problem is that those, who are actually advocating for this, come from
all sorts of languages (or have moved to them some time ago) and now what
to "make php better". Sorry folks, but I have picked up a script language
not because it has strict type hinting, but actually because it does not
have it. And because in web we are working with text. Almost any data we
get is text and in critical places we just check that data we have is
actually a number and not a random string. Or is an object of certain type.
Or is an array. Or a valid string. And we let the PHP to handle routine
conversions. And it's good because there can be tons of them per single
script call. String to number and vice-verse conversions are all over the
place in almost any script. They are so common, that if you would add
strict typehinting - you would probably need a type conversion on every
function/method call.
I'm not so sure about that. In a well-written web application, you would
typically convert them on the first layer, when receiving from the web.
On next usages, your int variables are usually ints already.

Anyway, you seem to think that people is advocating to add strict typing
to the language, while I haven't seen that in this thread. Only to add type
hinting (and this all began with an enum proposal!), which could be either
strict or weak.
Some people positioned against typehints, have been much more vocal
against strict, of course, as that has much more ground.

14 years ago by Kris Craig — view source — reply

unread

Bleh well that's just semantics. Strict typing / type hinting is what I'm
talking about; not specifically advocating one or the other.

And yeah this started as an enum proposal, but it came back to this issue.
I offered to move this to a separate topic but everyone seems content to
just keep talking about it here. I honestly don't care either way. So
long as this important discussion isn't just "tabled" yet again I'm good.

--Kris

2012/2/26 Ángel González keisial@gmail.com

Kris Craig

I usually just read the list, sometimes add if I have something to say
and
I had voiced my opinion on typehinting before. And you know, just from
the
stand of a userland developer who has 7-8 years of experience and
devoting
myself to the excelence at PHP, i see this discussion about adding strict
typehinting to PHP as ridicilous. I cannot express my thrustration,
because
i would probably be kicked out of the list permanently.
The problem is that those, who are actually advocating for this, come
from
all sorts of languages (or have moved to them some time ago) and now what
to "make php better". Sorry folks, but I have picked up a script language
not because it has strict type hinting, but actually because it does not
have it. And because in web we are working with text. Almost any data we
get is text and in critical places we just check that data we have is
actually a number and not a random string. Or is an object of certain
type.
Or is an array. Or a valid string. And we let the PHP to handle routine
conversions. And it's good because there can be tons of them per single
script call. String to number and vice-verse conversions are all over the
place in almost any script. They are so common, that if you would add
strict typehinting - you would probably need a type conversion on every
function/method call.
I'm not so sure about that. In a well-written web application, you would
typically convert them on the first layer, when receiving from the web.
On next usages, your int variables are usually ints already.

Anyway, you seem to think that people is advocating to add strict typing
to the language, while I haven't seen that in this thread. Only to add type
hinting (and this all began with an enum proposal!), which could be either
strict or weak.
Some people positioned against typehints, have been much more vocal
against strict, of course, as that has much more ground.

14 years ago by Richard Lynch — view source — reply

unread

I'm not so sure about that. In a well-written web application, you
would
typically convert them on the first layer, when receiving from the
web.
On next usages, your int variables are usually ints already.

Afraid not.

It turns out that PHP, on 32-bit hardware, converting large BIGINT
using (int) $ID ends up as a negative number, and then when you pass
it in to the database if a string query, you get a negative ID, not at
all what was intended.

(Been there, done that, got burned)

At least, that's been my experience with some versions of PHP and some
database drivers.

So at least the database IDs have to remain as strings, if you are
using BIGINT.

You could, of course, only convert the values known to be in range of
PHPs positive integers, and leave the others as strings.

This is just a simple example of how the super strict typing simply
doesn't work out too well in PHP.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

14 years ago by keisial@gmail.com — view source — reply

unread

I'm not so sure about that. In a well-written web application, you
would
typically convert them on the first layer, when receiving from the
web.
On next usages, your int variables are usually ints already.
Afraid not.

It turns out that PHP, on 32-bit hardware, converting large BIGINT
using (int) $ID ends up as a negative number, and then when you pass
it in to the database if a string query, you get a negative ID, not at
all what was intended.

(Been there, done that, got burned)

At least, that's been my experience with some versions of PHP and some
database drivers.

So at least the database IDs have to remain as strings, if you are
using BIGINT.

You could, of course, only convert the values known to be in range of
PHPs positive integers, and leave the others as strings.

This is just a simple example of how the super strict typing simply
doesn't work out too well in PHP.
That's a good example from experience.
Although if you want to keep ids as strings, you can simply keep them as a
string type.
I was thinking on input coming from a web browser, btw.

14 years ago by Chris Stockton — view source — reply

unread

Why is it every time this comes up people need to get butt hurt and
passionate? Re-read past discussions and provide new arguments or move on.
This is likely a feature that will never exist, but don't worry... You can
still make websites using PHP :)

Inline, we go....

--Kris

On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev <smalyshev@sugarcrm.com

wrote:

Hi!

I'm well aware that this has been discussed before, Stas. However,

you're mischaracterizing those previous conversations. It has never
been proven that optional strict typing doesn't work. You've made the
same arguments against it, but those arguments have counter-arguments
that are also viable.

I'm not sure what you mean by "proven". You expect rigorous mathematical
proof? You're not getting one. If you have something new to say with
regard
to the arguments that were brought up 10 times already - ok, go ahead.
But
please read them first.

Another logical fallacy. Cognitive dissonance. Either there is "rigorous
mathematical proof" or a statement is completely unproven (and/or cannot be
proven).

In fact, you haven't proven your point by any standard, rigorous or
otherwise. There is no basis for suggesting that it cannot be done.
You've clearly stated that you don't think it should be done, but you
haven't viably demonstrated that it can't be done, or that it would
"break" PHP as we know it.

people keep asking for it. It keeps coming up because, despite

belittling and dismissive comments made by yourself and a few others,
people continue to see that there is, in fact, a valid argument for
implementing this. It shows that you have never been able to convince
those who don't already agree with you that this is impossible.

Or it's coming up because people don't bother to read past discussions
and
think they are first who thought "let's put strict typing in PHP" and
only
reason why it's not there because nobody was smart enough to think about
it. It's not so. It was repeatedly discussed and rediscussed. If you have
new argument - fine, we'd all be happy to hear it. So far I didn't hear
one
though. Please let us hear it.

No, it's coming up because people have read these past discussions and
still think it's a reasonable goal that deserves further consideration.
Your assumption that anyone who disagrees with you must not have read or
even be aware of the existence of previous threads on this topic is a good
example of your arrogant belittling of and disrespect toward them.

Your premise seems to rely on the notion that, since this was previously
discussed but not implemented, this idea was resoundingly rejected. On the
contrary, it looks to me more like it either fizzled or was punted each
time, but no consensus was ever reached. Therefore, further discussion is
warranted. The fact that this was discussed previously does not make this
topic any less legitimate.

remotely like that. On the contrary, the PHP language would remain

largely unchanged; we'd merely be adding a new element to it.

It doesn't work that way. Language is a complex construct, with all parts
influencing each other, thinking you can just add strict typing somewhere
in the corner and nothing changes is a dangerous illusion. It would not
work. If you type function arguments, you should also type all the
variables that could end up as the function arguments, all the functions
returning into those arguments and all the operators and functions that
do
any transformations over those things. Otherwise it is guaranteed to blow
up in runtime. After doing that, you've got yourself a strictly typed
language. Absent compiler, though, such language would be quite hard to
operate - how do you know your code correctly uses all the types some
library wants? How do you know next version doesn't change any types
without you noticing? etc., etc.

You're operating on a number of unfounded assumptions here (a "house of
cards" if you will). First, nobody is saying that this wouldn't be a
significant undertaking at the core development level. We all agree that
it would be. However, you're once again introducing cognitive dissonance
into this. The same logic you're using could be used to say that solid OO
classes shouldn't be implemented because it would then render procedural
scripting impossible. After all, "all parts influence each other," as you
put it. However, everything didn't blow up when PHP 5 was released.
People can still write purely procedural code just like they did before.

Language is complex, yes; but it is also flexible. We've already discussed
previously in this thread how these interactions between strinct and
dynamic functions could take place.

So, your argument that this would be "guaranteed to blow up in runtime" and
that, therefore, we would be stuck with a purely strict-typed language is
based on a faulty premise. The house of cards collapses.

Don't get me wrong; there are plenty of fine details that would need to be
figured out. But again, complexity != impossibility. It can be done, and
it can be done in a way that won't cause the world to come to an end.

Furthermore, I have spoken to numerous people who have complained about

PHP code being overly bulky and/or difficult to read due to its
mandatory dynamic typing. Your counter-argument to that was,

I think these people are mistaken. PHP code, as in any language, may be
well written or purely written, however this has nothing to do with
dynamic
typing. There are dynamically and statically typed languages, both have
their uses. Static typing is well fit for compiled languages since
compiling allows pre-execution type control and thus ensures no surprises
in runtime.
If you would like to explain yourself more in detail and specifically
describe which code is "bulky and hard to read" due to dynamic typing -
please do so.

PHP may not be compiled, but it does plenty of "pre-runtime" sanity checks.
That's when things like parse errors are caught.

As for an example, please refer to earlier posts on this thread, as that
has already been provided.

essentially, "Yeah, well they're all stupid!" No, they're not. They

If you're going to distort my words and assign me things that I never
said
I would just stop this discussion and instead will silently delete
everything you send. No sane discussion can be held in this manner, so
please show respect to yourself and everybody participating and never do
this again.

You should re-read your statements before you accuse others of distorting
them. Here's the exact quote of what you said:

"If somebody finds PHP much more difficult to read than C++, well, he
obviously has a very different concept of reading than the rest of the
humankind."

In other words, anyone who think PHP is harder to read is obviously not as
smart as the rest of the human race (at least when it comes to reading
comprehension). So yes, you were basically saying that these people are
stupid. You've been consistently belittling those who disagree with you,
like accusing all of them of being ignorant of previous threads on this
topic, etc.

I stand by what I said. Much of your rhetoric consists of you looking down
your nose at everyone who disagrees with you. Don't dish it out of you
can't take it. ;P

And again, you're using the, "If you don't like PHP, then get the hell

out and use a different language," argument (i.e. "If one needs strict
typed compiled language, one knows where to find plenty of them."). As
I said in a previous post, that argument carries ZERO weight with me,
and I'm not the only one who feels that way.

PHP is built on a certain principles, and people that build and maintain
PHP would like to continue developing it along these principles. You
think
the proper language should be based on different set of principles - it
is
your right, however this language would not be PHP. There's nothing wrong
with that, and pointing out that fact is not "dismissive". It is just a
reminder that each language should have some principles. If you want to
discuss why these principles are there - fine, but I mus warn you that it
is rather unlikely that these principles will be thrown out and replaced
with entirely new ones.

Another logical fallacy. You're attempting to redefine the debate on the
grounds that mandatory dynamic typing is one of the founding "principles"
that PHP stnads for, even though you have zero basis for making that claim
other than the fact that PHP in its current form does not support strict
typing (that same argument could be used to reject any new feature to PHP
that touches the language). That would be like saying that English is no
longer English because we've added some new words to the dictionary and
modified some of the grammar rules (Oxford Comma, anyone?).

So no, we're not talking about turning PHP into a different language.
We're not tearing everything down and starting from scratch. Hell, what
we're talking about wouldn't even break compatibility with existing
scripts! This sort of radical hyperbole does not justify being dismissive
of those who are making a legitimate argument that you happen to disagree
with. It's not constructive, and it's probably hyperbole like this that
makes people less likely to continue discussion threads on this topic.
After all, I'm sure nobody here would like the idea of being seen as
trying to "kill PHP".

should be discussed. So let's drop the arrogant, "We've already talked

about this stupid thing before," crap right here and now because it's
not going to change anything.

I would also ask you to please amend your tone and avoid name-calling,
swearing and otherwise rude expressions on the list. I understand that
some
topics can make one passionate, however I think remaining within the
bounds
of polite and civilized tone of discussion is not too much to ask.

What name-calling, exactly? The word "arrogant" is an adjective, not a
noun.

It sounds like you're trying to imploy the old, "I'm rubber, you're glue"
approach; i.e. hoping to cancel-out my criticism of your disrespectful tone
by repeated the same accusation toward me. I could then counter with the
classic, "Well you started it!" but that wouldn't serve any purpose, now
would it?

Like I said before, if you are dismissive and disrespectful of the other
side, they in turn will develop a more hostile tone toward you. It's basic
human nature and perfectly understandable. If you've suddenly come around
and decided you want to have a respectful conversation, I'm all for it!
But you need to take responsibility for your own attitude and remember
that the opinions of those who disagree with you are no less valid than
your own.

I'd really prefer that this thread not devolve into a cliche flame war.
That's probably what killed some of the past discussions. However, we've
procrastinated on this long enough IMHO. These extremely prevelent
concerns are not going to just "go away" and ignoring them or belittling
them won't change that. The status quo is rarely a blueprint for
perfection. =)

--Kris

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Richard Lynch — view source — reply

unread

On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev
smalyshev@sugarcrm.comwrote:

Hi!

I'm well aware that this has been discussed before, Stas. However,

you're mischaracterizing those previous conversations. It has
never
been proven that optional strict typing doesn't work. You've made
the
same arguments against it, but those arguments have
counter-arguments
that are also viable.

I'm not sure what you mean by "proven". You expect rigorous
mathematical
proof? You're not getting one. If you have something new to say with
regard
to the arguments that were brought up 10 times already - ok, go
ahead. But
please read them first.

Another logical fallacy. Cognitive dissonance. Either there is
"rigorous
mathematical proof" or a statement is completely unproven (and/or
cannot be
proven).

Are you going to completely dismiss statistical probability somewhere
in the middle of the two?

People a whole lot smarter than I, and, forgive me, but some of them
probably smarter than you, have tried this again and again and again.

They all failed.

They failed exactly for the reasons Stas pointed out:

You can't change just one thing.

The changes have repercussions, and in this particular instance, those
repercussions dig into the heart and soul of PHP, to the point where
you would, quite literally, have to change PHP INTO JSP or similar.

In fact, you haven't proven your point by any standard, rigorous or
otherwise. There is no basis for suggesting that it cannot be done.
You've clearly stated that you don't think it should be done, but
you
haven't viably demonstrated that it can't be done, or that it would
"break" PHP as we know it.

The problem is probably NP-incomplete, though I have no proof for even
that statement, other than my "gut" telling me it is so.

I certainly have not the time nor inclination to "prove" the
completeness or lack thereof for adding static typing to PHP.

Perhaps a trained mathematician (like me) who has kept his skills up
(unlike me) would take a "go" at it. :-)

people keep asking for it. It keeps coming up because, despite

belittling and dismissive comments made by yourself and a few
others,
people continue to see that there is, in fact, a valid argument for
implementing this. It shows that you have never been able to
convince
those who don't already agree with you that this is impossible.

Or it's coming up because people don't bother to read past
discussions and
think they are first who thought "let's put strict typing in PHP"
and only
reason why it's not there because nobody was smart enough to think
about
it. It's not so. It was repeatedly discussed and rediscussed. If you
have
new argument - fine, we'd all be happy to hear it. So far I didn't
hear one
though. Please let us hear it.

No, it's coming up because people have read these past discussions and
still think it's a reasonable goal that deserves further
consideration.

In the abstract ideal, it's quite reasonable.

The devil is in the details. It can't be done, without completely
re-writing PHP into something akin to a different language.

This conclusion has been reached multiple times, with multiple
proposals and attempts, including a lot of patches, some that went
very far down the path before they failed, and were abandoned.

On the
contrary, it looks to me more like it either fizzled or was punted
each
time, but no consensus was ever reached. Therefore, further
discussion is
warranted. The fact that this was discussed previously does not make
this
topic any less legitimate.

They all fizzled or punted because the enormity of the problem space
turned out to be insurmountable.

This is not to say you CANNOT succeed: Only that every attempt before,
and they are legion, has failed.

It doesn't work that way. Language is a complex construct, with all
parts
influencing each other, thinking you can just add strict typing
somewhere
in the corner and nothing changes is a dangerous illusion. It would
not
work. If you type function arguments, you should also type all the
variables that could end up as the function arguments, all the
functions
returning into those arguments and all the operators and functions
that do
any transformations over those things. Otherwise it is guaranteed to
blow
up in runtime. After doing that, you've got yourself a strictly
typed
language. Absent compiler, though, such language would be quite hard
to
operate - how do you know your code correctly uses all the types
some
library wants? How do you know next version doesn't change any types
without you noticing? etc., etc.

You're operating on a number of unfounded assumptions here (a "house
of
cards" if you will). First, nobody is saying that this wouldn't be a
significant undertaking at the core development level. We all agree
that
it would be. However, you're once again introducing cognitive
dissonance
into this. The same logic you're using could be used to say that
solid OO
classes shouldn't be implemented because it would then render
procedural
scripting impossible. After all, "all parts influence each other," as
you
put it. However, everything didn't blow up when PHP 5 was released.
People can still write purely procedural code just like they did
before.

That was actually a quite different set of circumstances altogether.

It was a very heated topic, but few people who actually hacked core
claimed it was "impossible." They may not have liked the idea, nor
some of the decision along the way, but few claimed it was
"impossible"

Stas, who has probably hacked core almost as much as anybody, is
telling you that it's impossible. You really should consider that
opinion. (Mine, of course, carries zero weight. I still haven't
submitted the trivial patch Rasmus asked for ~15 years ago.)

You could create a whole new language, completely "independent" of
PHP, and merge it with the PHP language, and essentially have two
languages in one, and get what you want, I suppose...

They'd have to have totally separate and non-interchangeable
base-types, functions etc.

With a great deal of effort, you might even be able to add
type-juggling operators that could "auto-convert" between PHP and your
strict PHP, though I should think that would sort of defeat the
purpose of strict PHP to a large extent...

But to attempt to make variables / functions / parameters totally
strict, or even partially strict, simply implies changing core PHP to
the extent that you've re-written the whole language.

Don't get me wrong; there are plenty of fine details that would need
to be
figured out. But again, complexity != impossibility. It can be done,
and
it can be done in a way that won't cause the world to come to an end.

Feel free to continue to try.

That would be the best way to prove your assertions, and show Stas wrong.

Or, you must admit, if he is right, you'd eventually find that out as
well.

For your first efforts, I'd suggest that examining the historical
record of previous attempts, and where they hit the brick wall, would
be good background research.

It's easy to START the race to add strict typing. And it's moderately
difficult but do-able to make a lot of progress. Nobody who has tried
has finished yet. Ignoring past attempts with major patches that
simply failed would be... unwise. :-)

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

14 years ago by Richard Lynch — view source — reply

unread

I hear that a lot; i.e. "If you want static typing, use Java."

Unfortunately, that dismissive answer has not worked too well over the
years, has it? People are still clamoring for this, and I think
making
some very valid arguments that shouldn't be so derisively and
flippantly
brushed aside.

I did not mean to be flippant, and was quite sincere, so allow me to
restate it:

This idea has been floated many times.

Sometimes, it even came with initial patches to "prove" it could be
done, and was feasible.

Every time, eventually, non-trivial issues were raised by Core Devs
that could simply NOT be addressed by the proposer, and they realized
that changing PHP at such a fundamental level was, indeed, a
non-starter. Or at least a non-finisher. :-)

I only meant to suggest that if you seriously WANT these features in
your language, switching to Java and JSP will give them to you,
without the pain and suffering of a TON of work that history has shown
will 99.9999% sure end in failure.

I am, again, not being flippant, nor trying to claim that PHP is not
an evolving language.

I am, still, stating that the probability of it evolving in this
direction, after it has been tried and failed so MANY times in the
past, is incredibly unlikely.

Examine the historical record, and the many proposed patches / changes
/ ideas, and I sincerely believe you will come to the same conclusion.

If you really think you can pull it off, despite the historical
evidence, I suggest you start to make a patch to do so, and find out
just how much you are biting off to chew.

In essence, you will effectively be re-writing Java / JSP or something
similar, while trying to maintain compatibility with PHP and PHP
internals that rely extensively on dynamic typing.

To bowlderize Clemens (?) with regard to typing:

"Strict is strict, and dynamic is dynamic, and never the twain shall
meet."

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

14 years ago by keisial@gmail.com — view source — reply

unread

I don't see your point, Sebastian.

And

| $studipNamedVariable = Databases::Mysql;
| // ... much code
| database_select($stupidNamedVariable, $sql);

is better? The problem here seems to be more the developer, that
avoids the use of constants, then less the missing enums.
You can obviously do weird things, as with in any feature. In this case
you bring up, I see little sense in passing enums in variables, unless
that comes itself from a parameter for that function, or comes from an
external source, like a configuration data.

If you use a constant like

| Databases::Mysql = 1024;

the call

| database_select(Database::IDontExists, $sql);

will fail too. Other examples, that supports type hints, can be found
in other mails around here.
Yes. With a parser error as IDontExists doesn't belong to Database enum.
How does it relate with assigning 1024 to Databases::Mysql ?

[RFC] Enum proposal (yet another) View as Markdown

Thanks

Thanks

Thanks

Thanks

Thanks

Thanks

Thanks

You should not. PHP is not a strictly typed language, so if you want strictly typed function you'll get in trouble, for the same reasons why strict scalar typing wasn't a good idea - you may want to re-read these discussions.

Regards

-- Lester Caine - G8HFL

I would also ask you to please amend your tone and avoid name-calling, swearing and otherwise rude expressions on the list. I understand that some topics can make one passionate, however I think remaining within the bounds of polite and civilized tone of discussion is not too much to ask.

You should not. PHP is not a strictly typed language, so if you want
strictly typed function you'll get in trouble, for the same reasons why
strict scalar typing wasn't a good idea - you may want to re-read these
discussions.

--
Lester Caine - G8HFL

I would also ask you to please amend your tone and avoid name-calling,
swearing and otherwise rude expressions on the list. I understand that
some topics can make one passionate, however I think remaining within
the bounds of polite and civilized tone of discussion is not too much to
ask.