, 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...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
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 Smith
m
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 Development Mailing List
To unsubscribe, visit: http
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 Smith
m
branches.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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 predictable. Which is good for downstream as well.
+1
regards,
Lukas Kahwe Smith
m
guides.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
place for end-users to stay up-to-date on such
topics? i'm looking at the php RFCs every ones in a while, but there was no
update regarding 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
.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
how to do it.
well couldnt the compat layer be written in PHP? i think this will send a
fairly clear message. finally 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
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
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
--
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 m...@pooteeweet.org
wrote:
On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote:
On 17 Jun 2010, at 20:14, Stas Malyshev wrote:
Hi!
I know the discussion is about scalar type
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 of the developers.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP
.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
should be independent for the different traits usages.
Any thoughts on that?
i agree. the mantra is traits are engine level automated copypaste.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
E_STRICT errors that come up?
Not very efficient.
Same deal as E_NOTICE. Either you care about them or you dont. Anyway, in my
weak typing proposal I also made 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
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
On 03.06.2010, at 18:57, Ferenc Kovacs wrote:
On Thu, Jun 3, 2010 at 6:32 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 03.06.2010, at 18:25, Josh Davis wrote:
On 1 June 2010 20:43, Stas Malyshev smalys...@sugarcrm.com wrote:
It is very frequent that you want number and get
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 different options on the table:
1
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
To unsubscribe, visit: http
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
:)
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
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
To unsubscribe, visit: http://www.php.net
?
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 logic there is simply
efficient.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
strict typing it would probably
become more widely used, not that having to add those lines of code are
something i would like to see in my code (the speed gains are
microoptimizations for most use cases of PHP).
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime
in with the question if API consumers are likely to have properly typed
(aka typed in the way the _various_ API he consumes expect) by default or not.
i think this is the key question to answer when deciding to go with enabling
type hinting or full out strict typing.
regards,
Lukas Kahwe Smith
://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
screen?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
all that compelling to make this change. However there are several
other reasons that imho are more relevant for making this change.
RMs: should this really be part of PHP 5.4 if it gets approved?
no way.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime
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 any documentation having been made or any
be a shame if that waited
until Q4 for alpha. I think with traits, performance enhancements and a few
additional changes we already have a pretty substantial version.
+1
+1
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
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 understand a previous decision ever again.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
arguments in function calls. PostgreSQL 9.0 supports that, but using the
syntax foo(3 AS a) instead of what ended up in the standard, foo(a = 3).
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
[1] http://petereisentraut.blogspot.com/2010/04/news-from-sql-standard.html
--
PHP Internals - PHP
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 Internals - PHP Runtime
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 Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-name, name);
}
/* }}} *
The patch is against SVN trunk.
looks good for me. if there are no objections from someone else I'll
commit it tomorrow.
@David: seems like you forgot to commit this?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development
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
killed the discussion last time around. i think it
was concerns over having to convert all internal functions, but i guess 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
,
Daniel Zulla
[1] Code Example:
?php
request_init(Array(POST, GET), Array(userid = INT, pass =
mixed), $callback-crap_transmitted, 1);
?
html
are you aware of the filter extension:
http://php.net/filter
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime
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
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
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 Internals - PHP Runtime Development Mailing List
To unsubscribe
traits are
comittet.
Stefan what do you think about stackable traits ?
Woha .. that code really scares me.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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 of this conflict. Therefore, neither
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 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
concept of properties, but grafts do (all hidden internally). correct
,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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.
regards
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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.
regards,
Lukas Kahwe Smith
m
On 24.03.2010, at 21:10, Hannes Magnusson wrote:
On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith m...@pooteeweet.org 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 changes. This
would
On 24.03.2010, at 21:26, Hannes Magnusson wrote:
On Wed, Mar 24, 2010 at 21:12, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 24.03.2010, at 21:10, Hannes Magnusson wrote:
On Wed, Mar 24, 2010 at 11:54, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
Hey,
Could one of you write up
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
.
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 Development Mailing List
of
delivering the unicode answer .. if the working group gets done in time we
can move it into the release plan, if not .. so it goes .. with regular
releases the next chance to get unicode in isnt too far off.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime
. 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
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
On 18.03.2010, at 18:48, David Soria Parra d...@php.net wrote:
On 2010-03-18, Pierre Joye pierre@gmail.com wrote:
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans der...@php.net
wrote:
I do agree that we need to do major releases more often, but just
setting a time already feels wrong.
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
.
Is this tone really necessary? One you are argueing for more flexibility and
then you are shooting the messenger because in a long list he forgot one thing
(there are probably a few others .. we might want to go through the todo wiki
pages for more)?
regards,
Lukas Kahwe Smith
m
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
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
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/todo/php60
--
PHP Internals - PHP
Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
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 version will be a minor bump (aka x.y+1) or a major (aka x+1.y).
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
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
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
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 because you are getting a new laptop
is not really
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 trunk to a branch and moving 5.3 to trunk.
regards,
Lukas Kahwe Smith
m
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. Guess you meant to say
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
To unsubscribe, visit: http
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, visit: http
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
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...@pooteeweet.org
--
PHP Internals - PHP Runtime
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 feature in a stable release.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
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 needed inside svn.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing
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 include, which works
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,
Lukas Kahwe Smith
m
. 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,
Lukas Kahwe Smith
m
.. then all that needs to happen
is to inform relevant developers once .. and nothing breaks if they do not know
about it at a fixed date .. like with a commit freeze.
In other words, the problem might exist, but its solvable and is unrelated to
using a branch or not.
regards,
Lukas Kahwe Smith
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
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 03:13, D. Dante Lorenso wrote:
Lukas Kahwe Smith wrote:
On 21.11.2009, at 22:29, Dante Lorenso wrote:
I would love to restate my recommendation for the function filled.
Which is the opposite of empty. Filled would accept a variable
number of arguments and return the first
to 5.3.2 or if it should wait
for the next minor/major version update instead.
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 returns the file
already been discussed and declined:
http://wiki.php.net/rfc/ifsetor
please review this rfc before continuing this thread.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to find out why something wasnt done etc.
This helps in avoiding redundant discussions, but also helps people if after
all certain changes do become possible/feasible eventually.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
notices for undefined variables.
This is not the same as the ifsetor debate because filled is opposite
empty and cares not about isset.
did you even read the RFC?
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
similar use cases, like having to deal
with legacy code.
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.11.2009, at 10:47, Richard Quadling wrote:
2009/11/11 Lukas Kahwe Smith m...@pooteeweet.org:
[snip]
Would using a userland-based set_error_handler() be of use here?
If, under normal circumstances, blind include() is what is used, then
trapping the error when it fails would be when
with exists
is better (for example include_file_exists(), though also not
ideal) .. Stas proposal of a file_find() is also good, but I think
it would be nice to have include in the name.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
1 - 100 of 846 matches
Mail list logo
