I see what you're trying to do but not a big fan of how it's being implemented
in the example given.
- Mike
Sent from my iPhone
On Oct 20, 2012, at 4:02 PM, Rasmus Lerdorf wrote:
> On 10/20/2012 01:59 PM, Nikita wrote:
>> Hello, list. I want to propose generics. For those, who don't know wha
*"Oh goodness no, let's please only do OOP with the language features.
Creating ridiculous "procedural" OOP abstractions helps absolutely nobody"*
Andrew, I'm the biggest advocate of OOP out there, but the purpose of this
is to provide a nice convenient layer for all developers to use to properly
Personally, I would like to see it operate similar to MySQLi, where you
have the convenience of OOP, but can still call a function directly in a
procedural manner.
And I definitely feel like we need encoding. We can default it to UTF-8 or
to the zend.script_encoding if set, but I think it needs t
*Basically if you are STORING XSS intrusions then you have badly designed
code as there is no reason that it would be stored. If you want to
'display' suspect code, then it is 'escaped' before it is stored so
preventing a potential problem if another viewer accesses the raw data!*
While that is t
The $b on this example would be freed as it is in the function's scope, and
not the global scope. The exception to this would be a static variable
within a function, which would persist for future use within the function.
Class properties on the other hand will persist until the object is
destruc
Just to elaborate on what Patrick said, in the first case the variables are
temporary, where in the second they persist even after you finish your
loop. So even after the foreach is finished, the $f1, $f2, and $f3
variables are still storing data- even though it is no longer needed.
In order to f
Correct me if I'm wrong, but I believe Zend Multibyte is now enabled by
default in PHP 5.4.
- Mike
On Wed, Mar 14, 2012 at 9:24 AM, Ferenc Kovacs wrote:
> >
> >
> > I would then propose to make mbstring compile time mandatory.
> >
> > I'm against yet another global ini setting, I find the ac
I think the ini directive, while adding another to the list, may be the
most unobtrusive method to address this issue, at least for developers.
I definitely agree with Rasmus that this could be one of the bigger
headaches in transitioning to 5.4 (for non-UTF8 sites) and unless we can
come up with
Perhaps rather than killing it we should just emphasize it more in the
documentation (ie on preg_replace and not only in pattern modifiers).
But I have found the /e modifier to be very useful in the past. Unfortunately,
just having woken up I can't remember exactly where and how I used it, lol.
+1 and agree that it should be implemented before the beta.
On Fri, Sep 2, 2011 at 2:58 PM, Ulf Wendel wrote:
> Am 02.09.2011 21:24, schrieb Stas Malyshev:
>
> Hi!
>>
>> On 9/2/11 12:17 PM, Christopher Jones wrote:
>>
>>> I'm +1 for this. I think the decision& implementation needs to be done
Didn't send to list the first time, please accept my apologies if you
received this twice - Thanks
That makes sense if it would overwrite the methods as well, but otherwise it
seems like it provides inconsistent functionality. Perhaps I'm wrong as
likewise I have a very limited understanding her
I agree with Adam, I think it would be nice to let the trait contain its own
properties which can then be overwritten by the class properties.
This way we could include default properties that the trait may be dependent
on, while providing the opportunity to override individual properties to
provi
I didn't know about gcov until a couple days ago, but just poking around I
think its fairly useful, if nothing else to see where potential
vulnerabilities may lie, as well as a quick, convenient way to check out the
internal code.
Thanks,
Mike
On Tue, Jul 19, 2011 at 6:44 AM, Rafael Dohms wrote
13 matches
Mail list logo
