On Tue, December 4, 2007 2:18 pm, Rasmus Lerdorf wrote:
> Stanislav Malyshev wrote:
>>> 1. Always compile it in but leave undocumented #ifdefs in place for
>>> performance freaks. Those same performance freaks aren't going to
>>> care
>>> about the binary compatibility issue since they are the sam
I suspect you could address security concerns by limiting the input to
valid characters in your arithmetic needs:
if (preg_match('|^[0-9.+/*-]+$|', $expression)){
eval("$foo = $expression");
return $foo;
}
On Fri, December 7, 2007 8:51 am, Nathan Rixham wrote:
> In-Built PHP Functions for par
On Friday 07 December 2007, Robert Cummings wrote:
> On Fri, 2007-12-07 at 15:55 -0500, Sam Barrow wrote:
> > Very good point
> >
> > namespace stuff ;
> > {
> > function myfunction() {
> > return true ;
> > }
> > }
> >
> > That would actually work, but it's not quite the same a
On Friday 07 December 2007, Gregory Beaver wrote:
> > If new, future core extensions showed up in a reserved PHP::
> > namespace, you would be >:-).
>
> Exactly - which is why you should never put classes, functions or
> constants in the __php__ namespace. The convention I am proposing is to
> on
Hello Everyon,
Casting a SimpleXML object to an array gives different results in PHP
5.2.5 and PHP 5.3-dev.
Source:
$xml = simplexml_load_file("sample.xml");
foreach($xml->column as $column) {
var_dump($column);
var_dump((array)$column);
}
sample.xml
?xml version="1.0"?>
There is no "fix" for the the class constants yet. I didn't have the time to
look at it nor anyone else did.
Anyway my patch for "regular" constant folding is still on-line, if someone
wants to commit or use it.
Nuno
- Original Message -
Did this topic end nowhere?
Isn't some fix he
I wrote an extension on sourceforge and am looking to merge it into PECL & take
advantage of PECLWin builds.
http://news.php.net/php.pecl.dev/4957 (last discussion link)
Pierre said I can mention his name as a reference. :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
> Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
> Exactly - which is why you should never put classes, functions or
> constants in the __php__ namespace. The convention I am proposing is
> to
> only use __php__ for code that *uses* re-usable components, not
> *declares* them.
Let alone __php__.
On Fri, 2007-12-07 at 15:55 -0500, Sam Barrow wrote:
> Very good point
>
> namespace stuff ;
> {
> function myfunction() {
> return true ;
> }
> }
>
> That would actually work, but it's not quite the same as you have the
> semicolon after the namespace declaration, which
However you don't have a semicolon after your namespace declaration.
With the current implementation you would need a semicolon, which
doesn't look nearly as good with braces.
On Fri, 2007-12-07 at 15:21 -0500, Ken Stanley wrote:
> I understand what you mean, but I was just trying to put a real-wo
Very good point
namespace stuff ;
{
function myfunction() {
return true ;
}
}
That would actually work, but it's not quite the same as you have the
semicolon after the namespace declaration, which looks kind of stupid.
Overall i dont think braces are a bad idea.
P
On Fri, 2007-12-07 at 15:21 -0500, Ken Stanley wrote:
> I understand what you mean, but I was just trying to put a real-world face
> on a so-far theoretical problem. But that does raise an interesting point;
> we can already use braces anywhere and everywhere, and while we could easily
> wrap names
I understand what you mean, but I was just trying to put a real-world face
on a so-far theoretical problem. But that does raise an interesting point;
we can already use braces anywhere and everywhere, and while we could easily
wrap namespaces in anonymous braces like you describe, why not just go t
On Fri, 2007-12-07 at 14:57 -0500, Ken Stanley wrote:
> In regards to the braces or no braces question, I have a scenario that I
> would like to share that could be considered similar in nature. We use a
> cluster of databases where I work, and to make things easier on us, we have
> a method called
Hi from Fleming . Hope your Friday is cool and happy holidays. Something
big for HxPn.pk over next few weeks. Check otc boards. Keep an eye out for
it and get in early.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
In regards to the braces or no braces question, I have a scenario that I
would like to share that could be considered similar in nature. We use a
cluster of databases where I work, and to make things easier on us, we have
a method called setSource() to switch between the clusters in our database
cl
Hi Greg,
1) recommend all global non-namespaced code that wishes to import
namespaced code via "use Namespace::Classname" add a "namespace
__php__;" at the top of the file, and that the __php__ namespace be
reserved for use by end-user applications.
That answers my main concern, but I'd make i
On 07 December 2007 17:36, Gregory Beaver wrote:
> The suggestion to make "namespace __php__;" implicit is very
> interesting, but would defeat its purpose, which is to separate
> declarations from use.
Oh, I missed that little wrinkle -- I did say I was only skimming! I guess it
could still be
I've thought about this for the remainder of the day, and I can't see
any good reason why this functionality should not be implemented into
the core; it's basic fucntionality, a safe way of doing things and
couldn't take more than a day or two to add in from a single developer,
and surely it'd
Antony Dovgal wrote:
On 07.12.2007 18:05, Alexey Zakhlestin wrote:
I doubt this is needed in core, but sounds "ok" for an extension.
Yes, I'm sure a simple extension using re2c to parse the expressions
would be gladly accepted into PECL.
or something libeval based ...
http://members.bellat
hi Derick,
all your tests passed for me yesterday with memory_limit=1G.
May be it's some fresh non GC related bug :)
Try the same test with -dzend.enable_gc=0 and with unpatched PHP.
I would very interested in this "bad" test case, if it's really related
to GC.
Thanks. Dmitry.
Derick Rethans
On 12/7/07, Mike <[EMAIL PROTECTED]> wrote:
> Yes, an easy way to handle this functionality that is safe to use with
> user input would be REALLY nice.
>
> Specifically for allowing users to specify custom formulas to do all
> sorts of nifty stuff. Especially in reporting and payroll/commission
> a
Yes, an easy way to handle this functionality that is safe to use with
user input would be REALLY nice.
Specifically for allowing users to specify custom formulas to do all
sorts of nifty stuff. Especially in reporting and payroll/commission
applications.
We're currently working on a reporting
Matthias Pigulla wrote:
>> 1) recommend all global non-namespaced code that wishes to import
>> namespaced code via "use Namespace::Classname" add a "namespace
>> __php__;" at the top of the file, and that the __php__ namespace be
>> reserved for use by end-user applications.
>
>
>> 5) namespa
Daniel and Derick, thanks for the replies..
Daniel first.. is great :) however
$arithmetic_string = "3*5";
$arithmetic_value = arith($arithmetic_string);
not possible with the method you mentioned.
eval() yes this works, however personally I feel a simple arith() (or
more suitably named functi
On Fri, 2007-12-07 at 16:44 +0100, Derick Rethans wrote:
> On Fri, 7 Dec 2007, Nathan Rixham wrote:
>
> > In-Built PHP Functions for parsing of basic arithmetic and if possible
> > fraction to decimal and decimal to fraction
> >
> > $arithmetic_string = "3*5";
> > echo arith($arithmetic_string);
Hello all,
I just wanted to drop an opp. Just to see the logic, when we have
programming structure class, interface, function, if statement, switch
statement etc, we have bracers encapsulation. This is the logic that most
programming language give to show a programmer that something is inside
some
Gregory, this is amazing and makes me - and I think many others - feel
confident, that namespacing will make it into PHP6 in a smooth and very
usable way. Thanks for your inteligent work on that.
I'd be pleased in having namespaces like that.
Regards,
Franziskus
--
PHP Internals - PHP Runtime
On Fri, 7 Dec 2007, Nathan Rixham wrote:
> In-Built PHP Functions for parsing of basic arithmetic and if possible
> fraction to decimal and decimal to fraction
>
> $arithmetic_string = "3*5";
> echo arith($arithmetic_string); // returns float 15
What's wrong with eval?
http://derickrethans.nl |
On Dec 7, 2007 9:51 AM, Nathan Rixham <[EMAIL PROTECTED]> wrote:
> In-Built PHP Functions for parsing of basic arithmetic and if possible
> fraction to decimal and decimal to fraction
PHP already handles half of what you're looking for by default.
> $arithmetic_string = "3*5";
> echo arith($a
proc_open() pipes:
when stdout and stderr are set to file no resource pointers are returned
in the pipes array
when using fwrite on a pipe to stdin (from proc_open())
fflush() does not work,
neither does stream_set_write_buffer();
regardless of whether stdout/stderr are mapped to pipes or files
Agreed, PECL or PEAR, some provision should be made, it's worth the
extra few bytes of code.
Thanks for the opinions
Nathan
Antony Dovgal wrote:
On 07.12.2007 18:05, Alexey Zakhlestin wrote:
I doubt this is needed in core, but sounds "ok" for an extension.
Yes, I'm sure a simple extension
On 07.12.2007 18:05, Alexey Zakhlestin wrote:
> I doubt this is needed in core, but sounds "ok" for an extension.
Yes, I'm sure a simple extension using re2c to parse the expressions
would be gladly accepted into PECL.
I don't see any need for this in the core, though.
> Also, I believe, quite a
I doubt this is needed in core, but sounds "ok" for an extension.
Also, I believe, quite a decent version of this can be written in php
(think PEAR)
On 12/7/07, Nathan Rixham <[EMAIL PROTECTED]> wrote:
> In-Built PHP Functions for parsing of basic arithmetic and if possible
> fraction to decimal a
In-Built PHP Functions for parsing of basic arithmetic and if possible
fraction to decimal and decimal to fraction
$arithmetic_string = "3*5";
echo arith($arithmetic_string); // returns float 15
$arithmetic_string = "1/2";
echo arith($arithmetic_string); // returns float 0.5
$fraction_string =
On Thu, 6 Dec 2007, Gregory Beaver wrote:
> I've been thinking a *lot* about your provocative email in the past
> couple of days, and have come to a different conclusion from my original
> reply (which, as a reminder stated I saw no problem with removing
> namespaces as long as we kept the import
On Tue, 4 Dec 2007, Rasmus Lerdorf wrote:
> 1. Always compile it in but leave undocumented #ifdefs in place for
> performance freaks. Those same performance freaks aren't going to care
> about the binary compatibility issue since they are the same people who
> build all their own stuff.
I am all
On Thu, 6 Dec 2007, Dmitry Stogov wrote:
> Derick Rethans wrote:
> >
> > That doesn't mean it works better for me than the old one either, where I
> > couldn't get it to crash at all ;-) Anyway, did you try to reproduce it with
> > the instructions that I provided?
>
> Yes I did. I'm looking into
Roman Borschel wrote:
I don't agree with that. I think multiple namespaces per file would be
fine with the current syntax as this is a feature that would not be used
by that many people and if it's used it's not for development purposes
(who wants to read a class bundle with no comments, linebr
I agree with everything here, especially the solution to multiple
namespaces per file (allow but discourage), but i don't agree with the
__php__ namespace. If any separation of core php and extensions into
namespaces happens, it should be kept as simple as possible, with root
namespaces like "php::
Great work!
+1 from me for your proposals, too!
Roman
On Dec 7, 2007, at 2:36 AM, Gregory Beaver wrote:
Hi Derick,
I've been thinking a *lot* about your provocative email in the past
couple of days, and have come to a different conclusion from my
original
reply (which, as a reminder state
On 07 December 2007 01:36, Gregory Beaver wrote:
[...snip...]
> In other words, 1 line of code is needed to take advantage of
> namespace's full protection and ability to import conflicting class
> names into the "global" (in this case unqualified, not
> containing :: in
> the name) scope, while
> 1) recommend all global non-namespaced code that wishes to import
> namespaced code via "use Namespace::Classname" add a "namespace
> __php__;" at the top of the file, and that the __php__ namespace be
> reserved for use by end-user applications.
> 5) namespaces provide these benefits that are
43 matches
Mail list logo
