> As the person that will end up having to maintain this, I wasn't aware
> that https://github.com/matomo-org/matomo-php-tracker is pretty much the
> same as the JS tracker. And as it does HTTPS requests from the PHP
> application to Matomo, instead of a JS tracker, this seems like a
> better solut
On Nov 11 2024, at 12:03 am, Larry Garfield wrote:
>
> First off, the obligatory "it was open for discussion for a month, and now
> you mention this?"
I apologize for that, wasn't intentional. Unfortunately a whole pile of
personal matters landed on my head between ... let's say October and N
> And we're in 2024 now and nobody writes PHP code without Composer. Without
> this change, we can't use any composer available library for PHP.NET sites,
> nor even mention it in the documentation.
> That's bonkers.
>
100% agree with you.
> This is counter productive, because the current rule
I also voted against because I think it's silly to create these arbitrary rules
on the various frameworks. "Not playing favorites" is literally as easy as
saying "The people who volunteered their time to build X did so using Y because
that's what they knew, it doesn't mean the PHP project favors
Here's an article from a trusted source about it in a little more detail as
well.
https://www.zdnet.com/article/why-remove-russian-maintainers-of-linux-kernel-heres-what-torvalds-says/
"While this action has removed these maintainers from their official roles, it
does not bar them entirely from
> So banning "full" frameworks is my attempt at steering clear of the
> appearance of that kind of favoritism. Showing favoritism for Composer or
> Xdebug is, well, there's no competition to complain. PHPUnit is technically
> not the only testing framework on the market, but it has north of 90%
On Sep 6 2024, at 2:07 pm, Claude Pache wrote:
>
>
> > Le 5 sept. 2024 à 18:03, John Coggeshall a écrit :
> >
> > > As per my previous email to the list, I have now created the official RFC
> > > to deprecate calling json_serialize()
> So if we had a #[NotSerializable] attribute (which I agree might be a good
> idea) it would be implemented by setting the ZEND_ACC_NOT_SERIALIZABLE flag
> on a class definition, and if this RFC passes, it would automatically apply
> to json_encode() as well as serialize().
>
My mistake, I hav
> As per my previous email to the list, I have now created the official RFC to
> deprecate calling json_serialize() on instances of classes marked with
> ZEND_ACC_NOT_SERIALIZABLE.
I would suggest we take a step back from this and look at it with a bit more of
a wider lens. It seems to me that
One thought re-reading the RFC.
abstract class Theme {
public function bar();
}
class CuteTheme extends Theme {
public function foo();
}
class Config {
public function __construct(Theme $theme = new CuteTheme()) {}
}
$a = new Config(default->foo());
In the proposed (updated) RFC would this be p
On Aug 28 2024, at 9:34 am, Larry Garfield wrote:
>
> I don't think I'd support a list of "popular" frameworks, but mentioning
> Composer, Xdebug, and PHPUnit seems a requirement for a useful modern
> tutorial.
Can you explain your position more here, what exactly is your concern (if I
captu
> I agree with this to a point. What if I want my newish framework listed on
> the page? What are the qualifications for being listed (or unlisted) there?
> Can anyone add their own framework?
Personally I say put the top 5 by Github stars on a page by themselves, and
have a secondary page rank
> And that is how you will find that the "new" languages will "win". If we
> don't promote how modern PHP Development works, then there will be more
> "PHP, a fractal of bad design" articles to come for decades.
>
> We *must* do better than this. It probably doesn't all need to be in the
> documen
On Aug 26 2024, at 5:27 pm, Matthew Weier O'Phinney
wrote:
> You'll likely identify the increased delay in such cases. Generally speaking
> these sorts of default values don't change a ton, but it's not unlikely that
> you may say "I'd like half that delay" or "twice that delay". But a better
On Aug 26 2024, at 5:57 pm, Bilge wrote:
> In case it matters, my initial inclination was also to do what some others
> have suggested, and modify the SEND opcodes so that the default is not
> actually looked up using reflection at all, but rather we just send nothing
> to the function and it
On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney
wrote:
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a string to a
> default.
>
> - fractional or multiplicative application, e.g. for durations/timeouts.
> These might require testing for non-zero
On Aug 26 2024, at 2:39 pm, Bilge wrote:
>
> I like this approach. I'm still not sure I'd want to pursue adding
> exclusions, but if we can identify something that's obviously bad and/or
> dangerous then we can consider that short list for exclusion. That is much
> more compelling than starti
> From the example you gave it appears that we can have a concrete problem when:
> 1. There is a parameter with a default value,
> 2. That parameter is type-hinted,
> 3. The hinted type is declared as a union type,
> 4. An earlier version of the library initialized the default with a value
> havi
his point if some downstream caller
decided to use my default value directly or not.
You can argue if this is a good API design or not, but it was only written to
provide a real example of how pulling the default value higher up the call
chain and allowing it to be used in expressions is problematic
On Aug 25 2024, at 6:42 pm, Bilge wrote:
> On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote:
> > It doesn't, unfortunately, persuade me that the behaviour proposed is
> > sensible.
>
> It should. But since it has apparently failed in that regard, I suggest you
> take me up on my challenge to i
On Aug 25 2024, at 5:51 pm, Bilge wrote:
> If you believe I am incorrect about this, I encourage you to submit a
> (working) Bison patch to demonstrate how a restricted expression grammar
> subset can still recurse with the unrestricted superset, then we can start
> having this discussion mor
> public function suspend(float|int|null $delay = null) {
> parent::suspend((int)(($delay ?? 0) * 1000) ?: default);
> }
> }
>
> new MySuspension()->suspend(2.2345); // int(2234)
> Not only have I demonstrated the need to use multiplication or division
> to change the scale, but also the need to
> Special-casing the T_DEFAULT grammar would not only bloat the grammar rules
> but also increase the chance that new expression grammars introduced in
> future, which could conveniently interoperate with `default`, would be
> unintentionally excluded by omission.
Forgot to add that I don't thi
On Aug 25 2024, at 11:31 am, Rowan Tommins [IMSoP] wrote:
>
>
> Even then, I look at that list and see more problems than use cases. As the
> RFC points out, library authors already worry about the maintenance burden of
> named argument support, will they now also need to question whether some
On Aug 25 2024, at 11:11 am, Rob Landers wrote:
>
> Which operants don’t make sense?
Well certainly all of the ones toward the end of the appendix in the RFC the
RFC itself notes are non-sensical. Personally, I'm not sold on the idea default
should be an operand in an expression at all though.
> If the underlying API changes the argument type, consumers will have an issue
> regardless. For those cases where the expression is simply `default`, you'd
> actually be protected from the API change, which is a net benefit already.
>
> This also protects the user from changes in the argument
On Aug 24 2024, at 12:49 pm, Bilge wrote:
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
Seems like you are missing an option for your theme example, which would be to
simply extend the C
On Aug 23 2024, at 3:41 pm, Rowan Tommins [IMSoP] wrote:
>
> None of these seem like showstoppers to me, but since we can so easily go one
> step further to "global only", and avoid them, why wouldn't we?
FWIW I'd support global only, specifically because of the point I wouldn't
necessarily w
On Aug 23 2024, at 1:46 pm, Stephen Reay wrote:
>
>
> The claims about "security" because a function you defined (or included via a
> package) is resolved in place of a global one are irrelevant. If you're
> including compromised code in your project, all bets are off.
I have plenty of experie
> 1. People who don't think BC is a problem, and would like to drop
> either the global or local lookup entirely, requiring disambiguation.
>
There is also an option of swapping the priority, making local lookups
secondary to global lookups -- and to override that behavior you would require
dis
> What do you mean by this? What is "the right thing"?
Also, faster code vs. slower code by default is "the right thing" too.
On Aug 23 2024, at 12:35 pm, Stephen Reay wrote:
>
> > would find it non-sensical that you must add a backslash for the engine to
> > do the "right thing" (in this case, optimize their code with a security
> > benefit), vs just doing the right thing by default.
>
> What do you mean by this? Wh
On Aug 23 2024, at 12:27 pm, Stephen Reay wrote:
>
> The current inconsistencies between symbol types can be avoided in userland
> in a 100% consistent way. Import or qualify the symbols you use, all the
> time, and you have 0 inconsistencies or bizarreness in terms of what it used
> when.
S
On Aug 23 2024, at 11:49 am, Rowan Tommins [IMSoP] wrote:
>
> And most users don't object to using a leading backslash, they just (quite
> reasonably) have no idea what impact it has on the ability of the engine to
> optimise their code.
I think this is a misread, and I don't think you can ar
On Aug 22 2024, at 4:09 am, Rob Landers wrote:
>
> If you have the ability to inject arbitrary code, you've already lost. It
> doesn't matter whether they use this feature, or just register a shutdown
> function, autoloader, replace classes/functions/methods entirely, or
> whatever. Should we
Forgive me, s/Illija/you :)
On Aug 21 2024, at 2:10 pm, Ilija Tovilo wrote:
>
> Including a malicious composer package already allows for arbitrary
> code execution, do you really need more than that?
>
Of course. We've seen many examples in the wild of 3rd party libraries getting
hijacked to inject malicious code (e.g.
On Aug 21 2024, at 8:03 am, Rob Landers wrote:
>
> If this is an attack vector for your application, then fully qualified names
> is the way to go (WordPress does this nearly everywhere, for example).
This is an attack vector for every application and I would argue should be a
real concern for
On Aug 2 2024, at 4:37 pm, Bilge wrote:
> My only concern is there needs to be an alternative way to do this:
> intercepting internal calls. Sometimes, whether due to poor architecture or
> otherwise, we just need to be able to replace an internal function call. One
> example I can think of r
> Just to show the range of viewpoints on this, I'd like to mention my opinion
> that Stringable is a horrible feature, with an implementation that's
> completely inconsistent with the rest of the language, and no clear semantic
> purpose. If your contract is "the input must be usable as a stri
On Aug 16 2024, at 6:49 pm, Rob Landers wrote:
>
> That being said, I would like to be able to use | and & on integer enums more
> than I would strings as stringables. Something like “flags” mode in C#. Maybe
> even make “flag” a backing type of enums. It would make a ton of json flags
> much
> To the original question, there's two reasons that __toString() was
> deliberately omitted from enums:
>
> 1. To discourage their use as "fancy strings". Enums are their own type,
> independent of any other. Making them usable as 95% strings partially defeats
> their purpose.
I disagree with
> Didja really?
>
> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
I swear I did.
That said, looking at that RFC it's a slightly different take than what I am
suggesting. This RFC suggests that string enums automatically implement
Stringable . I am pointing out that i
Hey all,
I poked around a bit in the Enum RFCs and I could find (maybe I missed) what's
up with this:
enum Foo:string implements \Stringable
{
case FOO = 'bar';
public function __toString() {
return $this->value;
}
}
PHP Fatal error: Enum Foo cannot include magic method __toString
It seems to m
On Aug 14 2024, at 5:27 pm, Lanre wrote:
>
> Can you point out where either of us suggested writing PHP in another
> language? You might be mixing this up with the C11 thread, which has nothing
> to do with this. All I'm proposing is improving the current C++ support in
> the engine.
> https
Friend, honest to god you are really not doing yourself any favors here.
You came on this list with a proposal. I think it's a bad idea, and I've
enumerated the reasons why I have come to that conclusion:
If it's so easy and transparent to improve support for C++, it could easily
exist outside o
lol. Listen friend, I've been involved in PHP internals on and off for over 20
years -- and so has Pierre. You'd do well to respond with a little more
consideration instead of flying off the handle calling us ignorant rust
developers lol.
The idea of enhancing support for C++ makes no sense. It
On Aug 12 2024, at 12:27 pm, Lanre wrote:
>
>
> On Mon, Aug 12, 2024 at 9:58 AM John Coggeshall (mailto:j...@coggeshall.org)> wrote:
> >
> > > > I’m considering adding some C++ enhancements to the Zend API.
> > I would definitely like to see an RFC for this
> > I’m considering adding some C++ enhancements to the Zend API.
I would definitely like to see an RFC for this if it was to be considered. To
me, adding a whole new way of doing things internally without completely
removing the old way is just asking for a more brittle, potentially less
secur
> That being said, I support your RFC. It seems like a better solution than
> mine. However, I would ask you to change your tone to be less offensive,
> because rudeness is not a welcomed behavior on the mailing list, and by the
> way, we have the same ultimate goal of improving PHP, even if you
On Jun 7 2024, at 8:49 pm, Erick de Azevedo Lima
wrote:
> The new keyword is meaningful and everyone knows what's being done just by
> looking at it. Removing it would make the language less readable. But it's a
> BC so big that I don't think it can be done anyway.
>
>
FWIW Languages like Da
> So here is my proposal :
>
> Add a "new" shorthand, using the tilde character : "~"
-10.
Please, don't make PHP as unreadable as Perl. IMO It's two extra characters at
worst and would be solved much more elegantly by removing the new keyword
entirely.
J
> > 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 either
> 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 someth
> 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 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 votes.
That is
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 wrote:
> This could be good. A custom built site where people can vote for and
> against (and maybe neutral) something and then post their reasoning.
>
+1 as Lukas, on adding but not enabled by default.
On Jun 20, 2010, at 4:39 PM, Lukas Kahwe Smith 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 reasons no
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 i
+1 for HEAD and 5.3
On Tue, Jul 7, 2009 at 1:55 PM, Gwynne Raskind 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
btw).
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 lik
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 i
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: ht
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 Mailin
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 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 beginnin
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
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 = ne
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 'tousa
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 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: http://ww
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: http://
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,
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
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 adoptio
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 f
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
th
Nuno:
Do you know when the BC break was with libtidy? I'll need to add a
config.m4 check at the very least.
John
On Wed, 2006-04-19 at 23:13 +0200, Steph Fox wrote:
> > I just thought that since we're looking at tidy we might as well update
> > the libs on win32 build boxes :)
>
> Mm but actua
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
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 Lync
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'v
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, 2006-03-0
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 rep
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 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 interna
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 warnin
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 o
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 se
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
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 ar
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
>
ut
> >>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 at it and commit if it looks good.
>
things just because we find them
> aesthetically 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 >
> > John
> >
>
So very -1 on anything introducing another way to print stuff. I am
however +1 on turning off everything but Marcus Boerger wrote:
> > Hello Wez,
> >
> > we could however drop '<%' support and introduce '
> You'll have to pry '<%' from my cold, dead hands :)
>
> Edin
>
--
PHP Internals - P
Removing the Can't help it... ;) By the way, I thought all programmers were lazy to some
> extent?
>
> Seriously though, I think it would be nice and consistent if it would work.
> I just really like the short
> Ron
>
>
> "Joseph Crawford" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PR
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
On Mon, 2005-08-29 at 13:23 +0200, Steph wrote:
> It's the 'given that it doesn't appear to have an active maintainer' part
> that's important here. It takes a little TLC to make a PECL package
> available for download.
I'll roll the PECL package myself.
> > > I'm well aware of ext/xmlrpc's limi
hat I'm not hugely concerned with
*when* this happens (read: What version of PHP the change 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.
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 w
se 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:
> &g
1 - 100 of 216 matches
Mail list logo
