On 21/04/16 20:11, Fleshgrinder wrote:
> On 4/20/2016 11:03 PM, Stanislav Malyshev wrote:
>> No of course not. The specific instance of error you had *this time* may
>> be solved. The problem won't be. You still have to deal with:
>> - How this object is initialized? How you ensure it *is* initiali
On 4/21/16 2:11 PM, Fleshgrinder wrote:
What I love about PHP is that we have a lot under one hood:
multi-paradigm as well as loose and strict types. This allows one to
choose the best tool for the current job.
^^ That thing. PHP is a very eclectic language. That's a good thing.
Does that
On 4/20/2016 11:03 PM, Stanislav Malyshev wrote:
> No of course not. The specific instance of error you had *this time* may
> be solved. The problem won't be. You still have to deal with:
> - How this object is initialized? How you ensure it *is* initialized and
> that initialization is correct (0
On 4/21/2016 2:52 AM, Lester Caine wrote:
> PHP5.4 http://lsces.org.uk/ 0.41s 3.65Mb
> PHP5.6 http://php6.lsces.org.uk/ 0.54s 11.77Mb
> PHP7 http://php7.lsces.org.uk/ 0.45s 1.83Mb
>
> Same set of code ... 3 different fpm instances
> PHP5.2 one with eaccelerator will not run :( but I thin
On 20/04/16 21:11, Fleshgrinder wrote:
> I do not see a single reason why you would need to change anything if
> you are not requiring any of the new features and would say that the
> only reason to upgrade for you is security patches.
>
> However, I hardly believe that you cannot see a speed impr
On 20/04/16 21:01, Stanislav Malyshev wrote:
>> The outcome is easy to grasp. Because it did not crash by a TypeError
>> > (which would also require the file to be declared as strict), and we lost
>> > 100k in sales. But PHP does not need more strictness...
> In other words, somebody wrote code tha
> You're blaming humans (devs, testers etc) for a problem which could have
> been caught automatically (by a strictly enforced type annotation). It
This particular problem maybe could. But it is a symptom of a systemic
issue (bad design, bad testing) - curing symptom and leaving the disease
is li
Hi!
> The question here is how type strictness would benefit the language.
> I agree with you on most parts. But still... if the class was declared
> like this:
>
> class CancelOutdatedOrdersDTO {
> public int $olderThan;
> }
>
> Wouldn't that be solved entirely? Code would crash (through a
> On 20 באפר׳ 2016, at 23:33, Jesse Schalken wrote:
>
> You're blaming humans (devs, testers etc) for a problem which could have
> been caught automatically (by a strictly enforced type annotation). It
> follows that you actually *want* writing PHP software to be inefficient,
> labour intensive
You're blaming humans (devs, testers etc) for a problem which could have
been caught automatically (by a strictly enforced type annotation). It
follows that you actually *want* writing PHP software to be inefficient,
labour intensive and error-prone.
On Thu, Apr 21, 2016 at 6:01 AM, Stanislav Maly
I do not see a single reason why you would need to change anything if
you are not requiring any of the new features and would say that the
only reason to upgrade for you is security patches.
However, I hardly believe that you cannot see a speed improvement; or at
least less memory consumption.
--
The question here is how type strictness would benefit the language.
I agree with you on most parts. But still... if the class was declared like
this:
class CancelOutdatedOrdersDTO {
public int $olderThan;
}
Wouldn't that be solved entirely? Code would crash (through a TypeError),
it would ne
On Wed, Apr 20, 2016 at 2:01 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > The outcome is easy to grasp. Because it did not crash by a TypeError
> > (which would also require the file to be declared as strict), and we lost
> > 100k in sales. But PHP does not need more strictness...
>
> In other words
Hi!
> The outcome is easy to grasp. Because it did not crash by a TypeError
> (which would also require the file to be declared as strict), and we lost
> 100k in sales. But PHP does not need more strictness...
In other words, somebody wrote code that is supposed to only accept ints
but does no ch
You can continue to use arrays for database records like you always have
been. None of the new or proposed features are going to stop you.
The concept of type annotations and type systems really has nothing to do
with databases directly. It's about adding certainty with regards to the
types that a
I might answer you by given a scenario that happened this week here at work.
Because our non-broken language relies on a loose type system, a developer
of my company wrote a property that accepts null, int, string, object,
whatever as a property.
This property was declared in a class that is used
With all of the debate on the 'type system', can I just ask a probably
silly question ;)
I'm currently working on porting an application that has been running on
windows as C++ code for 20 years. The main reason for changing is that
While it worked fine when sites upgraded to XP, the move to W7 an
17 matches
Mail list logo
