Andi Gutmans wrote:
> Interfaces should not support access modifiers and should by default be
> public.
+1
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Interna
I've got Apache 1.3.27 with PHP 4.3.0 on NetBSD 1.5.3. When a PHP
program running in safe mode calls the mail() function to send
mail, the usual Apache environment variables like SCRIPT_FILENAME
and REMOTE_ADDRESS are not exported. This is a problem since I
need to log which CGI and remote host a
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 not. The real problem is that next()
doesn't work with false.
A diff against PHP 5 is at
having had a quick think about this, here some thoughts that may affect it.
What is the API going to be used for.
a) replacement for method_exists(), call_user_func() in code
.. which makes sense for the object methods...
b) quick testing of what an interface is - as in print_r() is quicker
than o
Hello Andi,
Friday, July 4, 2003, 1:53:48 AM, you wrote:
AG> At 01:51 AM 4/7/2003 +0200, Andi Gutmans wrote:
>>At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote:
>>>Hello internals,
>>>
>>>It is of course correct that an interface method cannot be declared private
>>>but i think it should be possib
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 would of course be an option which simplifies
At 01:51 AM 4/7/2003 +0200, Andi Gutmans wrote:
At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote:
Hello internals,
It is of course correct that an interface method cannot be declared private
but i think it should be possible to declare it protected.
Interfaces should not support access modifiers an
At 06:40 PM 3/7/2003 -0400, Jon Parise wrote:
On Thu, Jul 03, 2003 at 03:36:58PM +0200, moshe doron wrote:
> > It's not an annoyance - it's not my spec, I'm just implementing it.
> > I'm happy to change the code to work via properties instead, it's not a
> > major change. I would like to settle o
At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote:
Hello internals,
It is of course correct that an interface method cannot be declared private
but i think it should be possible to declare it protected.
Interfaces should not support access modifiers and should by default be public.
Andi
--
PHP Int
On Thu, Jul 03, 2003 at 03:36:58PM +0200, moshe doron wrote:
> > It's not an annoyance - it's not my spec, I'm just implementing it.
> > I'm happy to change the code to work via properties instead, it's not a
> > major change. I would like to settle on a concensus first.
>
> +1 (maybe both)?
Maybe we should just not allow access modifiers for the destructor. It
doesn't make very much sense and we don't "promise" destruction at a
specific point in time.
Andi
At 03:07 PM 3/7/2003 +0200, Marcus Börger wrote:
Hello Zeev, hi Andi,
attached is my idea of finally fixing the destructor vi
On Thu, 2003-07-03 at 15:31, Björn Schotte wrote:
> If so, then I would suggest the following add-ons:
Whatever. :-)
The patch is out there. I wrote because I found it useful. If others
find it useful as well, so much better. I see no value in this
discussion, and no reason to keep cluttering the
* Marco Tabini wrote:
> On Thu, 2003-07-03 at 13:49, Björn Schotte wrote:
> > No. My position is that a developer should evolve and learn
> > that there are some more professional ways than just dumping
> > debug data to the browser instead of a log file.
> Please, do not imply that what I am sugge
Can you guys take this thread off the internals@ list please.
- Original Message -
From: "Fred Merritt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 03, 2003 7:16 PM
Subject: Re: [PHP-DEV] Re: var_dump_html()
> Sorry, I'll try again
> Why is dumping debug to the log m
Sorry, I'll try again
Why is dumping debug to the log more professional??
When I want debug information, I usually want it quick. It takes 2
seconds to add a var_dump or whatever, upload the change, and reload the
page. Whatever gets the job done quickest seems more professional to me.
Best re
smime.p7s
Description: S/MIME Cryptographic Signature
Marco Tabini schrieb:
> A two-liner is twice as many lines as a one-liner :-) .
Thats why I pointed to auto_prepend_file.
> In a debugging
> situation, you often add and remove var_dump()'s quickly and all over
> the place while hunting down a bug. Having to worry about an extra step
> uselessly
On Thu, 2003-07-03 at 13:49, Björn Schotte wrote:
> * Marco Tabini wrote:
> > So, your position is that a developer should bend to the technology.
>
> No. My position is that a developer should evolve and learn
> that there are some more professional ways than just dumping
> debug data to the brow
* Marco Tabini wrote:
> So, your position is that a developer should bend to the technology.
No. My position is that a developer should evolve and learn
that there are some more professional ways than just dumping
debug data to the browser instead of a log file.
--
ThinkPHP und Partner auf dem L
On Thu, 2003-07-03 at 13:43, Björn Schotte wrote:
> * Marco Tabini wrote:
> > (a) Not everybody does it that way
>
> That's no argument.
Well, how can I argue with this?
> > (b) Not everybody *can do it* that way--think Windows users.
>
> Cygwin exists and I'm sure there's a bunch of freeware/
* Marco Tabini wrote:
> (a) Not everybody does it that way
That's no argument.
> (b) Not everybody *can do it* that way--think Windows users.
Cygwin exists and I'm sure there's a bunch of freeware/shareware
tools that do the same.
--
ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei,
On Thu, 2003-07-03 at 13:33, Björn Schotte wrote:
> Normally one would dump to an error_log (and having
> a tail -f php_error.log in another shell), not to the browser.
> If one has a small web package, he could do "" ... "",
> so there shouldn't be any problem.
Yes, but--
(a) Not everybody does
* Marco Tabini wrote:
> Thanks, Frank, I have. But do I really want to load up a PEAR class to
> dump my variables to the browser? For me, the answer is no--although,
> obviously, that is only my opinion.
Normally one would dump to an error_log (and having
a tail -f php_error.log in another shell)
On Thu, 2003-07-03 at 13:09, Frank Wiegand wrote:
> IMHO its not PHP's job to produce HTML output for debugging purposes.
Well, then, I guess we'll have to agree to disagree. IMO, PHP's job is
to work in a way that is most useful to the developer. Since most
developers use PHP in web projects, it
Hello Moriyoshi,
Thursday, July 3, 2003, 7:13:44 PM, you wrote:
MK> [EMAIL PROTECTED] (Marcus Börger) wrote:
>> Nice idea, but one thing i wanted is to disable cloning of class objects.
>>
>> The following class makes cloning impossible for all derived classes:
>> class no_clone {
>> final pr
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Nice idea, but one thing i wanted is to disable cloning of class objects.
>
> The following class makes cloning impossible for all derived classes:
> class no_clone {
> final private __clone() {}
> }
>
> but the all classes that should not be cloned m
Marco Tabini wrote:
>> Please have a look at PEAR::PHP::Var_Dump:
>> http://pear.php.net/package-info.php?pacid=103
> Thanks, Frank, I have. But do I really want to load up a PEAR class to
> dump my variables to the browser? For me, the answer is no--although,
> obviously, that is only my opinio
Hello Moriyoshi,
Thursday, July 3, 2003, 6:50:46 PM, you wrote:
MK> [EMAIL PROTECTED] (Marcus Börger) wrote:
>> Not really. An interface simply describes a protocol subset that must be part
>> of the implementing class's protocol. In that it makes no sense to allow final
>> or private methods in
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Not really. An interface simply describes a protocol subset that must be part
> of the implementing class's protocol. In that it makes no sense to allow final
> or private methods in an interface but still a protected member in an interface
> would descri
Hello Jan,
Thursday, July 3, 2003, 6:15:04 PM, you wrote:
JS> Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>:
>> [EMAIL PROTECTED] (Marcus Börger) wrote:
>>
>> > Hello internals,
>> >
>> > It is of course correct that an interface method cannot be declared
>> private
>> > but i think it should
Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] (Marcus Börger) wrote:
>
> > Hello internals,
> >
> > It is of course correct that an interface method cannot be declared
> private
> > but i think it should be possible to declare it protected.
>
> I don't see the benefit to all
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Hello internals,
>
> It is of course correct that an interface method cannot be declared private
> but i think it should be possible to declare it protected.
I don't see the benefit to allow interfaces to have protected methods as I
use abstracts for t
On Thu, 2003-07-03 at 11:47, Frank Wiegand wrote:
> Marco Tabini wrote:
>
> > Not sure if this interest anyone, but the attached patch adds a function
> > called var_dump_html() that performs the same functionality as
> > var_dump(), except that it outputs HTML instead of plain text.
> > var_dump(
Hello internals,
It is of course correct that an interface method cannot be declared private
but i think it should be possible to declare it protected.
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
Marco Tabini wrote:
> Not sure if this interest anyone, but the attached patch adds a function
> called var_dump_html() that performs the same functionality as
> var_dump(), except that it outputs HTML instead of plain text.
> var_dump() is a bit impractical to use in a web environment, IMO.
Plea
I still fail to understand how this would be helpful to someone who's
debugging a script (as I presume you're not showing the user nicely
colorised var_dump()s). *shrug*
Vlad
Ken Tossell wrote:
Quoting Vlad Bosinceanu <[EMAIL PROTECTED]>:
What could it possibly colorize and how would it be
What could it possibly colorize and how would it be useful?
epplestun wrote:
In my opinion is good idea but Derick has rason, is better if var_dump_html
colorise the output :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
In my opinion is good idea but Derick has rason, is better if var_dump_html
colorise the output :-)
- Original Message -
From: "Marco Tabini" <[EMAIL PROTECTED]>
To: "Derick Rethans" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 03, 2003 5:13 PM
Subject: Re: [PHP-DEV] var
My only consideration is that most people use var_dump in a web
environment--hence it seems counterintuitive to have to enclose the
function in additional HTML tags.
Cheers!
On Thu, 2003-07-03 at 11:09, Derick Rethans wrote:
> On Thu, 3 Jul 2003, Marco Tabini wrote:
>
> > Not sure if this intere
Quoting Derick Rethans <[EMAIL PROTECTED]>:
> On Thu, 3 Jul 2003, Marco Tabini wrote:
>
> > Not sure if this interest anyone, but the attached patch adds a function
> > called var_dump_html() that performs the same functionality as
> > var_dump(), except that it outputs HTML instead of plain text
On Thu, 3 Jul 2003, Marco Tabini wrote:
> Not sure if this interest anyone, but the attached patch adds a function
> called var_dump_html() that performs the same functionality as
> var_dump(), except that it outputs HTML instead of plain text.
> var_dump() is a bit impractical to use in a web env
Not sure if this interest anyone, but the attached patch adds a function
called var_dump_html() that performs the same functionality as
var_dump(), except that it outputs HTML instead of plain text.
var_dump() is a bit impractical to use in a web environment, IMO.
Cheers,
Marco
--
Marco Tabin
On Wed, 02 Jul 2003, Andi Gutmans wrote:
> I've already said so, but I definitely prefer methods.
So do I. Overloading properties is a bit of magical powder that's
appropriate only in some cases.
-Andrei
* There is no knowledge that is not power. -- Ralph Waldo Emerson *
--
PHP Internals - PHP
On Wed, 02 Jul 2003, Timm Friebe wrote:
> On Wed, 2003-07-02 at 05:32, Timm Friebe wrote:
> [...]
> > This should now be the final patch.
>
> Then again, it would help to attach it:)
Why aren't you using the standard zend_parse_parameters() API function
here?
-Andrei
* It's an emergent property
On Tue, 01 Jul 2003, Timm Friebe wrote:
> - Added Reflection_Class::getModifiers which returns a long
> consisting of the bitmask of modifiers which are registered
> as constants with the following names:
>
> STATIC
> ABSTRACT
> FINAL
> INTERFACE
> ABSTRACT_CLASS
> FINAL_CLASS
>
Hello Zeev, hi Andi,
attached is my idea of finally fixing the destructor visibility. It simply
emits an E_ERROR on an illegal attempt to destruct an object during execution
and emits an E_WARNING with a slighlty longer message in shutdown (outside
execution). Patch attached.
--
Best regards,
fixes building under windows.
Uses TSRMLS_FETCH().
Not sure if there is a better way.
Index: zend_reflection_api.c
===
RCS file: /repository/ZendEngine2/zend_reflection_api.c,v
retrieving revision 1.8
diff -u -r1.8 zend_reflection_
On Wed, 2 Jul 2003, Gabor Hojtsy wrote:
> > Does anybody object if I remove the php-4.3.0-dev-zend2-* files from
> > phpweb/distributions ? This saves atleast 20mb...
>
> +1 :)
done
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read
> It's not an annoyance - it's not my spec, I'm just implementing it.
> I'm happy to change the code to work via properties instead, it's not a
> major change. I would like to settle on a concensus first.
+1 (maybe both)?
>
> George
>
--
PHP Internals - PHP Runtime Development Mailing Li
Zitat von Jani Taskinen <[EMAIL PROTECTED]>:
>
> Works fine here, get a fresh checkout.
Doh! You shouldn't try to run the tester if you compiled --without-cli. ;-)
> --Jani
>
> On Wed, 2 Jul 2003, Jan Schneider wrote:
>
> >/bin/sh: line 1: /home/jan/software/php43/: is a directory
> >mak
Hi Greg,
Actually it is possible to have both installed. Just make sure all php4
files
are in the same directory, say c:\php4\php432 including your php.ini, while
the php.ini in the windows directory is for php5.
Regards, John
"Greg Beaver" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTEC
51 matches
Mail list logo
