my point: I'm not saying we won't need to begin
> soon, but I do not accept the way it is done, the total lack of
> respect of the other core developers and the total lack of roadap,
> consensus or general agreement about what will be php-next.
+1
regards,
Lukas Kahwe Smith
m...@p
only then bring it back to this
list.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a much better work flow already
to handle feature branches.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11.08.2010, at 14:14, Richard Quadling wrote:
> So, the trunk keeps strict typing.
no .. a controversial patch like this should never have gotten into trunk
without a vote. the only place for this patch in the svn.php.net repo would be
a feature branch.
regards,
Lukas Kahwe Smit
n't know why nobody cares (well I do ;), but this is totally
> insane. Do we ever learn? PHP6, the last 5.4 horrible episode, etc.
> And as we clearly see today, we are not ready.
+1
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Developm
type
check changes should be moved to a feature branch.
just committing, and then try to wait for a moment when nobody complains (guess
it didnt work this time) to release the commit has been done before i guess,
but its not the way to go .. for obvious reasons.
regards,
Lukas Kahwe Sm
gt; This only works if manage to keep the time between "new code is
> committed to trunk" and "new code is released" under a year. Otherwise
> developers get frustrated.
>
> If we manage to release a PHP 5.X.0 release every year, we are a lot
> more predictabl
vide? Seems to me like this is something
the linux vendors take care of for the most part. Of course this leaves
windows, OSX (and maybe some others).
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
and assist the doc team
in writing the migration guides.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
arding closures/$this ...
subscribe to the RSS feed on the wiki.
also .. the time is now to discuss the future and get changes into trunk
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
urself.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 12.07.2010, at 21:22, Reindl Harald wrote:
> Am 12.07.2010 21:16, schrieb Lukas Kahwe Smith:
>
>> I am sorry but I think you have to accept that this service will not be
>> provided
>> by php.net (for which version of PHP should be release the security patches)
>
ns of PHP just to get security fixes, but for those
people who prefer to stick with one version of PHP and simply get security
backports, there are plenty of distributions to choose from that provide these
services for free or via a subscription.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
kinds of
optimizations because its now possible to more tightly integrate with core?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hink this type of BC break in an edge feature (or
rather edge bug) would be ok in a major update to the language.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
by default .. or rather undecided at this point.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
inally IIRC there was a mysql->mysqli conversion script
that could be prominently placed in the docs. and of course we can add
deprecation notices.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 18.06.2010, at 18:13, Christian Kaps wrote:
> On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith
> wrote:
>> On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote:
>>
>>>
>>>
>>> On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
>>>
d be *any* class if you're
> modify the behaviour of some default methods (say doing something like a
> decorator pattern). Having a type hint that recognises object vs non objects
> is useful.
isnt this what interfaces are for?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
quot;. Yet now this is a specific pgsql*** interface that cannot be
> abstracted for other drivers OR implemented at the driver level. Now
> if I want a MSSQL / Sybase dump/load method, I need to preface it with
> dblibCopyFrom, dblibCopyTo.
right .. Ilia just chose to ignore the rest o
s. Thus,
> static variables should be independent for the different traits usages.
>
> Any thoughts on that?
i agree. the mantra is traits are engine level automated copy&paste.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing L
gure out some sensible
way to let people vote on the various solutions that are proposed.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
de an optional variant to get an E_FATAL instead
of E_STRICT, though I personally do not see the need for it.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 03.06.2010, at 18:57, Ferenc Kovacs wrote:
>
>
> On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith wrote:
>
> On 03.06.2010, at 18:25, Josh Davis wrote:
>
> > On 1 June 2010 20:43, Stas Malyshev wrote:
> >
> >> It is very frequent that you w
typos to result in hard to debug
issues. Sure sounds good and I guess there probably is a market, maybe even an
urgent need for a strictly typed scripting language for the web space.
But really is PHP the best basis for this?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e using pcre? If not: Less code to maintain -> less
> trouble :-)
i would still keep it deprecated simply because people should not write new
code with ereg, even if we do not have to remove it because of lack of unicode
support.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 28.05.2010, at 11:50, Lukas Kahwe Smith wrote:
>
> On 28.05.2010, at 11:22, Etienne Kneuss wrote:
>
>> so, it would be nice to update the RFC(s), so that we have a solid
>> ground on which we can discuss/vote.
>
>
> i agree. i currently see 5 fundamental
t they want to veto.
of course if 6) gets voted for we would then have to decide on which of the
permutations (1/3, 1/4, 1/5, 2/3, 2/4, 2/5) to go with in a second vote.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
PS: of course for 4) i see some suboptions
a) raise an E_STRICT on data loss
ype juggeling in PHP). However I can also accept if we simply
stick with the same rules as PHP has atm (albeit still with the addition that a
cast that causes data loss would not happen silently
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
T
t type if you specify so. So
> this is moot point.
well most people do not use that since its just as tedious to use as having to
cast your results. of course if we did have strict typing it would probably
become more widely used, not that having to add those lines of code are
something i
e effort as possible to be as functional and
secure as possible?
Again, API developers are likely to be more competent than those consuming the
API's that just how the food chain goes. Furthermore every API method will be
called multiple times and so moving the validation/cast log
letely against the
> auto-conversion hint idea.
the current proposal is quote the opposite from obfuscation since it would
alert the user if the conversion would imply data loss.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
uot;cake or death" a new dimension :)
seriously php.ini settings to manipulate how core syntax is interpreted are a
no no.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
With the proposal of weak typing with error/notice on data loss none of that
would be needed.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
go with enabling
type hinting or full out strict typing.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hello world
heh ... you are selling recoverable errors as anything but a solution to
display something else than a white screen?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
st a few mails early in the thread than yours:
http://wiki.php.net/rfc/typecheckingstrictandweak
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tied up in a perpetual battle. Over the years I got a few things to go the way
I wanted (wiki, a todo list, RFCs) but there are simply some fundamental things
where I am no longer motivated to work with the status quo, but where I do not
see a realistic chance if this ever changing.
regards,
improvement. Cons: BC
>> break from current documented behaviour.
>
> Once and for all: +1 for #2 (BTW that kind of BC will not be that hard to
> fix!)
we have had the topic of making PHP case sensitive before. I do not find the
above reason all that compelling to make thi
would hold off with doing this change until we have our unicode plans more
concrete, because this might result in yet another change in this area.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
PS: Then again .. the entire unicode discussion seems to have died on this list
and I am not aware of
d; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe
>>> Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List
>>> Subject: Re: [PHP-DEV] trunk is alive and open
>>>
>>> On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote:
>>>> Bef
ed for
some out of the box BC extension), than this would be the moment to fix stuff
like this.
Anyways, if anyone cares about any of the above proposals write up an RFC (or
champion an existing one). Lets not end up in a situation where we have to
refer people to the archives to understa
tion
> syntax, will it look something like this:{'a'=>'b', 'c'=>'d'} or will it
> look like {a: 'b', c: 'd'} ?
Just stumbled over a post about SQL 2011 which also seems to get support for
named parameters for functions
y got karma and told me he can commit his traits patch after the
15th.
I do not really think we should leave out the aliasing, lets have as many
people as possible play with it as is. We can always tweak/change/drop it later.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internal
. Thanks for sharing the results!
So where do we stand here? Do we want to start rolling these changes into
trunk? Could the changes and additional proposals be tracked inside a wiki RFC?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development M
Hi,
Anyone core to summarize the thread on the wiki? can just be a couple of
sentences and links to news.php.net.
regardsm
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
likely to resurface in trunk at
> some point and it doesn't make sense to lose this feedback.
was anything done here yet?
i presume someone could just change the version to "PHP6-First-Experiment" or
something on the database ..
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
by links to news.php.net. Also try to keep the relevant people in the
loop as you are summarizing them. In order to get a wiki account just follow
the "register" link on the "login" page.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtim
that
was before we unified the parameter parsing API. IIRC hartmut was quite
involved in the discussion back then .. maybe he remembers.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
add named parameters
are you just use the current work around for the absence of named parameters
(aka an array parameter and array_merge/array_replace_recursive)
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t;> zend_throw_exception_ex(reflection_exception_ptr, 0 TSRMLS_CC,
>> -"Property %s does not exist", name);
>> +"Property %s::%s does not exist", ce->name, name);
>> }
>> /* }}} *
>>
>> The patch is against SVN trunk
what's going on.
>
> When magic_quotes and register_globals will, finally, be killed in
> PHP6, this could be, finally, a real security feature, couldn't it?
>
> Greets,
> Daniel Zulla
>
> [1] Code Example:
> request_init(Array(POST, GET), Array(userid => IN
hen cherry pick.
So yeah, lets get it into trunk.
+1
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e link is here (can be
found by clicking on "login" on the lower right navi bar):
http://wiki.php.net/start?do=register
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
would think
that it would help a lot to get the RM's sorted out quickly, so I would really
ask all people to quickly chime in with their preference, nominations or
whatever else might matter to get this decision finalized.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Intern
On 25.03.2010, at 22:59, Stefan Marr wrote:
>
> On 25 Mar 2010, at 21:30, Stefan Marr wrote:
>> On 25 Mar 2010, at 16:37, Lukas Kahwe Smith wrote:
>>> Hi,
>>>
>>> this was just brought up on IRC. my understanding is that traits have no
>>>
ct, right. You can not instantiate traits.
> But, I would not speak of multiple inheritance. I would prefer something
> along the lines of 'sustainable copy'n'past reuse'.
I think Stefan used the right metaphor in the RFC: its language level copy
paste.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 25.03.2010, at 21:13, Stefan Marr wrote:
> On 24 Mar 2010, at 11:50, Lukas Kahwe Smith wrote:
>> "In case of the above definition of Talker, PHP will show a warning that
>> there have been conflicts and name the methods smallTalk() and bigTalk() as
>> the reason o
Hi,
this was just brought up on IRC. my understanding is that traits have no
concept of properties, but grafts do (all hidden internally). correct?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
> during runtime and should be douable in PHP too. For sure aliasing is not
> possible in this example.
>
> But as said just a general idea that I might try to work on once traits are
> comittet.
>
> Stefan what do you think about "stackable traits" ?
Woha .. that
On 24.03.2010, at 21:26, Hannes Magnusson wrote:
> On Wed, Mar 24, 2010 at 21:12, Lukas Kahwe Smith wrote:
>>
>> On 24.03.2010, at 21:10, Hannes Magnusson wrote:
>>
>>> On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith
>>> wrote:
>>>> Hey,
On 24.03.2010, at 21:10, Hannes Magnusson wrote:
> On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith wrote:
>> Hey,
>>
>> Could one of you write up a short RFC on this patch? Just some details about
>> the bugs fixed, known BC breaks and (undocumented) edge case
ctually
think its quite the opposite. I think it would be great for PHP to have him
take an "official" role. I have full trust in his integrity and so it might be
also a good signal after the entire PDO2 CLA debacle that we do have trust in
working with people from big corps.
Hey,
Could one of you write up a short RFC on this patch? Just some details about
the bugs fixed, known BC breaks and (undocumented) edge case changes. This
would be helpful for anyone wanting to review their code and testing as well as
documentation.
regards,
Lukas Kahwe Smith
m
ple can integrate them as they see fit, like they can use
delegation if they are still on an older version of PHP or use Grafts. I also
envision that there will be less surprises when using Grafts and this fits well
with the approach to keeping the barrier to entry low for PHP development.
re
oice.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
should there still be any.
In conclusion:
There should of course be fun in just hacking out cool stuff, but I think for
most developers a big part of the fun is actually seeing your ideas in a stable
release.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime D
If thats the case then I will work
> on merging those removed features like safe_mode and so on out.
uhm no .. i think for that stuff we have to wait until we decide if the next
version is 6.0 or 5.4
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Developmen
On 23.03.2010, at 17:59, Rasmus Lerdorf wrote:
> On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote:
>>
>> On 23.03.2010, at 17:21, Rasmus Lerdorf wrote:
>>
>>> On 03/23/2010 09:11 AM, Pierre Joye wrote:
>>>> hi,
>>>>
>>>> I
rovements (*)
(*) lets see what ideas we come up with, might turn out to be the big thing or
maybe just a small incremental tweak here and there
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 18.03.2010, at 18:48, David Soria Parra wrote:
On 2010-03-18, Pierre Joye wrote:
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans
wrote:
I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it
I propose that sort of a
unicode working group forms but much less formal than what I make it
sound like. I think the discussions can remain on internals@ and
hopefully alternative approaches will be documented as RFCs. But what
I mean with working group is a list of a handful of names who feel
en review your patch when it comes to
SQL server. Maybe Matteo has some time to take a peek. Especially in the
beginning its very helpful to get some feedback on patches before getting
direct commit access. Then again for PDO we might be at the stage where we
might not even have the resources to do that :(
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ations.
+1 .. this all aligns perfectly with my suggestion to establish a "unicode
working group" that I made in the "PHP 5.4 branch and trunk" thread. so just
like you i agree that we shouldnt put the next release under the pressure of
delivering "the unicode answer&quo
and so that the ideas
do not get lost in the archives. Again the wiki is the perfect place for this.
Also this will help others to collaborate in moving the idea to a full fledged
proposal .. ideally with some numbers to backup any performance claims.
regards,
Lukas Kahwe Smith
m
hould have regular releases. So I say we shoot for the release following the
next one to come out in the summer of 2012.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
st". Ok this isnt a good suggestion,
but I hope you get what I am suggesting.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n.
> You didn't even list the mbstring patch.. that was discussed and as
> far as I remember everyone thought it was great idea, just not in a
> stable branch.
Is this tone really necessary? One you are argueing for more flexibility and
then you are shooting the messenger because in a
s in how to keep svn running. I see little incentive to move
the _central_ repo to a DVCS. Are the bridges to git, mercurial, bzaar etc
really so bad that this topic is worth discussing (no sarcasm, honest
question)?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ch create a
branch and work things out there. This way normal development in trunk can
commence.
But again, I really do hope that we can however wrap up the debate up by end of
April.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
[1] http://wiki.php.net/rfc?do=register
[2] http://wiki.php.net/
6 need to be ... punished ;-)
> Is that wise and well-considered or something the community might regret in
> the long run?
Nobody needs to be punished and I think Rasmus stayed clear of such words for a
reason. The name of the next version is not really all that relevant more if
the next
th work or god
forbid go on vacation). I am willing to take the co-RM role again. I can also
see Philip in this role. But I think the more important question is to find the
technical RM and if the technical RM feels like he can use the support he can
just appoint a co-RM.
regards,
Lukas Kahwe
> the talking openly on the mailing list, not some IRC channels. And no more
> wikis. :)
i hope you mean internals and not the svn commit mailinglist. so much for
dagger style ..
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
T
On 11.03.2010, at 18:54, Johannes Schlüter wrote:
> On Thu, 2010-03-11 at 18:46 +0100, Lukas Kahwe Smith wrote:
>> +1 for moving trunk to a branch and moving 5.3 to trunk.
>
> not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
> stable stuff (fixes) only. Gues
on those in
> trunk. Other features necessarily need to play along with these in the
> same branch. I refuse to go down the path of a 5.4 branch and a
> separate Unicode branch again.
>
> The main focus here needs to be to get everyone working in the same branch.
+1 for moving
On 11.03.2010, at 17:26, Jani Taskinen wrote:
> On 03/11/2010 06:21 PM, Scott MacVicar wrote:
>>
>> On Mar 11, 2010, at 10:22 AM, Jani Taskinen wrote:
>>
>>> On 03/11/2010 04:41 PM, Lukas Kahwe Smith wrote:
>>>> @jani: committing to a stable branch bec
se you are getting a new laptop is
not really a convincing argument. :)
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ime i know that it hurts and php6 not
moving forward is the root cause there.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 03.02.2010, at 00:24, Guillaume Rossolini wrote:
> Upgrade wiki.php.net (as per lsmith's and pierre's request)
indeed thats correct.
thx Guillaume
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
t one as well and see if any others make sense.
>
> I do think the syntax is a bit ugly, but I also think it is clear what
> it does and doesn't obscure/mislead the semantics of the call the way
> the (new foo)->bar() suggestion does.
+1
regards,
Lukas Kahwe Smith
m...@poote
at hurts readability, not really.
if you are worried about key strokes switch to an IDE. if you are worried about
performance use a byte code cache.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on the policy front?
>
> As you can tell, I am itching to see where this goes ;)
just FYI:
a tweaked stream_resolve_include_path() is scheduled for inclusion in PHP 5.3.3
do note that the next PHP 5.3 release will be 5.3.2, so it will be a few months
until we will see this feat
5.4 should there be one).
>
> So: What now?
Call for a vote. This time around people cannot claim to not have had time to
review the issue. Also back then we tried to play it safe because of the short
time before we were to release. This time there is more time for this to mature
if
d when a reason for not merging a ticket is added to the
wiki it would be automatically submitted to the bug tracker as a comment. Not
sure how easily this could be done though and I cannot commit time to checking
this out myself :-/
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PH
ted to
using a branch or not.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
came along fairly ad hoc. However I do agree that the wiki is not the right
place for this in the long run. Like I said, I believe the bug tracker is the
place for this by adding milestone support. This would also be the natural
place to note why a patch is not merged for example.
regards,
Making sure that every commit has a bug id attached (or if
necessary gets a bug ticket created on the fly and the id injected into the
commit) could also help.
Obviously such infrastructure will not materialize over night, but I would urge
everything to not drop the idea entirely.
regards,
On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote:
> I have updated the current RFC accordingly:
> http://wiki.php.net/rfc/autoload_include
>
> So there are three approaches listed in the RFC:
> 1) http://wiki.php.net/rfc/autoload_include#proposal
> add a new alternative to in
nd for example the session
handler that comes with the Memcached extension? could you provide a code
example of how that would look like?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote:
> So there are three approaches listed in the RFC:
> 1) http://wiki.php.net/rfc/autoload_include#proposal
> add a new alternative to include, which works the same except that for
> missing files it returns null and on success it retu
1 - 100 of 900 matches
Mail list logo
