> When Adobe moved from Actionscript 2 to Actionscript 3 they placed all
> existing functions into a legacy namespace. Similarly, I believe that
> may be PHP's best shot for smoothing out the API.
>
> Basically, the current function library is moved to the legacy
> namespace. The default setting
On Sun, Jul 15, 2012 at 6:21 PM, Rasmus Lerdorf wrote:
> On 07/15/2012 06:03 PM, Anthony Ferrara wrote:
>
> > Additionally, DateTime is a class in core. Do any functions throw
> > exceptions?
>
> Nope, and note that if you call those same DateTime functions
> procedurally they don't use exception
Hi:
I have made a patch here: https://gist.github.com/3120879
maybe some one can merge it.
thanks
On Sun, Jul 15, 2012 at 1:46 PM, Stas Malyshev wrote:
> Hi!
>
> When I go to qa.php.net to see pulls for php-src, I only see pulls down
> to number 56, but earlier ones are not displayed for
On 2012-07-15 09:48, Stas Malyshev wrote:
Hi!
And I actually know of websites using the functions to display the logo..
Is there some way we could provide a BC function for it somehow?
Maybe rather then removing the functions, make then return the data uris?
Having the functions to get the im
On 07/15/2012 06:03 PM, Anthony Ferrara wrote:
> Additionally, DateTime is a class in core. Do any functions throw
> exceptions?
Nope, and note that if you call those same DateTime functions
procedurally they don't use exceptions. So yes, changing PHP to start
throwing exceptions from procedurall
forwarding.
On 16 July 2012 02:11, Larry Garfield wrote:
> I think you meant to send that to the list. :-)
>
> --Larry Garfield
>
>
> On 07/15/2012 08:07 PM, Andrew Faulds wrote:
>>
>> It would be nice if PHP 6 unified the semantics of
>> string/int/float/bool, arrays, and objects. For those firs
On 07/13/2012 07:35 PM, Stas Malyshev wrote:
Hi!
So, I've not been inside the engine so in practice this may make no
sense at all, but what about looking at it the other way around? Vis,
instead of making objects more and more like arrays, make arrays an
object that happens to implement ArrayA
Daniel,
On Sun, Jul 15, 2012 at 8:20 PM, Daniel Convissor <
dani...@analysisandsolutions.com> wrote:
> Hi Anthony:
>
> > But I agree with your larger point. The only problem with it is that it
> > would take an engine wide shift to do.
>
> How does using exceptions in this new extension require a
Hi Anthony:
> But I agree with your larger point. The only problem with it is that it
> would take an engine wide shift to do.
How does using exceptions in this new extension require an "engine wide
shift?" DateTime already uses exceptions, no problem.
Thanks,
--Dan
--
T H E A N A L Y S I
Hi!
> Nowadays (since PHP 5.0) the code was moved from
> call_user_function_ex to zend_call_function and just looks like
> this:
>
> ((zend_internal_function *)
> EX(function_state).function)->handler(fci->param_count,
> *fci->retval_ptr_ptr, fci->retval_ptr_ptr, fci->object_ptr, 1
> TSRMLS_CC);
Alex,
On Sun, Jul 15, 2012 at 7:19 PM, Alex Aulbach wrote:
> Ok. I think, I go too much off topic. Sorry.
>
> But I want to repeat
> - we never know in which context the program will run. And good
> security means, thait it shouldn't care, in which context it runs.
>
Could you explain what you m
Check out the conversation around it.
Specifically: http://marc.info/?t=13308247243&r=1&w=2
But also: http://marc.info/?t=13302683324&r=1&w=2
So basically it just stopped. But that doesn't mean that it can't
be resurrected or continued...
Anthony
On Sun, Jul 15, 2012 at 11:48 AM, Bra
On Sun, Jul 15, 2012 at 9:50 AM, Reeze wrote:
> Hi,
> I guess /usr/local/bin is writable. then:
> which version of php and autoconf? it may set the EXEEXT=.dSYM
> if so /usr/local/bin/php may becomes /usr/local/bin/php.dSYM
>
> will you take a look at the generated Makefile is there any val
Ok. I think, I go too much off topic. Sorry.
But I want to repeat
- we never know in which context the program will run. And good
security means, thait it shouldn't care, in which context it runs.
- everything, which can go wrong will go wrong (Murphy); if there is
any chance to make it wrong, the
Hi!
> The question is more about the correctness of the doc, and to what I
> remember (I implemented that NULL on failure thing), the doc is wrong.
Well, the question is if '' is an acceptable boolean expressing false or
an error. I could see an argument for either, e.g. if you're having a
config
On 15/07/12 22:07, Alex Aulbach wrote:
> 2012/7/14 Andrew Faulds :
>> Well... if people have poorly configured servers spitting out debug
>> info in production mode, I don't think it is our problem. It is
>> theirs.
> Do you want to make it secure or do you want to discuss?
Seems Andrew mail didn't
Hi Anthony:
> I want exceptions here too. But PHP doesn't use exceptions in its standard
> library (aside from SPL)
DateTime uses exceptions.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
ht
2012/7/14 Andrew Faulds :
> Well... if people have poorly configured servers spitting out debug
> info in production mode, I don't think it is our problem. It is
> theirs.
Do you want to make it secure or do you want to discuss?
--
Greetings Alex Aulbach
--
PHP Internals - PHP Runtime Developm
The 4th param to str_replace is a by-ref param, so you can't just skip
over it, can you ?
On Sun, Jul 15, 2012 at 8:54 PM, Felipe Pena wrote:
> Hi,
>
> 2012/7/15 Paul Dragoonis :
>> Hey,
>>
>> I'm proposing to add a new function str_replace_limit, this will be
>> identical to str_replace() with o
Hi,
2012/7/15 Paul Dragoonis :
> Hey,
>
> I'm proposing to add a new function str_replace_limit, this will be
> identical to str_replace() with one key difference, you can specify
> how many times you want the replace to occur.
>
> Currently this isn't possible with any functions in the
> /ext/sta
Hey,
I'm proposing to add a new function str_replace_limit, this will be
identical to str_replace() with one key difference, you can specify
how many times you want the replace to occur.
Currently this isn't possible with any functions in the
/ext/standard/string.c stack, the only easy workaround
hi!
On Sun, Jul 15, 2012 at 7:57 AM, Stas Malyshev wrote:
> Hi!
>
> We've got a bit of a discussion on bug #49510 in the comments. The
> problem is this: filter_var('', FILTER_VALIDATE_BOOLEAN, array("flags"
> => FILTER_NULL_ON_FAILURE)) returns "null" (i.e. failure) while docs say
> boolean filt
2012/7/15 Brandon Wamboldt
> This seems pretty useful, but could technically be accomplished using the
> get/set syntax already proposed. Obviously this is a cleaner implementation
> however.
As I said, the get/set syntax RFC propose a "read-only" and a "write-only"
keywords.
For example, it wi
On Jul 14, 2012, at 22:58, "Stas Malyshev" wrote:
> The question is - should we apply it to 5.3/5.4? It is a behavior
> change, even though current code behavior does not match documented
> behavior.
I understand the concerns of BC, but I don't understand our general reluctance
to break BC to f
Hi,
I guess /usr/local/bin is writable. then:
which version of php and autoconf? it may set the EXEEXT=.dSYM
if so /usr/local/bin/php may becomes /usr/local/bin/php.dSYM
will you take a look at the generated Makefile is there any value of this
variable "EXEEXT =" ?
--
reeze | reeze.c
This seems pretty useful, but could technically be accomplished using the
get/set syntax already proposed. Obviously this is a cleaner implementation
however.
On Sun, Jul 15, 2012 at 12:46 PM, Amaury Bouchard wrote:
> Hi,
>
> Here is an RFC proposal about a syntax extension for PHP. The purpose
https://wiki.php.net/rfc/object_cast_to_types
What's the status of this RFC? I see it has a patch associated with it, and
was wondering if it would be something we'd see in 5.5 or 5.6. Does it need
to go through any sort of voting process? I'm sorry if this is the wrong
question for this mailing l
Hi,
Here is an RFC proposal about a syntax extension for PHP. The purpose is to
manage precisely the visbiliy of attributes, by separating reading and
writing access.
First of all, I know there is already an RFC about attributes ("Property
get/set syntax" [1]). Its goal is mainly different, but I
I don't understand this 100% but it sounds awesome. +1
On Sun, Jul 15, 2012 at 12:14 PM, Michael Morris wrote:
> When Adobe moved from Actionscript 2 to Actionscript 3 they placed all
> existing functions into a legacy namespace. Similarly, I believe that
> may be PHP's best shot for smoothing o
When Adobe moved from Actionscript 2 to Actionscript 3 they placed all
existing functions into a legacy namespace. Similarly, I believe that
may be PHP's best shot for smoothing out the API.
Basically, the current function library is moved to the legacy
namespace. The default setting is import t
30 matches
Mail list logo
