Derick Rethans wrote:
On Sat, 5 Jul 2003, Sebastian Bergmann wrote:
Derick Rethans wrote:
T_INTERFACE and T_IMPLEMENTS not defined in tokenizer extension
Are the other new keywords in there?
I think those were added already, atleast I couldn't think of any new
ones not in the extension yet.
On Sat, 5 Jul 2003, Sebastian Bergmann wrote:
> Derick Rethans wrote:
> > T_INTERFACE and T_IMPLEMENTS not defined in tokenizer extension
>
> Are the other new keywords in there?
I think those were added already, atleast I couldn't think of any new
ones not in the extension yet.
regards,
Der
Derick Rethans wrote:
> T_INTERFACE and T_IMPLEMENTS not defined in tokenizer extension
Are the other new keywords in there?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de
> What you are saying is that differentiating between a null value from
> next() and not having more elements is impossible without such a function?
> (I just want to be sure I understand what your motivation is).
> I don't really have a problem with array_has_more() the only problem is the
> name
Any feedback about the patch I've sent? It's not on CVS, is someone at
least looking at it? I had 3 hits to the address I've sent since 3 days.
I realize Windows isn't the perfect platform for PHP, but still, a lot
of developpers are using the binary distrib to develop on their system
and after
Hello Andi,
Friday, July 4, 2003, 10:18:41 PM, you wrote:
AG> At 07:00 PM 4/7/2003 +0200, Marcus Börger wrote:
>>Hello Andi,
>>
>>damn, yeah, it was already to early in the morning when i sent the mail, i
>>somehow didn't notice that i was trying to send a '.tx' file :-(
AG> What you are saying
Hello Andi,
Saturday, July 5, 2003, 12:55:09 AM, you wrote:
AG> At 09:30 PM 4/7/2003 +0200, Marcus Börger wrote:
>>Hello Andi,
>>
>> so now we will copy Java behavior? But why then have destructors at all?
>>But since we have them why not allow visibility with destructors as all the
>>other lan
At 09:30 PM 4/7/2003 +0200, Marcus Börger wrote:
Hello Andi,
so now we will copy Java behavior? But why then have destructors at all?
But since we have them why not allow visibility with destructors as all the
other languages do which have destructors?
I came accross it when i wanted to force ce
Hello Andi,
so now we will copy Java behavior? But why then have destructors at all?
But since we have them why not allow visibility with destructors as all the
other languages do which have destructors?
I came accross it when i wanted to force certain destruction ion behavior. I
could define i
At 07:00 PM 4/7/2003 +0200, Marcus Börger wrote:
Hello Andi,
damn, yeah, it was already to early in the morning when i sent the mail, i
somehow didn't notice that i was trying to send a '.tx' file :-(
What you are saying is that differentiating between a null value from
next() and not having more
At 07:29 PM 4/7/2003 +0200, Marcus Börger wrote:
AG> I don't like these OO tricks. It makes sense in my opinion not to have
AG> access modifiers for destructors. The destructor should be called on
object
AG> destruction no matter what.
Hm, i think full language support for factories and related p
Hello Andi,
Friday, July 4, 2003, 10:52:45 AM, you wrote:
AG> At 12:55 AM 4/7/2003 +0200, Marcus Börger wrote:
>>Hello Andi,
>>
>>Friday, July 4, 2003, 1:35:58 AM, you wrote:
>>
>>AG> Maybe we should just not allow access modifiers for the destructor. It
>>AG> doesn't make very much sense and we
Hello Andi,
damn, yeah, it was already to early in the morning when i sent the mail, i
somehow didn't notice that i was trying to send a '.tx' file :-(
Friday, July 4, 2003, 11:55:01 AM, you wrote:
AG> You forgot to attach the diff :)
AG> Andi
AG> At 03:56 AM 4/7/2003 +0200, Marcus Börger wrot
Some more info.. if it matters..
here is msghdr from sys/socket.h
/*
* NOTE: The POSIX msghdr structure takes precedence over the XOPEN flavor
* if both environments are defined. The two structs differ in the
* size of the msg_iovlen element.
*/
#ifdef _POSIX_PII_SOCKET
struct ms
cc: Warning: /php/php-src/ext/sockets/sockets.c, line 266: In this statement, the
referenced type of the pointer value "&salen" is "unsigned int", which is not
compatible with "int" because they differ by signed/unsigned attribute. (ptrmismatch1)
out_sock->bsd_socket = accept(in_sock->bsd
You forgot to attach the diff :)
Andi
At 03:56 AM 4/7/2003 +0200, Marcus Börger wrote:
Hello internals,
during my todays work i was again reminded that still one array function is
missing namely array_has_more. This function will return true if there are
more elements in an array and false if
At 01:06 AM 4/7/2003 +0200, Marcus Börger wrote:
AG> Just in case I wasn't clear, interfaces *are* meant to be a contract
to the
AG> outside world and aren't supposed to be used for all sorts of internal
AG> hierarchy stuff.
AG> If they allow PPP modifiers today then that is a bug IMO.
Of course
At 12:55 AM 4/7/2003 +0200, Marcus Börger wrote:
Hello Andi,
Friday, July 4, 2003, 1:35:58 AM, you wrote:
AG> Maybe we should just not allow access modifiers for the destructor. It
AG> doesn't make very much sense and we don't "promise" destruction at a
AG> specific point in time.
On one hand it
18 matches
Mail list logo
