Ron Korving wrote:
> is multiple inheritence something we might see appearing in 5.2 ?
The concept of Multiple Inheritance should be left to programming
languages that can properly deal with it (by letting the programmer
influence how inheritance collision can be resolved, for instance).
Mult
Hi Marcus,
I followed your commits and tested the latest code (had to compile a few
times there) but it all seams to be working now. Thanks.
- Frank
> Hello Frank,
>
> the problem turned out to be a possible memory reallocation/size
> evaluation violation. After switching some times between *
hi all,
to check syntax of pieces of code and to avoid wild regular expressions, i
wrote this:
proto bool php_check_syntax_string(string string [, &$error_message])
like php_check_syntax but on string
it will be useful for applications who have to store valid code like smarty,
...
is it possible
On Feb 17, 2005, at 2:55 PM, Jason Garber wrote:
Hello,
Speaking of these matters, how about implementing functions within
interfaces?
That is by definition impossible. Instead of being an interface, it
would be an implementation.
-ryan
--
Best regards,
Jasonmail
"Ron Korving" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> So why is this such a big "no"? Implementation problem or is it against a
> certain PHP philosophy?
Just do a google search on the cons of MI (narrow it to C++ if you please).
it's much more a philosophical issue, altho
Hello,
Speaking of these matters, how about implementing functions within
interfaces?
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, February 17, 2005, 5:46:08 PM, you wrote:
RK> Okay, I'll accept the "no" of course, but I am curious.. Is it an
RK> im
Hello Andi,
Thursday, February 17, 2005, 8:49:44 PM, you wrote:
> At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
>>Hello internals,
>>
>> before we rush into another version, how about clearing some open issues
>>that were explicitly relayed from 5.0 to 5.1.
>>
>>1) __toString()
>>
>> The
Okay, I'll accept the "no" of course, but I am curious.. Is it an
implementation problem with the current engine? Saying that using interfaces
discards the MI issue is nonsense imho, because I can't implement any
functions in an interface.
So why is this such a big "no"? Implementation problem or
Andi Gutmans wrote:
At 03:26 PM 2/17/2005 -0500, Daniel Convissor wrote:
On Thu, Feb 17, 2005 at 12:21:45PM -0800, Andi Gutmans wrote:
> Yeah I realize it's different but my idea was that if you have
something
> like:
> filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some
other
>
Hello Ron,
Thursday, February 17, 2005, 11:10:55 PM, you wrote:
> A little offtopic, but I'm still curious.. is multiple inheritence something
> we might see appearing in 5.2 ?
Definitively not.
You may raise this question prior to PHP 6,
However still getting the answer 'no'.
The concept simply
IMHO this is a bit to specialized to be included by default.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nope. Interfaces is supported as an alternative approach to MI.
Andi
At 11:10 PM 2/17/2005 +0100, Ron Korving wrote:
A little offtopic, but I'm still curious.. is multiple inheritence something
we might see appearing in 5.2 ?
Ron
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PRO
On Thu, 17 Feb 2005, Ron Korving wrote:
> A little offtopic, but I'm still curious.. is multiple inheritence something
> we might see appearing in 5.2 ?
No.
-adam
--
[EMAIL PROTECTED] | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday r
A little offtopic, but I'm still curious.. is multiple inheritence something
we might see appearing in 5.2 ?
Ron
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello internals,
>
> before we rush into another version, how about clearing some open issues
> that we
You're absolutely right... It should've said "notemptyor" :) Very perceptive
;)
Ron
"Christian Schneider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Ron Korving wrote:
> > $foo = emptyor($foo, "bar");
>
> I'm not really sure that you'd use this for. Set $foo to either the
> ori
I was recently introduced to AP style month names, and I thought it
might be a useful addition to the date formats.
http://www.umw.edu/policies/style_guide/ap_style_guide/default.php
Jan.
Feb.
March
April
May
June
July
Aug.
Sept.
Oct.
Nov.
Dec.
This stems from a publishing client who is using a L
Hello Frank,
the problem turned out to be a possible memory reallocation/size
evaluation violation. After switching some times between *nix and
windows i think i have solved the issue completeley now.
regards
marcus
Thursday, February 17, 2005, 5:56:50 AM, you wrote:
> Hi Andi,
> Here is the
At 03:26 PM 2/17/2005 -0500, Daniel Convissor wrote:
On Thu, Feb 17, 2005 at 12:21:45PM -0800, Andi Gutmans wrote:
> Yeah I realize it's different but my idea was that if you have something
> like:
> filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some other
> function could be:
> i
Ron Korving wrote:
$foo = emptyor($foo, "bar");
I'm not really sure that you'd use this for. Set $foo to either the
original value (if $foo was empty before) or "bar"? Is that empty as in
empty()? So you could end up with null, "", 0, "0", false or "bar"?
- Chris
--
PHP Internals - PHP Runtime D
I see Marcus found the problem. Definitely required a compiler to find this
problem :)
At 12:25 PM 2/17/2005 -0800, Andi Gutmans wrote:
I took a look at the code and I can't see why it wouldn't work. I lost my
VC++ environment recently because my machine died. Maybe someone else can
try and see
On Thu, Feb 17, 2005 at 12:21:45PM -0800, Andi Gutmans wrote:
> Yeah I realize it's different but my idea was that if you have something
> like:
> filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some other
> function could be:
> if (isset($_POST["foo"]) && is_number(.
>
> I t
I took a look at the code and I can't see why it wouldn't work. I lost my
VC++ environment recently because my machine died. Maybe someone else can
try and see what's going on until I rebuild mine.
Andi
At 08:56 PM 2/16/2005 -0800, Frank M. Kromann wrote:
Hi Andi,
Here is the diff I send to Mark
Yeah I realize it's different but my idea was that if you have something like:
filter_get(POST, "foo", FILTER_NUMBER) the semantics of this or some other
function could be:
if (isset($_POST["foo"]) && is_number(.
I think in most cases that would do and doesn't require to add/change
opcodes a
At 03:03 PM 2/17/2005 -0500, Wez Furlong wrote:
On Thu, 17 Feb 2005 11:49:44 -0800, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> 6) Still need to integrate PDO into the build system. I emailed Wez about
> this. I see this a show stopper for 5.1. Basically I think --with-db should
> build both ext/db a
Hello Andi,
>>4) php 5.1 is aiming to increase performance and security => ifsetor
>>
>> It is nice and easy and fast...only it's name. Well guys come on that's
>> the stupiest reason to reject. The name is selfspeaking, you're all only
>> not so used to its name as you are with foreach for
Marcus,
a minor but important issue (to me, at least) is the consistent use of
SPL exceptions throughout OOP based extensions...
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello internals,
>
> before we rush into another version, how about clearing some o
Hello Andi,
Thursday, February 17, 2005, 8:49:44 PM, you wrote:
> At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
>>Hello internals,
>>
>> before we rush into another version, how about clearing some open issues
>>that were explicitly relayed from 5.0 to 5.1.
>>
>>1) __toString()
>>
>> The
On Thu, Feb 17, 2005 at 11:49:44AM -0800, Andi Gutmans wrote:
> At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
> >4) php 5.1 is aiming to increase performance and security => ifsetor
>
> It wasn't only the name but also the implementation. Actually, I was hoping
> that the input filter API w
On Thu, 17 Feb 2005 11:49:44 -0800, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> 6) Still need to integrate PDO into the build system. I emailed Wez about
> this. I see this a show stopper for 5.1. Basically I think --with-db should
> build both ext/db and ext/pd_db.
I already made a start on this la
> 4) php 5.1 is aiming to increase performance and security => ifsetor
>
> It is nice and easy and fast...only it's name. Well guys come on that's
> the stupiest reason to reject. The name is selfspeaking, you're all only
> not so used to its name as you are with foreach for now.
I really lo
At 08:18 PM 2/17/2005 +0100, Marcus Boerger wrote:
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
1) __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that
Will take a look at that struct thingy.
As far as the warnings, a lot of the are bogus and I wouldn't want to hide
them with explicit casting. This might hide bugs which exist. It will
definitely be good to go through them though and see if/what needs fixing.
Thanks,
Andi
At 04:36 PM 2/17/2005 +
Marcus Boerger wrote:
4) php 5.1 is aiming to increase performance and security => ifsetor
It is nice and easy and fast...only it's name. Well guys come on that's
the stupiest reason to reject. The name is selfspeaking, you're all only
not so used to its name as you are with foreach for now.
Hello internals,
before we rush into another version, how about clearing some open issues
that were explicitly relayed from 5.0 to 5.1.
1) __toString()
There was a problem with the Zend engine 2.0 that forced us to drop this
feature. Now that we have 2.1 we should check again and readd the
Anybody happen to have an archive of the old [EMAIL PROTECTED]
Majordomo mailing list from 1995 or have an idea where I might be able
to get that? Or perhaps an email backup of any correspondence with me
from back then?
Please reply privately.
-Rasmus
--
PHP Internals - PHP Runtime Development
If struct _zend_arg_info is an incomplete type, the declarations in
zend_modules.h like:
extern struct _zend_arg_info first_arg_force_ref[2];
are not valid C code (it doesn't make sense to declare an array if the
compiler does not know what size each element is, so this is not hard to
understand)
Right, as long as you explicity include the encoding.
So with the patch if you include a BOM, it wont parse (previous behavior
worked fine) and if you include a prolog without explicit encoding it
will always use UTF-8 (previous behavior was to autodetect encoding
based on the charset used for f
On 2005/02/17, at 22:28, Joe Orton wrote:
So it is a bit of a tricky trade-off...
How about #ifdef'ifying it? It's lame though...
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Feb 17, 2005 at 07:19:46AM -0500, Rob Richards wrote:
> It looks like there would be BC breaks unless libxml with the bug fix is
> used as the encoding is detected properly and no infinite loop if an xml
> declaration or BOM is used in the xml. So basically with the patch there
> is no m
Hi Rob,
Tank you for you extensive reply.
> -Original Message-
> A few comments from eyeballing the patch:
>
> - Depending upon how much c14n functionality there is to be,
> this might be better off as a standalone extension. This way
> it wouldn't be dependant upon DOM (especially if
It looks like there would be BC breaks unless libxml with the bug fix is
used as the encoding is detected properly and no infinite loop if an xml
declaration or BOM is used in the xml. So basically with the patch there
is no more autodetecting if used with any other libxml versions (though
no m
On 17.2.2005 12:26 Uhr, Joe Orton wrote:
libxml2's charset encoding auto-detection mode is broken with the push
parser in current versions of libxml2, I found that recently:
http://bugzilla.gnome.org/show_bug.cgi?id=162613
but trying to force it can trigger infinite loops in libxml2, which is
what
libxml2's charset encoding auto-detection mode is broken with the push
parser in current versions of libxml2, I found that recently:
http://bugzilla.gnome.org/show_bug.cgi?id=162613
but trying to force it can trigger infinite loops in libxml2, which is
what happens in http://bugs.php.net/?id=3200
A few comments from eyeballing the patch:
- Depending upon how much c14n functionality there is to be, this might
be better off as a standalone extension. This way it wouldn't be
dependant upon DOM (especially if PHP is built without it) and allow it
to work with simplexml alone. Take xsl for ex
> -Original Message-
> D.Kingma wrote:
>
> > Hi Rob / Chregu,
> >
> > As a first (small) step to implementing xml-security specs
> (dig-sign,
> > encryption) I created a patch against HEAD to expose
> (exclusive-)C14n
> > functionality from libxml2. I allows you to canonize a single n
Patch can be found here:
http://www.php.net/~jani/patches/bug18613.patch
I wrote that just for fun (nothing better to do :) so it might
not be perfect. Do whatever you want with it..
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
At 18:38 16/02/2005, Rasmus Lerdorf wrote:
Given the way XML is used in xmlrpc and SOAP systems, I don't think I
would classify a security problem in libxml as a local exploit.
I know, that's why I said 'most', and not 'all' (some exploits may have
more far reaching effects, for certain users).
47 matches
Mail list logo
