Agreed. Just to clarify in case my post confused anyone, we are not (at
least to the best of my knowledge) in the process of developing the 6.0
release right now, nor am I suggesting that the ideas I floated should be
in 5.x. I apologize if I made anyone scratch their heads needlessly lol.
So ye
Hi,
Discussion disperses a way I didn't expect.
As far as I know, next PHP release will be the 5.5, and would have a
strong compatibility
with 5.4.
So strict typing would not happened for 5.5 release.
If I understand correctly, at best, PHP 5.5 will have weak type hinting
(like
https://wiki.php.
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
Hi!
If I create a callback with either of these values:
* $callback = 'Foo::bar';
* $callback = array('Foo', 'Bar');
is_callable() now returns true. In PHP 5.2 and 5.3, it returned false,
which is what I'd expect.
I tried the code from the bug and it returned true for me in 5.3:
c
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
I reported a bug some weeks ago regarding how is_callable() works in PHP
5.4:
https://bugs.php.net/bug.php?id=51527
Here's the situation:
class Foo
{
public function bar()
{
return __METHOD__;
}
}
If I create a callback with either of these va
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,
> (Hint: __wakeup() isn't called).
>
This looks to be the same as https://bugs.php.net/bug.php?id=60879. Can
you
try the build I linked to in that report and see if it resolves this issue
for you?
It does. Thanks!
- Timm
--
PHP Internals - PHP Runtime Development Mailing List
To u
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
In me experience the more errors are thrown (instead of hidden and
recovered from) the better - you will clear much quicker the bugs.
If we have this case as recoverable (and possibly others) then you would
have to write a some of try/catchs... Instead you can avoid throwing the
errors by writing
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 use
And with the latter, you've reduced the amount of checks you have to
do, by putting them in the proper places (if baby and mother objects
inherit from the same class you've essentially got one check on null
inside getMother(), not many spread out in client code). Also, the
client code now only kn
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: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
"A Top 100 Logistics I.T. Provider in 2011"
-Origina
23 matches
Mail list logo