Gregory Beaver wrote:
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT a
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT as originally stated was
Adding more error modes is fine and dandy, but it has to be with a
good reason in mind. In my mind if we add E_DEPRECATED and mark
certain behavior as deprecated it means in a certain version, PHP6
(for example) it will go away and no longer work. Marking something
as deprecated with no int
Marcus Boerger wrote:
That said I can only repeat here what I said earlier on IRC. Lets do things
right and make the more complex OO rules as E_STRICT and create new severity
level E_DEPRECATED. E_STRICT will then only be used for 'pedantic' OO rules
while E_DEPRECATED will be used for stuff tha
Hello William,
Saturday, October 21, 2006, 1:04:44 AM, you wrote:
> Ilia Alshanetsky wrote:
>>
>> On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
>>
>>> Hello Ilia,
>>>
>>> also an ISO/shared server will never be securewhatever you do and
>>> you can
>>> make MySQL disaalow external connectio
