Thies C. Arntzen wrote:
and this is 'cause pdo _expects_ the user to prefix the bound variables
with a colon. grr...
ppls, lets change it before it's too late. this "tiny bit" makes binding
harder than it should be, and we all know and understand that all user
of php should use bound variables
Jared Williams wrote:
$sql = "insert into $table ($col_list) values ($bind_list)";
Can I just point out that you've just negated the whole reason for having parameters in the first place, imo.
uhm the point of prepared queries is not to eliminate sql injection.
thats just an added benefit
$tab
Wez Furlong wrote:
Yep, will do.
I dont want to pretend that this change should open the flood gates for
radical changes. However there are still a few minor points beyond the
bindParam() that may need minor adjustments. Some of them can be added
later of course ..
1) DSN http://oss.backendmedi
Alan Knowles wrote:
I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html
and slightly related
http://www.akbkhome.com/blog.php/View/76/r
Sebastian Bergmann wrote:
Andrey Hristov wrote:
isn't this going to blow up existing applications that define class
File?
It already "blew up" existing applications before this commit.
I'd say that all extensions should really follow the 1 prefix per ext
for anything that ends up in the global
Hi,
it would be very useful if class_implements()/class_parents() would also
handle a string containing a class name instead of requiring an object
instance.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andrey Hristov wrote:
Hi Marcus,
what about class_constant_exists("classname", "const")
(a bit long function name though)?
maybe leave of the ant ...
class_const_exists()
fits in with
class MyClass
{
const constant = 'constant value';
function showConstant() {
echo self::constant .
Grant Croker wrote:
I would like to submit the following patch to PHP:
http://www.ingres.co.uk/php/head/ingres_error_reporting.diff
It includes 3 new functions for reporting errors; ingres_error(),
ingres_error_text() and ingres_error_sqlstate(). Also included is the
ability to suppress E_WARNING m
Lukas Smith wrote:
Wez Furlong wrote:
Yep, will do.
I dont want to pretend that this change should open the flood gates for
radical changes. However there are still a few minor points beyond the
bindParam() that may need minor adjustments. Some of them can be added
later of course ..
I also
Wez Furlong wrote:
How about sitting down together at php|tropics
Sure.
and simply going through each of the methods one by one.
Looking at what kind of methods names we currently are using for the
same or similar things in any of the current projects on php.net and
make any adjustments then?
Ma
George Schlossnagle wrote:
I'm not an OO expert, but doesn't this break a fundamental semantic of
OOP -- namely that new() returns a new object of the specified class.
Isn't this the whole reason that the Singleton pattern exists?
yeah I would agree that we should always try to find a non magic
Sebastian Bergmann wrote:
Lukas Smith wrote:
http://bugs.php.net/bug.php?id=30235
I agree with Marcus: self is bound at runtime, so the behaviour is
correct. If you do not like this late binding just do not use self but
the name of the class.
So please explain to me how you would write a
Lukas Smith wrote:
Sebastian Bergmann wrote:
Lukas Smith wrote:
http://bugs.php.net/bug.php?id=30235
I agree with Marcus: self is bound at runtime, so the behaviour is
correct. If you do not like this late binding just do not use self but
the name of the class.
So please explain to me how you
Leonardo Pedretti wrote:
It would not be such a problem to write something that does the same task
through a static or global function, but unfortunately it is impossible, due
to the following: you can build a cache in an array, then in a __new()
function you could check if the requested object
Leonardo Pedretti wrote:
Yes, the question was pointed in another way, the destructors are not called
until the last reference to an object has been removed, but if you store a
reference in an array so you lately return a reference to the already loaded
instance instead of creating an aliasing o
Ondrej IvaniÄ wrote:
class SingletonFactory {
private $instances;
__construct() {
$this->instances = array();
}
function getInstance($name) {
if(is_a($this->instances[$name], $name) === false) {
$this->instances
Thomas Richter wrote:
Lukas Smith wrote:
FYI: SingletonFactory can be a pure static class.
yes it just doesnt work if you normally already use a factory
..because then you cant do $name::factory();
call_user_func(array($name,"Factory")); ??
that works if you store the class name for e
Nicholas Telford wrote:
What I'm proposing is to allow PDO::query() to return a subclass of
PDOStatement. This would allow abstractions to tailor the result set to
their own needs while not (in theory) being too complicated to implement.
My initial idea involves passing an object that is a subcl
Nicholas Telford wrote:
Wez Furlong wrote:
It's generally a bad idea, and definitely something to avoid if you
are building a class library.
You have now been warned that the traffic is dangerous; if you want to
go play in it, it's your choice :-)
The same could be said for using an external Fram
Derick Rethans wrote:
Hi Dmitry,
On Thu, 26 May 2005, Dmitry Stogov wrote:
This patch breaks binary compatibility.
It cannot be broken in 4.3.x tree, and that doesn't make sense to release
4.4 just for this patch.
You mean that they think that it doesn't make sense to fix PHP in cases
whe
Marcus Boerger wrote:
4) I still want the ifsetor operator since it is very helpfull and again
simplifies a lot of things.
+1
+1 for goto as well
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
DR>>which is ugly and already possible anyway).
Using control blocks is no more ugly than using goto's - and thr right way
to do it is using exception handling and finally, IMO.
well exceptions as we have them right now are everything and much much
more than what
Stanislav Malyshev wrote:
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.
so I guess the only additional danger I can see from goto is someone
jumping from goto A to goto B and th
Ilia Alshanetsky wrote:
Stanislav Malyshev wrote:
IA>>Ok, so you propose that people start using exceptions for OO and
IA>>procedural code just because they are "there"? One major problem with
No, I don't propose that. I am just concerned once you put goto there
it would be abused in all kinds
Stanislav Malyshev wrote:
MM>>Exceptions ? No thank you, even worse then continue/break..
Why is it worse? That's something that I don't understand - why people
think exceptions, which have clear structured mechanism of using them, are
worse than goto which has no safeguards at all and allows
Stanislav Malyshev wrote:
LS>>the safe guard is that you only have:
LS>># static labels to jump to
That's not a safeguard, since you still can jump to any label.
it is combined with the fact that you cannot jump out of the scope ..
should make it really easy to do a simple search for the labe
Stanislav Malyshev wrote:
LS>>> No, they do not. You can not exception to abritrary point of the code. You
LS>>
LS>>but it can be a "relatively" arbitrary point in the sense that the catch can
LS>>be endless lines of code away ... effectively making a search a very tedious
LS>>process.
Ever tri
Hi,
A while ago someone on IRC suggested that it might be a good idea to add
"public" to PHP 4.x for forward compatibility. I brought it up again on
IRC yesterday and several prominent members of the php core community
said it would be a good idea to add to the 4.4 branch.
The patch seems to
Stanislav Malyshev wrote:
LS>>I think its a good idea to have, to make it somewhat possible to prepare for
LS>>the PHP5 E_STRICT world, while still developing PHP4 compatible code. I
LS>>could for example see this help increase the PHP5 adoption inside PEAR,
Like, PEAR would drop support for PH
Stanislav Malyshev wrote:
I wonder what was the original purpose of PHP5 emitting warning when
seeing 'var'? What are you basically saying now is "I want PHP4 code that
wouldn't have messages on my class vars if run in PHP5". But I'm sure
there was some idea behind these warnings, not?
There
Sebastian Mendel wrote:
and is it a problem to implement such a new error level also with PHP
4.4. for example reporting overwriting $this is not allowed in PHP 5 ?
and, when we are at this, what about 'clone' as a dummy-keyword in PHP 4.4 ?
err no .. because that would break existing php 4 c
I wonder if it wouldnt be enough to be able to force the triggering of
__set(), __get() for all properties be enough to deal with your situation?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
On Thu, 4 Aug 2005, Lukas Smith wrote:
I wonder if it wouldnt be enough to be able to force the triggering of
__set(), __get() for all properties be enough to deal with your situation?
No, besides that would break BC, it would also not solve the problem of
returning
Marc Boeren wrote:
So what is needed to get it on the pecl site in the packages list?
1) It needs to become registered as a package:
http://pecl.php.net/package-new.php
2) In order to be downloadable it needs a release:
http://pecl.php.net/release-upload.php
For all of these steps you need t
Andi Gutmans wrote:
I don't agree that instanceof on a class which doesn't exist should
work. It doesn't do so in other languages (or at least not in
Java/C++(dynamic_cast)) nor does it really seem to make a lot of sense
and be useful. Sounds more like an edge case you have hit with some
weird
Alan Knowles wrote:
On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
You are wrong because __autoload() *is* called and you can load the class
on the-fly. The only problem is if the class does not exist in your code
base, in which case, your application should blow up!
The basic point
Wez Furlong wrote:
On 8/9/05, Pierre-Alain Joye <[EMAIL PROTECTED]> wrote:
5.x - small additions (in my case, gd updates and merge,
xmlwriter)
This is what PECL is for. We're trying to move stuff out of the core
so that these kinds of updates are easier for everyone to work on and
Andi Gutmans wrote:
I am not stubborn. I just think this has close to 0 use in real-life (or
you're doing some weird coding). In any case, for the one in a million
case, I think Reflection is good enough.
I worded my example a bit wrong. I dont like people loading PEAR.php on
demand. However
Derick Rethans wrote:
On Thu, 11 Aug 2005, Derick Rethans wrote:
I believe we mentioned once the possibility of adding another error level,
which is fatal - but still catchable by set_error_handler(). That is a good
idea (which we should be doing either way).
That would work well. I just wa
+1 on all the mentioned items, except for case sensitivity for
identifiers where I am -1 (I dont see the benefit).
Aside from that I wouldnt mind an aggressive function name and parameter
order clean up. We could provide a BC lib via runkit (or was it classkit
.. I can never separate the two i
Ron Korving wrote:
13. A built-in code optimizer. Why should something like Zend optimizer be
installed afterwards, if everybody can use increased performance?
IIRC George once played around with a few peekhole optimizations for
APC. I think the performance improvements possible with peekhole
Marcus Boerger wrote:
11. class operator cleanup
:: static
-> non static
this would allow to do more things like accessing static members/consts
from anywhere a class is allowed etc. (if proposed that before incl. patch
lookup the archieves).
could you elaborate what you mean with th
Xuefer wrote:
possibly make a internal or loadable "argument reposition table", enabled with:
declare(fix_function_argument_position);
fix at compile time, no performance lost on runtime.
but might confuse the debuger if the origin position in source is
forget after compile
As I suggested by u
Ron Korving wrote:
16. Support for
that reminds me:
set short_open_tags to off in any sample php.ini we ship.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski wrote:
Even if we forget about the users, and only think about ourselves -
unless something drastic happens, we're going to look at supporting 4
major different versions simultaneously - 4.3/4.4, 5.0, 5.1 and 6.0. Is
it really such a great idea to start breaking compatibility bey
Zeev Suraski wrote:
If we are to continue with that idea, we need to strike that one out
completely. Instead, we need to come up with clear instructions on how
to upgrade without forcing people to audit their applications. Your
letter is a good first step. It's very much contradictory to th
Sebastian Bergmann wrote:
Zeev Suraski schrieb:
That was a stupid response, Jani.
Maybe we should collect and publish (with a PEPr-like system, for
instance) the suggestions that came up in this way-too-long thread and
let the php-general readers comment/vote on them.
Having the suggest
Hi,
I am using custom streams for the LOB support in PEAR::MDB2.
It seems that things work nicely on PHP 4.4 and PHP 5.1.0RC1. However
using todays windows 5.0.x binarys from snaps.php.net still give me
errors. Atleast there is still bug that leads to the stream_eof() return
being flipped (fal
Jani Taskinen wrote:
Not critical enough to try and find the fix.
Just use 5.1. As far as I'm concerned, 5.0 is dead along with 4.4 :)
Sure.
But why even bother with 5.0.5 .. or more specifically whats the purpose
of 5.0.5? I presume there are other bugs which will follow the same fat
Zeev Suraski wrote:
At 01:23 23/08/2005, Rasmus Lerdorf wrote:
Greg Beaver wrote:
> I just synced php-src/pear (PHP_5_0/PHP_5_1/PHP_4_4) with pear-core
> (PEAR_1_3). May god bring the day when this is no longer necessary
> sooner rather than later.
We'll get there. But we can't kill the 5.0
DvDmanDT wrote:
Hello everyone.. I woke up this morning with an idea, that I think would be
useful: a BC break list. I think that could benefit alot of people, and I
don't think it would be that much work to implent (I can do the scripting if
noone else cares to). I would need some input from y
DvDmanDT wrote:
Hello everyone.. I woke up this morning with an idea, that I think would be
useful: a BC break list. I think that could benefit alot of people, and I
don't think it would be that much work to implent (I can do the scripting if
noone else cares to). I would need some input from y
Joseph Crawford wrote:
I would like to see Multiple Inheritance implemented in a future version. I
am not sure what obstacles got in the way (if any) for not implementing that
in PHP 5 but i would defenately like to see that in PHP 6 or 7
IIRC, it was shot down. Use overloading and interfaces
Derick Rethans wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
1) seems to be an issue in doxygen and phpDocumentor
2) this seems solveable with a non public set of arrays containing
information about the prop
Oliver Grätz wrote:
This is a valid argument. PHP has always been the BORG language that
assimilates every positive aspect of other languages. Nowadays PHP users
can use complex class hierarchies, interfaces, expections ans a lot
more. But they may still use simple functions and use "global" for
Zeev Suraski wrote:
Umm, that's not exactly an option, not before 5.1 proves itself stable
(as far as architecture goes - the changes between 5.0 and 5.1 are as
substantial as the changes between 4.x and 5.0 were). PHP 5.0 is
deployed on roughly 5% of the userbase, including most of the new u
Stanislav Malyshev wrote:
DR>>If it returns false, the engine can throw an error on the line where
DR>>it was used, not inside the __get() method itself, as that doesn't
DR>>help debugging your code (as you don't usually know where it was
DR>>called from).
That I understand. However, you sti
Torsten Roehr wrote:
Maintaining code for PEAR::HTTP_Session as lead developer.
See: http://pear.php.net/user/troehr
The request is valid as can be seen on the following page:
http://pear.php.net/package/HTTP_Session/
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To
Sebastian Bergmann wrote:
Marcus Boerger schrieb:
honestly why do you want to prefix iterators? and secondly i'd be
just plain stupid to prefix the exception classes.
Bugger, I forgot that those two (iterators and exceptions) are part of
SPL for a second. They're so essential, IMHO, that I
Hi,
Here is a list of ideas I have to improve the release management
process. Once I will get back to Berlin tomorrow I will try to put some
of these into action.
1) Select a list of popular PHP applications (in total about 3-4 ..
things like Gallery, MediaWiki ..) and make sure they test RC
Ron Korving wrote:
1) Does unsetting $stmt trigger a closeCursor() as well? I assume so, but
the article doesn't mention it. It only talks about the importance of
calling that method.
yes this is done automatically ..
2) Could it be a good idea (performance wise) and possible in the first
pl
Lukas Smith wrote:
3) Wouldn't it be nice if you could do a $stmt->execute("foo", "bar");
(numeric parameters) instead of $stmt->execute(array("foo", "bar")); ?
I think this would severely hurt the extensibility of the API not on
So it seems to me we have 2 issues here:
1) timing
2) code duplication or not
It seems evident that the old magic never worked reliably exactly for
those people that are now seemingly adversly affected by the current
changes. Its just that what worked by chance may not work anymore and
vice v
Andreas Korthaus wrote:
People needing the new features (like me) would be happy if old
date/time behave the same as before 5.1, and if there is a new OO
interface for the new extension.
I dont see a pressing need for an OO API and I also dont think that PHP
internal API's should one by one
Edin Kadribasic wrote:
I dont see a pressing need for an OO API and I also dont think that PHP
internal API's should one by one be moved over to an OO interface either.
I think the point is to have date() working as it was, and have a *new*
extension for all the fancy stuff (including OO).
Stanislav Malyshev wrote:
LS>>It seems evident that the old magic never worked reliably exactly for those
LS>>people that are now seemingly adversly affected by the current changes. Its
It doesn't seem evident to me. For me it worked flawlessly and did
exactly what I wanted it to do - show curr
Stanislav Malyshev wrote:
I don't see any need to force users into anything they don't need just
because you seem to like the new code. Users don't care how much you love
the code, they care if it works - and now it does not, at least not for
the atsk of printing current date with date() call.
Pierre wrote:
And the question is more about delaying 5.1.0 or not. I doubt it is a
possible to delay again 5.1.0. There is thousands of critical fixes in
there, and many people are waiting for them since months. Sadly.
I agree ... PHP 5.1.0 should not be delayed any longer. There are enough
Stanislav Malyshev wrote:
LS>>Now the new code does cause problems for some (certainly not a majority of
LS>>people) and this needs to be taken into account. However if these people do
I wonder how do you know it's not a majority? Almost nobody is using 5.1
in production now, but once it's out
Marcus Boerger wrote:
You should face reality that php 5 is a bit different than php 4.
Many of the things changed in php 5 were made to support exactly pear
development but pear is absolutley ignoring it. Why can't at least the
things that shall be shipped in 5.1 fashion - especially since you'
Derick Rethans wrote:
We are not ignoring it. However the single most useful feature from PEAR POV
was dropped from PHP5: namespaces.
That's lame, this has nothing to do with E_STRICT warnings or other
dubious code.
How is it dubious to support PHP4 and PHP5 with the same code base?
There
Bart van Bragt wrote:
There are some whacky things in PHP4 and PHP5 that need to be fixed and
to fix that BC sometimes breaks. No problem with that. The problem is
that you're breaking BC again while almost no-one has switched to PHP5
yet because of the BC breaks between 4.x and 5.0. Breaking
Bart van Bragt wrote:
Derick Rethans wrote:
But who says your code should run on the new version? You don't *have*
to upgrade per se. It merely allows newly developed projects to run on
a cleaner version of PHP, which would undoubtfully also be faster
(because we wouldn't have any BC ballast)
Bart van Bragt wrote:
The 'communicate more clearly' part is what this (IMO) all boils down
to. As I said, I understand that BC breaks are sometimes needed, no
problem with that. The problem lies in the fact that we now all of the
I made a suggestion in regards to this a few days ago on this
Rasmus Lerdorf wrote:
People seem to have latched onto this $ref =& $this issue for some
reason. Is this really a place where you want to use up some of our BC
breaking karma points? I really don't see this particular point as
Atleast for me it was more a general rant ..
regards,
Lukas
--
Ilia Alshanetsky wrote:
Zeev Suraski wrote:
Ok, maybe I missed it in the lengthy thread.
I suspect that is very much the case. Derick has been working quite
diligently over the last little while at getting the BC problems solved
and as far as I know all but a few Win32 issues have been reso
Derick Rethans wrote:
You don't need this, as there is:
http://no.php.net/date_default_timezone_set
cool ..
now we only need to get the list of possible legal TZ's documented (or
linked from the docs) .. atleast I do not see it yet (but it might be
just me not seeing it at 5 am after coming
Hi,
some of you may be aware of the wiki I set up to manage/document the
todo lists and parts of the release management for PHP releases. In
response to this Wez created a set of patches to enable developers to
set milestones (aka PHP versions) for bug reports. While I do not think
this repla
Jani Taskinen wrote:
Unnecessary, you can tell the user within the closing comment
in which branches you fixed the bug. Don't forget that it can
CHANGE later, someone reverts the fix or the fix wasn't needed
or.. you get the picture.
Does it hurt though?
It makes it alot easie
14 Oct 2005, PHP 5.1 Release Candidate 2
- Changed SQLite extension to be a shared module in Windows
distribution. (Edin)
Whats the reason for this?
To allow people to switch between sqlite2 and sqlite3?
Shouldnt the extension then be enabled by default in the php.ini-dist
and php.ini-recomme
Wez Furlong wrote:
It's a linkage/dependency problem; ext/sqlite holds the sqlite2 PDO
driver, and PDO is a shared extension.
Ok .. can then someone enable the php_sqlite.dll in our sample php.ini's
then? I dont have the karma ..
thx
regards,
Lukas
--
PHP Internals - PHP Runtime Developmen
Antony Dovgal wrote:
On 16.10.2005 19:31, Lukas Smith wrote:
Wez Furlong wrote:
It's a linkage/dependency problem; ext/sqlite holds the sqlite2 PDO
driver, and PDO is a shared extension.
Ok .. can then someone enable the php_sqlite.dll in our sample
php.ini's then? I dont have
Wez Furlong wrote:
That's one of the reasons why we don't do it.
I once proposed that every driver should atleast be able to generate a
DSN from an array through an optional function. However since I never
implemented and nobody else stepped out it never materialized.
regards,
Lukas
--
PHP
Hi,
just as an FYI:
http://oss.backendmedia.com/PhP51
if anyone could report any important issues they are still aware please
let me (and of course more importantly Ilia) know.
i would also appreciate if anyone could report any of the todo items
solved. for example, from all i have read on t
Ron Korving wrote:
I was wondering; we've seen quite a few PHP6 wishlists passing by here. Is
there (and if not: should there be) a centralized spot where changes and new
features are logged, perhaps with a status saying whether somebody (and who)
is working on this, or if it's still being cons
Cesare D'Amico wrote:
Alle 12:25, lunedì 14 novembre 2005, Cesare D'Amico ha scritto:
a default way to hold objects/variables in memory (on ANY operating
system) between two HTTP requests
Hey, I didn't mean sessions :)
I meant something like creating a complex object and holding it in
memo
Rasmus Lerdorf wrote:
Wez Furlong wrote:
I can't think of any case where you'd want to error out when given
'100 ' if it would accept '100' quite happily.
I'd lean towards a single cast semantic for this, and remove that
strict checking flag from zend_parse_parameters(); lazy dynamic type
hand
Steph Fox wrote:
Anything else missing?
I have listed a few items here. I havent checked which ones you covered
in your test:
http://oss.backendmedia.com/PhP51
But from a quick glance you may have missed points 4-6
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To
Ilia Alshanetsky wrote:
Todd Ruth wrote:
The hope
in my original email is that if php is clever enough to give
me a message, it might be clever enough to just make the change
too.
A scripting language is not a spell checker, you can forget about it
auto-correcting your code. The E_STRICT/E_N
Rowan Lewis wrote:
Well, that just sucks. I can only dream...
Ian:
How was this mail more useful/polite/pointful than Andrei's reply?
Now remember that PHP developers get stuff like this all the time, yet
users most of the time just come here to complain now and then. Its like
working at Wal
Marcus Boerger wrote:
obviously one problem is that PEAR does ignore coding standards. Classes
should be prefixed in both pear and core. And neither Date nor File is in
any way prefixed. In th end all we see here is that we want namespaces asap.
Err, how are we supposed to prefix PEAR::Date?
Marcus Boerger wrote:
So in conclusion its needlessly messy. I am sure other projects than
PEAR also have a Date class. Maybe we need to teach our users (including
PEAR) that they should simply stick to prefixing everything with 3-4
letter combinations (maybe even offer a central place to regi
Rasmus Lerdorf wrote:
I think that is a pretty good idea actually. It's the uid matching that
is the problem. Having a way to restrict which commands the exec
functions can execute is sort of a separate thing that is snapped onto
the end of safe_mode.
We're a little distracted by 5.1, but
Sara Golemon wrote:
We can either roll back:
http://cvs.php.net/diff.php/php-src/ext/date/php_date.c?r1=1.43.2.20&r2=1.43.2.21&ty=u
or perhaps a better option is to rename that internal class for now
I vote for #ifdefing it out of PHP5, and renaming PECL::Date to iDate or
Datei for PHP6 (i
Rasmus Lerdorf wrote:
Are you saying this works?
namespace ns {
function foo() { }
}
function foo() {}
echo true ? ns:foo():foo();
even worse if you use a class constant inside the ternary ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
Wez Furlong wrote:
Agreed, the PECL bundle is still very useful to maintain for each release.
(as is the debug pack, so that debugging crashes becomes a possibility
for releases).
Shouldnt we then fast track the binary support in the PEAR installer?
It should be enough to commit all your code,
Ilia Alshanetsky wrote:
The attached patch is a possible solution to the date *crisis*, it
renames the class to PhpDate to avoid any namespace conflicts with pear
or custom user classes called date.
I do not think it makes sense for PHP to start prefixing internal
classes with PHP. We just nee
Stanislav Malyshev wrote:
MB>>cool argument: as long as there are worse features we can add anything?
:-))
No, as long as the feature has high abuse potential (hint: goto does) it
is better not to add it. Of course, it's not always possible, some
features are vital even if dangerous. But got
Oliver Grätz wrote:
one absolutely needs to use namespaces inside the ternary. As such cases
will be pretty rare, this is no big drawback. The good thing: no
whitespace magic is needed!
so you replace the need for whitespace magic with the need for
parentheses? you do notice you are running i
Stanislav Malyshev wrote:
LS>>a scope limited goto will never be close as dangerous for spagetti
LS>>code as exceptions already are because they are not scope limited.
Exceptions are structured way of handling code flow - you can not get to
random points of code with exception, you can get eit
1 - 100 of 318 matches
Mail list logo
