On Mon, February 27, 2012 5:21 pm, Ángel González wrote:
> On 27/02/12 19:22, Richard Lynch wrote:
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 varia
On 27/02/12 19:22, Richard Lynch wrote:
>>> 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 th
>> 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 BIGI
On Sat, February 25, 2012 7:58 pm, Kris Craig wrote:
> On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev
> 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 opt
On Fri, February 24, 2012 4:33 pm, Kris Craig wrote:
> 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 th
On 27/02/12 02:44, John Crenshaw wrote:
> 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
On 27/02/12 01:33, Kris Craig wrote:
> 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 s
-
> From: Kris Craig [mailto:kris.cr...@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!
>
+1 for that as well.
-Original Message-
From: Kris Craig [mailto:kris.cr...@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
Well said, John! I think that's a terrific idea!
--Kris
On Sun, Feb 26, 2012 at 5:44 PM, John Crenshaw wrote:
> > From: Kris Craig [mailto:kris.cr...@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
> From: Kris Craig [mailto:kris.cr...@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. Some
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
> There's no such thing as optional global anything, if you're a libra
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.
On Sun, Feb 26, 2012 at 7:30 PM, Kris Craig wrote:
> I actually agree as well. Looking back in the thread, I think my overly
> broa
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
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
writ
[trim]
> 2. "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 develop
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 tal
On 26/02/12 05:11, Arvids Godjuks wrote:
> 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
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 :)
On Feb 25, 2012 6:59 PM, "Kris Craig" wrote:
>
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
disa
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 ad
Inline, we go
--Kris
On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev 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'v
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
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.
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 languag
> From: Arvids Godjuks [mailto:arvids.godj...@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,
> witc
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
n
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
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
> -Original Message-
> From: Lester Caine [mailto:les...@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 languag
On 24/02/12 19:35, Kris Craig wrote:
> 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
Hi Kris,
You're right it wasn't clearly expresseded. Lets see if I can
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 argumen
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 P
On Thu, February 23, 2012 1:21 pm, Kris Craig 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:
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
> On 24/02/12 00:36, Kris Craig wrote:
> > Hmm that's a fascinating idea! So, and
On 24/02/12 00:36, Kris Craig wrote:
> 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 cou
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
> 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 determin
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 ty
On 23/02/12 23:49, Kris Craig wrote:
> 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 talkin
On 02/23/2012 11:49 PM, Kris Craig wrote:
[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 PH
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 wr
On 23/02/12 22:59, Kris Craig wrote:
> 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
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 thin
Am 23.02.2012 21:21, schrieb Ángel González:
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 l
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 ob
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 s
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 ques
Am 23.02.2012 20:01, schrieb Ángel González:
On 23/02/12 00:09, Stas Malyshev wrote:
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 i
On 23/02/12 00:09, Stas Malyshev wrote:
> 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 functi
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
; From: Stas Malyshev [mailto:smalys...@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 w
rovider in 2011"
-Original Message-
From: Stas Malyshev [mailto:smalys...@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 k
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 thi
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
st
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://j
On 22/02/12 23:13, Kris Craig wrote:
> 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.
--
PHP Internals - PHP Runtime Development Mailing Li
Am 22.02.2012 22:30, schrieb Sebastian Krebs:
> Am 22.02.2012 22:22, schrieb Ángel González:
>> 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;
20-4640 x 2097
> Fax: (888) 795-6642
> E-Mail: dsnytk...@ultralogistics.com
> Web: www.ultralogistics.com
>
> "A Top 100 Logistics I.T. Provider in 2011"
>
>
> -Original Message-----
> From: Sebastian Krebs [mailto:krebs@googlemail.com]
> Sent: Wednesda
795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
"A Top 100 Logistics I.T. Provider in 2011"
-Original Message-
From: Sebastian Krebs [mailto:krebs@googlemail.com]
Sent: Wednesday, February 22, 2012 4:31 PM
To: PHP internals list
Subject: Re:
Am 22.02.2012 22:22, schrieb Ángel González:
On 22/02/12 09:37, Sebastian Krebs wrote:
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
UnexpectedV
On 22/02/12 09:37, Sebastian Krebs wrote:
> 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 =
: www.ultralogistics.com
>
> "A Top 100 Logistics I.T. Provider in 2011"
>
>
> -Original Message-
> From: Samuel Deal [mailto:samuel.d...@gmail.com]
> Sent: Tuesday, February 21, 2012 11:46 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [RFC]
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
:46 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC] Enum proposal (yet another)
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, a
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
On Wed, Feb 22, 2012 at 5:45 AM, Samuel Deal wrote:
> Hi all,
>
> I really missed enums in PHP,
> So after reading I tryed to synthetise the various views.
>
>
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 multipl
2012/2/22 Charlie Somerville
> 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
>}
>
>
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) {
// ...
}
The
On Wed, Feb 22, 2012 at 12:45 PM, Samuel Deal 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 o
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
70 matches
Mail list logo
