> > Having GPG key requirements is all fine and dandy I suppose, but my
> > tongue-in-cheek comment above has a real point behind it: GPG keys
> > don't mean jack if you can't trust who owns the key.
>
> GitHub doesn't show the web of trust anyway, just "verified". Command
> line GIT doesn't
> So if we want to make sure that something like XY doesn't happen, we
> have to add some additional restrictions to those GPG keys.
>
Looks like all those geeky colleagues of ours back in the day having
key-signing parties at conferences were on to something, maybe..
Let's be clear about
> VCS was already moved to github after the recent hack of the php VCS, a lot
> of technical internals-related discussion is already using exclusively github
> issues and pull request discussions, I believe that the mailing list is
> nothing more than a redundant relic of the past.
>
As one of
On Jun 3, 2011, at 4:43 AM, Derick Rethans der...@php.net wrote:
On Fri, 3 Jun 2011, Stas Malyshev wrote:
- a call to vote is easily drowned out on the ML with all the noise
I read the same ML as you do :) Using threaded email client it is very
easy to separate new threads and see calls for
Formality, in any of its forms, is about as far from PHP or this
project as you could possibly get.
John
On Wed, Sep 15, 2010 at 10:51 PM, Alec alecgo...@gmail.com wrote:
This could be good. A custom built site where people can vote for and
against (and maybe neutral) something and then post
+1 as Lukas, on adding but not enabled by default.
On Jun 20, 2010, at 4:39 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 20.06.2010, at 22:21, Lester Caine wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:
What are your views on including APC in the core, or
All:
I'm in favor of this so-called Weak typing Zeev has proposed as
well, but I would like to see it become available in PHP before PHP 6.
That doesn't mean it has to go into 5.3.x, but I don't see why there
can't be a 5.4 that includes it. Personally, I think primitive typing
has a much more
+1 for HEAD and 5.3
On Tue, Jul 7, 2009 at 1:55 PM, Gwynne Raskindgwy...@darkrainfall.org wrote:
On Jul 7, 2009, at 1:17 PM, Andrei Zmievski wrote:
I would like to ask all developers to voice their opinions of whether it
makes sense to add this to 5.3 or to throw it away (either one is fine
On Fri, 2006-07-21 at 23:48 +0200, Lukas Smith wrote:
EXPERIMENTAL is just a way to cover our asses against not being able to
break BC if we find out we screwed something up in a new extension.
Bringing something into core obviously gives us a larger testbed and so
new situations are likely
On Wed, 2006-07-19 at 10:35 +0200, Marcus Boerger wrote:
where is the problem in having it as 'DateTime' or 'Date' in namespace
'PHP' and as 'PHPDateTime' or 'PHPDate' in the global namespace? We do
not have namespaces now but there is no technical reason to prevent that
from the beginning.
On Wed, 2006-07-19 at 10:49 +0200, Lukas Smith wrote:
+1 for DateTime and DateTimezone; the flame was funny, but let's move
on, please.
+1 from me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2006-07-19 at 16:23 +0100, Edin Kadribasic wrote:
Rename date timezone classes to DateTime and DateTimeZone respectively
Tony
Derick
Mike
Rasmus
Andi
Ilia
+ John
+1
John
--
PHP Internals - PHP Runtime Development Mailing List
To
On Wed, 2006-07-19 at 17:34 +0200, Pierre wrote:
+1/-1/0?
+1 from me, I still to this day get people pestering me about my article
on creating .zip files from pure PHP -- a real extension is clearly
useful.
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Wed, 2006-07-19 at 09:40 +0200, Marcus Boerger wrote:
A single alpha released pecl extension has a problem, well that imo is
not that bad conflict and can be solved before it is being released.
I wonder if The Perl guys check every single CPAN extension before
introducing a new keyword or
On Tue, 2006-07-18 at 20:25 +0200, Edin Kadribasic wrote:
But breaking even a few or both is still reckless, irresposible
behaviour when all that is needed to fix the breakage is rename the
class. Espacially because of all the bad publicity we get for breaking
backwards compatibility for no
I don't think prefixing things with PHP makes a lot of sense to me for
something like Date. For starters, it isn't very intuitive. But thinking
more long term why name the class PHPDate now only to rename it to
Date later when we get a PHP namespace? We're avoiding a BC break
today when adoption
On Tue, 2006-07-18 at 22:41 +0200, Pierre wrote:
Yes, and in my book, my team collegues answer mails, don't ignore
users question and inform the rest of the team of their plans. If you
read the archives you will see that none of these points has been
fullfilled in the past 5 months.
Not to be
On Tue, 2006-07-18 at 22:25 +0200, Pierre wrote:
- to start using the common names in general without a loud,
official and preemptive
warning to our users (meaning not from one minor to another)
I think we need people in charge of this specific topic. We're largely
developers after all, not
On Tue, 2006-07-18 at 13:33 -0700, Andi Gutmans wrote:
PHP 6 will come with some big changes. We could have a compat flag that
supports old-style classes PhpDate if needed.
-100
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Wed, 2006-07-19 at 01:06 +0200, Derick Rethans wrote:
Delaying it to 5.3 is not an option. We already delayed it once.
Delay the RC -- It'll be in 5.2, when we've settled this issue.
John
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, 2006-07-18 at 18:44 -0700, Andrei Zmievski wrote:
V6 is not a hindrance to V5 and is at least 9-12 months away (for an
alpha).
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just
On Wed, 2006-07-19 at 03:29 +0200, Steph Fox wrote:
Rasmus, I'm sorry but I can't agree with you. When we get namespacing it'll
make perfect sense to have PHP::Foo(). Until then, it makes no sense
whatsoever to me to mess about with plain names for root classes. We aren't
breaking 'tousands
On Wed, 2006-07-19 at 03:58 +0200, Steph Fox wrote:
John's right, because PHP::PHPDateTime would have to become acceptable
syntax. Not the _only available_ syntax, but an acceptable one.
Unless you're proposing that we automagically parse class names so that
$a = new PHP::DateTime();
$b = new
On Tue, 2006-07-18 at 18:58 -0700, Rasmus Lerdorf wrote:
Regardless, we know it's coming and we know it'll have namespacing
support. If we do PHPDateTime right now we'll have PHP::PHPDateTime
later, and that's just wonky.
Why would it be PHP::PHPDateTime ? An extra alias here isn't
On Wed, 2006-04-19 at 14:27 +0200, Steph Fox wrote:
Really this is down to John Coggeshall (as maintainer) - unless someone else
feels like going and finding a newer version of libtidy and testing it with
the existing extension(s) - e.g. would a newer version also bring other new
functions
Nuno et all.
I agree that the libtidy version we're using is pretty out of date
(2004) so I'm open to upgrading it to the latest *released* version of
tidy (not CVS)[1]. Since you have been keeping up with the library more
then me as of late, I've asked Derick to grant you karma to ext/tidy for
Richard:
I haven't even looked at the code for phpize yet, but this is just a
hunch -- what is the output of php-config? Wouldn't surprise me to find
out that's how it gets the information, nor that it is the reason you're
build isn't working.
John
On Thu, 2006-04-13 at 22:15 -0500, Richard
Committed to HEAD.. I'll let the RM decide where this belongs for PHP
5.1+ before PHP 6 (5.2 probably) Sorry I misspelled your name in the
commit ;)
John
On Thu, 2006-03-23 at 12:16 +0100, Markus Fischer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
okay, so with whom I've to
if($choice == 1) {
goto bad;
} else if ($choice == 2) {
goto good;
} else if ($choice == 3) {
goto bad;
} else if ($choice == 4) {
goto good;
}
good:
$vote++;
bad:
return;
On Tue, 2006-03-07 at 12:50 -0500, Robert Cummings wrote:
On Tue,
Sorry this fell off my radar. Is getParent() a new function to tidy? I
may have to include some lib checks in my config...
John
On Wed, 2006-01-25 at 15:22 +0100, Markus Fischer wrote:
Hi,
Antony Dovgal wrote:
On 25.01.2006 16:17, Markus Fischer wrote:
the patch is in the bug report (
goto++
On Sun, 2005-11-27 at 19:27 -0500, George Schlossnagle wrote:
me 3.
goto is good.
Wez Furlong wrote:
me also
On 11/27/05, Edin Kadribasic [EMAIL PROTECTED] wrote:
Ilia Alshanetsky wrote:
If it comes down to count of +1/-1 about this feature, I am +1 for
+1 as well if and only if this applies to IS_NULL
On Tue, 2005-10-25 at 02:45 +0400, Antony Dovgal wrote:
I'd say silently ignoring it and moving along is fine here.
Only if the var IS_NULL, but this is the case.
So I'm +1.
On 25.10.2005 02:22, Marcus Boerger wrote:
Hello internals,
If paths could be made relative, that's the ideal solution. Otherwise I
agree with Marcus that when --enable-gcov is on the ./configure line we
should regenerate the parsers and scanners to omit the debugging
information. Perhaps it would be wise in this circumstance to also tack
on a little
On Thu, 2005-10-20 at 20:20 +0100, Nuno Lopes wrote:
As I've told you before, I had already tested your patch. It has the problem
in the parsers that have bogus #line directives (but thats another story).
The other problem is that you don't handle files with the same name.
Yeah I'm aware of
It works fine, but like SQLite has limitations on scalability.
John
On Wed, 2005-10-12 at 20:03 +1000, Kevin Waterson wrote:
I have played with this and it looks a good idea on paper
but have not been successful in practice. If this is not
going to work easily, lets remove the option for
On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote:
The don't upgrade argument doesn't work. Unless we commit to having
two major versions forever where we will add new features. That is a
possibility as well of course. Have 2 trees. Unicode-PHP and
non-Unicode-PHP and everything that
On Tue, 2005-10-04 at 09:49 +0200, Derick Rethans wrote:
I am quite getting tired of having to maintain BC for *every* little
stupid thing we ever did. I think it's time to start with a clean slate
as it's all getting way to annoying to maintain (and know what subtle
differences there are
Danke, Jani.
Cheers,
John
On Fri, 2005-09-16 at 16:29 +0200, Marcus Boerger wrote:
Hello Jani,
Jani, thanks for the work! If it wasn't you we all had to do it and
everybody had to keep track. Having you doing all the checks is quit
econvenient (for us).
best regards
marcus
displeasing.
-adam
On Wed, 31 Aug 2005, John Coggeshall wrote:
So very -1 on anything introducing another way to print stuff. I am
however +1 on turning off everything but ?php from php.ini
John
On Wed, 2005-08-31 at 22:44 +0200, Edin Kadibasic wrote:
Marcus Boerger wrote
that RC1 is out of the
door?
thanks,
- Markus
Andi Gutmans wrote:
We're in a feature freeze so please hold it to after 5.1.0 is out
the door. You'll be able to commit to head when RC1 is branched off.
Thanks,
Andi
At 01:31 PM 7/15/2005 -0400, John Coggeshall wrote:
I'll take a look
Removing the ?= syntax from PHP 6 entirely right along with % seems
like a much better idea to me then trying to expand upon it.
Cheers,
John
On Wed, 2005-08-31 at 15:23 +0200, Ron Korving wrote:
Can't help it... ;) By the way, I thought all programmers were lazy to some
extent?
Seriously
So very -1 on anything introducing another way to print stuff. I am
however +1 on turning off everything but ?php from php.ini
John
On Wed, 2005-08-31 at 22:44 +0200, Edin Kadibasic wrote:
Marcus Boerger wrote:
Hello Wez,
we could however drop '%' support and introduce '?php=' support.
On Mon, 2005-08-29 at 14:43 +0200, Steph wrote:
Yes.
Yes what? :)
'replace in core'
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is made).
Although there could be a bunch of compat functions to emulate the old
xmlrpc behavior,I'm against it simply because there is nothing stopping
someone from having both extensions loaded.
- Original Message -
From: John Coggeshall [EMAIL PROTECTED]
To: Jani Taskinen [EMAIL
On that line though, I'd like to finish up the ext/xmlrpci ext I've got
in PECL and replace ext/xmlrpc. It'll eliminate the custom lib we have
for that ext, ground-up designed for PHP 5 (ext/soap style overloading,
etc.) Objections?
Cheers,
John
On Sun, 2005-08-28 at 04:10 +0300, Jani Taskinen
for their application.
I don't see any compelling need to rip out a feature that is essential
for some platforms, just because it might not work so well on others.
--Wez.
On 8/25/05, John Coggeshall [EMAIL PROTECTED] wrote:
On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote:
There are almost
I don't buy into the argument that we shouldn't start even trying to
solve the thread safety issues in PHP because of some arbitrary we
can't tell or it's faster not to do it sort of argument. Threads
aren't exactly an archaic or edge technology, and it's just stubborn of
us not to support them.
On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote:
There are almost no advantages to multithreaded PHP. There are
disadvantages (the reduced stability is inherent; no matter how good PHP
gets, multi-process deployments are by definition more
robust). Performance is slightly degraded
On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote:
Maybe we can give extensions a way to indicate that they're Unicode
compatible, and assume they're not if they don't. Non-compatible
extensions will not be loaded and produce an error.
Not to hijack the topic, but if we are going to do
On Wed, 2005-08-24 at 18:30 +0300, Stanislav Malyshev wrote:
JC Maybe we can give extensions a way to indicate that they're Unicode
JC compatible, and assume they're not if they don't. Non-compatible
JC extensions will not be loaded and produce an error.
JC
JCNot to hijack the topic, but
On Wed, 2005-08-24 at 18:47 +0300, Stanislav Malyshev wrote:
Ah, now I see, so you propose along with compiled in TS to have
actually works in TS flag. Only problem here is that extension author
may probably not know if it works in TS - TS support is much more
complicated than unicode
Why this crashes:
php -r 'class a { function b() { return $this-b(); }} $c = new a(); $c-
b();'
and this does not?
php -r 'function a() { return a(); }'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ignore that last e-mail, helps if you call the function :)
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Per my online conversation with Andi, I will be committing the gcov
stuff prior to the deep-freeze tomorrow morning -- expect a cvs commit
and a follow-up e-mail on usage early tomorrow morning.
John
On Mon, 2005-08-08 at 23:11 -0700, Andi Gutmans wrote:
At 07:57 AM 8/9/2005 +0200, Sebastian
Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed.
The changes are relatively minor and I've already run it past Andi. I'm
trying to get around one last problem that maybe someone else can take
care of:
The basic issue is that our parsers have broken file/line preprocessor
I also wrote one, i don't care which we use... it's a 5 line shell
script :)
On Tue, 2005-08-09 at 16:40 -0400, Wez Furlong wrote:
IIRC, we have a script that does this already for our release
tarballs; should save some effort.
--Wez.
On 8/9/05, John Coggeshall [EMAIL PROTECTED] wrote
On Tue, 2005-08-09 at 21:49 +0100, Nuno Lopes wrote:
BTW, there was an error in your patch: it cleans the *.gcno files (which are
generated at compile time) in cov_gen_clean() before running lcov, thus
breaking the proccess.
Opps. I'll fix that when I commit. As soon as we get the parsers
I'd also like to get this in to PHP 5.1+ after we branch before Unicode:
http://blog.coggeshall.org/archives/204_Code_Coverage_Support_for_PHP_5.html
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'll take a look at it and commit if it looks good.
John
On Fri, 2005-07-15 at 12:09 +0200, Markus Fischer wrote:
Hi,
attached is a patch to add the getParent() method for the tidyNode
against HEAD.
It's just a quick patch for me. I don't know if all tidy version support
the
Perhaps this is the obvious answer, but I'm pretty sure a fair number of
structures used in the engine are, memory-space wise, portions of larger
structures defined elsewhere. This allows the larger structure to be
type-cast to a smaller structure for certain operations easily. It is
possible that
Sure, except you can't create an instance of a class which contains
abstract methods.
On Wed, 2005-06-08 at 12:40 -0600, John LeSueur wrote:
Stanislav Malyshev wrote:
As of now, PHP allows declaring abstract private methods. Does anyone
has any use for it? IMO, it is meaningless and
On Tue, 2005-06-07 at 18:21 +0300, Stanislav Malyshev wrote:
Here I see all kinds of spagetti code already brewing... Tree drawing with
goto... Yuck.
I don't think this discussion should be about what you consider ugly or
not, but if there is a reasonable desire for the construct and the
No, I don't propose that. I am just concerned once you put goto there it
would be abused in all kinds of creative ways and would make a mess out
of the code.
Since when did anyone care that we were giving users enough rope to hang
themselves with?
?php
I think the lexer patch is good enough.
John
On Sat, 2005-03-12 at 06:58, Christian Schneider wrote:
Moriyoshi Koizumi wrote:
I modified your patch so it can capture the position where the
supposed data begins into the constant __HALT_PHP_PARSER__.
Sounds like a good idea to me as all
We've been talking about this on IRC for awhile now and I think it's a
nice patch to minimize memory usage when you want to create these sorts
of bundled PHP/data hybrid scripts.
John
On Fri, 2005-03-11 at 14:36, Ilia Alshanetsky wrote:
The attach patch implements a special token ?php HALT; ?
On Fri, 2005-03-11 at 16:37, Daniel Convissor wrote:
Interesting. I'm wondering about the security implications of this.
This makes it very easy to use PHP as a means to propogate all sorts of
nasty things. Well, people could even do that today in one script by
setting a variable to a
This ext. is completely new ground-up reimplementation of XML-RPC
specifically for PHP 5. It uses libxml2 and object overloading closely
resembling the same thing you'd find for ext/soap:
$rpc = new XMLRPC(http://pear.php.net/xmlrpc.php;);
$rpc-callfunction(10, string, 3.14, false, array(1,2,3),
testing, please ignore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 2005-02-12 at 12:57, Andi Gutmans wrote:
Creating WSDL files in Java is usually done by the development tools.
And one of the major benefits to SOAP in .NET is that it is done
completely by the core.
John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I've been itching to code, and I actually wrote this once upon a time
and lost it when my laptop harddrive bombed.
I'll take this up and try to get it out by Monday -- I don't have much
planned for the weekend.
Cheers,
John
On Wed, 2005-02-09 at 21:14, Marc Richards wrote:
George
You did't answer my question. Why?
I am def. a fan of this idea. I'd love to see internally a set of
Java-style objects representing the basic types in PHP.
As for why I have two reasons:
Although PHP is not a strongly-typed language and never will be, with
the introduction of type-hinting I
:51, John Coggeshall wrote:
You did't answer my question. Why?
I am def. a fan of this idea. I'd love to see internally a set of
Java-style objects representing the basic types in PHP.
As for why I have two reasons:
Although PHP is not a strongly-typed language and never
Is something that I could see building into the language (in all honesty,
isn't that was zend_parse_parameters does for internal functions already?),
but objects for primitives? Didn't someone say something about smelly
corpses recently? maybe it was charred? cold? smoking? rank?
I don't
if (zend_parse_parameters_ex(ZEND_PARSE_PARAMS_QUIET, ZEND_NUM_ARGS()
TSRMLS_CC, r ..
why would you silence the error for the parameter when this function
requires a valid Postgres resource to do anything?
John
On Mon, 2004-11-08 at 07:44, Markus Bertheau wrote:
Hi,
attached is a patch
I honestly don't really care about the performance side of things, I'd
be very surprised if this sort of calculation is going to be in the top
5 bottlenecks of an application. However, from a development point of
view I do find $a{-1} a much shorter and cleaner way of calculating an
end-of-string
Personally I would like to see the hooks for op-codes stay in place, I
think they offer a lot of possibilities for extensions. Andi, what do
you mean create the handler execution architecture? I'm a little
confused to what you are referring to.
John
PS -- I hated the switch() method ;)
On
If I understand you correctly you can put this pointer inside of a
resource container and return the resource container to user space as
the return value from url_init(). Then, from url_set_string() you accept
the resource as a parameter and extract the pointer to your CPP instance
of whatever
On Thu, 2004-08-26 at 17:14, Naik, Roshan wrote:
I dont beleive all the people are being pissed off. They are just
I didn't even bother reading past this line, and I'll be surprised if
anyone else responds to this because chances are you've already been
filtered out of existence. You're
Shouldn't you be able to disable that cache though?
John
On Tue, 2004-08-24 at 11:53, Ilia Alshanetsky wrote:
This is not a bug, but rather expected behavior. PCRE extension caches
compiled regular expressions so that subsequent runs of the same regex do not
need to perform the compilation
Which generic sort function? They all use the same sorting code as far
as I can tell.
John
On Tue, 2004-08-10 at 15:59, Rasmus Lerdorf wrote:
On Tue, 10 Aug 2004, Sterling Hughes wrote:
i don't think sort() should be changed - this is how php works, for
better or sometimes worse, changing
Consider the following:
?php $a = array('a', 'b', 'c', 'a'=0, 'b'=1, 'c'=2);
sort($a);
print_r($a);
?
This produces a bogus output:
Array
(
[0] = a
[1] = b
[2] = 0
[3] = c
[4] = 1
[5] = 2
)
Notice how 0 and c are switched incorrectly. Attached is a patch
attached
--- /home/john/working/php-src/Zend/zend_operators.c2004-07-27 11:15:55.0
-0400
+++ /home/john/usbdrive/zend_operators.c2004-07-26 02:01:54.0 -0400
@@ -1251,6 +1251,9 @@
zend_free_obj_get_result(op2, free_op2); \
could start committing new code we've been sitting on
for months already. I'm all for branching to and just fixing bugs for
5.0
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp
Not to bust everyone's bubble here, but frankly what is the point of a
90-100+ thread on this? I mean can't this just be implemented as a PHP
function without all this discussion?
Coogle.
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http
On Sun, 4 Jul 2004, Nuno Lopes wrote:
Maybe John has to make this methods static and they will work just like
the
functions.
As I just e-mailed Nuno, that's exactly what theyt should be (static
methods). I've been away from e-mail for the past for days because of my
move to NYC, but I'll
chregu
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
a quick example as to why I would want to assign a
default value like this? Other than that, +1 on nullable in concept.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php
4 and PHP 5 that
really doesn't buy people much.
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On Wed, 2004-04-21 at 02:47, Andrey Hristov wrote:
OTOH hinting for array (internally) will be nice also.
Arrays are the only complex type that we can't hint, I'd love to see
this sort of thing implemented.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
exceptions with non-OO code.
Nuno
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com
The change wasn't actually to make Tidy throw exceptions, but rather to
throw errors instead of exceptions (until recently, Tidy would throw
exceptions in either OO or procedural contexts).
Although I could change Tidy to not throw exceptions, I am inclinded to
leave it as is (maybe change the
more concerned
about the other extensions which are not using exceptions at all,
especially when they are warranted.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php
reason why such a change can't be implemented for
internal classes.
Feedback welcome.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com
in a object context.
It's really crazy to need to mix both types of error handling within
the same block of code.
Completely agree
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbook
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php-handbook.com/
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
their scripts.
I'm hesitant that RC2 should just be rolled because of basically this
one ultimately superficial change.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-
John Coggeshall http://www.coggeshall.org/
The PHP Developer's Handbookhttp://www.php
1 - 100 of 140 matches
Mail list logo
