So, what, exactly, is the fuss all about?
Richard, the problem with a CLA (moral quibbles apart) is it prevents any of
the core contributors doing anything with the code. As in:
+# PDO Specs. CLA required to commit
+unavail||pdo-specs
That's what 'unavail' means.
Surely all this us/them,
We do have peer-review after all.
Not on CLA'd code we don't.
Steph the CLA seems to just relate to the docbook xml specifications
for PDO.
Someone told you that, or have you developed psychic powers?
The same applies, regardless. If a commit to that module breaks the PHP
manual build,
Stas - we don't even know what they're planning to put into CVS. Just
And waiting couple of days for the explanation is of course not an option.
But opening up a module in the php.net CVS repository that php.net
contributors are excluded from without discussion is?
- Steph
--
PHP
Hi Johannes,
On a side-note: It's not only about peer review - without signing the
CLA one might still read the code and send reports to the maintainers.
I was responding to Richard when I wrote that. He was operating under the
assumption that php.net have control over what goes into a CLA'd
such switches only add more complexity, confusion for users and
addtional trouble to distributors.
FWIW, amen to that.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
It has nothing to do with little peon.
Be fair Stas, Brian already apologized for the way that post came across.
You argue that we need some language-level change to improve performance
(and it is the only reason to add it). It is suspected that this language
change has very high
Couldn't there be some way to mark a 'bundle' file and use that mark to
discriminate between where multiple namespaces are or are not allowed in
zend_compile.c? That would eliminate the potential for abuse, no?
Not really. People would start bundling files left and right, just
because
The need to pack a program all into a single source file for performance
reasons would seem to indicate that the way PHP compiles/interprets could
be improved. Wouldn't it be better to improve this area than add language
features to deal with the issue?
How do you improve the performance of a
That depends on how many 'bundle files' are allowed. I hate to say it, but
if this were an INI directive rather than a keyword it would be possible
to limit bundling to a single file, or to any given number.
Take that back, it wouldn't work... I was thinking of single applications
rather than
I strongly suspect performance difference in bundles does not follow
from syscalls. On include() PHP does a lot more than just issue a couple
of syscalls.
So Michael's right and it needs some proper investigation.
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
I'm a firm believer that it's better to throw more CPU power at a
performance problem than to make code less maintainable. Just buy a faster
server.
That hardly applies to library developers, though. They don't have control
over their users' CPU power...
- Steph
--
PHP Internals - PHP
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work with test::xmlreader, which of
course you can define. But in global
I can't. I can only hope they would do it right, I can't force them to do
it right :)
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
Maybe one of the OO
I guess what I'm really asking is, 'is there any point in allowing
import/use to be used in the global space?' I'm tired and etc, but I just
can't visualize where it would be useful.
And now I've finished reading old South Park episodes...
OK, it's sinking in now. Because global import/use is
Hi Larry,
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
I'd missed that in the ebb and flow. I guess the bug in my copy was fixed
then, good. It still doesn't make sense to have global import though...?
(I'm probably going to kick myself sooo hard for this in the
Hi Nate,
Only if you insist on *not* using the namespaces to solve collision
problems. For the 1001th time - you can not expect to put all names into
global space and have the language by some magic to sort it out and go
both ways. One name can mean only one thing, namespaces or not.
Namespaces
Hi Matthias,
Let alone __php__. If you just put all of your code into namespace Mylib,
you're not safe because according to the name resolution rules, internal
classes come after imported ones but before trying to find classes in the
current namespace.
I'd missed that :-( and from what I
Hi Greg,
1) recommend all global non-namespaced code that wishes to import
namespaced code via use Namespace::Classname add a namespace
__php__; at the top of the file, and that the __php__ namespace be
reserved for use by end-user applications.
That answers my main concern, but I'd make it
stripper...
- Steph
- Original Message -
From: Steph Fox [EMAIL PROTECTED]
To: Raghubansh Kumar [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, December 09, 2007 3:31 PM
Subject: Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/array
array_unique_basic.phpt array_unique_error.phpt
Hi Stas,
I just spent most of two evenings looking at this one - so much for an easy
fix. Read on...
the code is
if (ZEND_NUM_ARGS() = 3 Z_TYPE_P(length_param) != IS_NULL) {
length = Z_LVAL_P(length_param);
} else {
length = num_in;
}
and afaik should be
I think in fact it should just
all of a sudden the fourth parameter, preserve_keys, doesn't throw
zend_parse_parameter() warnings any more, regardless of the type you give
it. (You tell me...)
... because I re-used the same variable in the test script after it had been
converted to long.
OK, so that mystery's solved. But
If Z_TYPE_P(length_param) is 0, it's not NULL because it has something in
it.
Bleh... but you know what I mean :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The manual kind of skirts around it: If length is given and is
positive, then the sequence will have that many elements in it. If length
is given and is negative then the sequence will stop that many elements
from the end of the array. If it is omitted, then the sequence will have
everything
if (ZEND_NUM_ARGS() = 3 Z_TYPE_P(length_param) != IS_NULL) {
+convert_to_long(length_param);
Isn't convert_to_long non-separating one? I think the variable supposed to
be separated before conversion, so convert_to_long_ex (and zval **) would
be in place.
Hm you're probably
It builds without complaint and works as expected - what am I missing?
IS_NULL is variable type. length is variable value.
So it's better to check for == 0? What's the difference? Is an IS_NULL check
slower?
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
Both are now on http://bugs.php.net/bug.php?id=43541. Ignore the first of
the three, it breaks when the length param isn't passed.
I'm going offline before I say anything else stupid :)
- Steph
- Original Message -
From: Steph Fox [EMAIL PROTECTED]
To: Stanislav Malyshev [EMAIL
C'mon guys, you're just not trying. Some of us stand to lose bets here...
On Dec 13, 2007 10:19 AM, Sean Coates [EMAIL PROTECTED] wrote:
2.) Probably a better idea, just click that DELETE button on any
emails you don't feel like reading or responding to. I find that, in
a case study
Hi all,
Having spent a few hours tussling with the load-order bogey, I found what I
think is a bit of a gap in the win32 build process.
There are no configure warnings at all when there's a missing extension
dependency... only a bailout if you try to build a dependency as shared for
a
Could someone please commit this? I just hit the same issue again.
Thanks,
- Steph
- Original Message -
From: Steph Fox [EMAIL PROTECTED]
To: internals internals@lists.php.net
Sent: Friday, December 14, 2007 9:40 AM
Subject: [PHP-DEV] Extension dependencies in win32 build
Hi all
-1
(OK so I'm late...)
- Original Message -
From: Johannes Schlüter [EMAIL PROTECTED]
To: PHP Internals List internals@lists.php.net
Sent: Friday, January 11, 2008 3:47 PM
Subject: [PHP-DEV] SUMMARY: Array syntax
Hi,
I did a short count of the votes about the Array Syntax shortcut
It is better to have input from people with a wide range of experience
levels, it results in a fairer vote that actually represents the
population, rather than putting PHP under the control of a select few.
No, it is not. This has nothing to do with fairness, as we are not
enacting laws,
This broke the TSRM build, trivial patch attached.
- Steph
- Original Message -
From: Derick Rethans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, January 13, 2008 3:16 PM
Subject: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/date php_date.c
php_date.h
Hi Andi,
As we have discussed in the past the migration path may be extremely hard
moving from PHP 5 to PHP 6. Therefore the community has to come together
and really invest in the migration path more than we have in the past
(like we did from version 2 to 3). This means that during the
I think the idea was no php.ini switch, but the question what foo
should produce - IS_UNICODE or IS_STRING is still open for consideration.
foo alone should produce IS_STRING. The real question IMHO is how far back
do you backport tolerance for a unicode cast.
- Steph
--
PHP Internals -
Blimey. I agree with Rasmus. That's twice now!
I think PHP 6 should be an interim period with support for both scenarios,
but with the default being bog-standard as-we-know-it IS_STRING and anything
IS_UNICODE needing to be marked.
Perhaps PHP 7 can drop the IS_STRING stuff and have it all
Hey Andrei,
You can't just say that without giving full details.
We've seen all your 'this will cope with Russian, Hebrew, Greek, Japanese
and Icelandic' demos. We haven't seen what happens to English, French or
German - ever.
So what happens if I pass in Hello World, in English, and it's
Right, and that's something that does NOT appear in any notes anywhere.
- Original Message -
From: Andrei Zmievski [EMAIL PROTECTED]
To: Steph Fox [EMAIL PROTECTED]
Cc: Rasmus Lerdorf [EMAIL PROTECTED]; Chris Stockton
[EMAIL PROTECTED]; php-dev internals@lists.php.net
Sent: Thursday
for user education way before it even becomes available, _or_
you hold it all back and force 'non-standard' (sorry rest of the world)
languages to use markers.
- Steph
- Original Message -
From: Andrei Zmievski [EMAIL PROTECTED]
To: Steph Fox [EMAIL PROTECTED]
Cc: Rasmus Lerdorf [EMAIL
[EMAIL PROTECTED]
To: Steph Fox [EMAIL PROTECTED]
Cc: Rasmus Lerdorf [EMAIL PROTECTED]; Chris Stockton
[EMAIL PROTECTED]; php-dev internals@lists.php.net
Sent: Thursday, January 24, 2008 1:33 AM
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
Hey, I can't do
The question here isn't so much where we are going, but exactly how we
will get there and how long that might take.
Absolutely.
- Steph (who has taken several queries over this today thank you)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi Marcus,
so you mean we do not have to confuse our uses by solution 2a becasue we
only have the minimum subset of zip in phar that ohar actually needs?
Yep. But Greg can explain better.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I think it is a good thing to require ext/phar even for the read
operations. It certainly allows a shit load of optimization and tricks
that will never be possible otherwise. But Greg or Marcus will give us
a better answer :)
? It's a 7kb add-in stub to make it open-access.
- Steph
--
PHP
phar's zip support. The tests simply need to be modified to create the
zips using pecl/phar and copy the filename to one phar doesn't already
know about, and the failures will go away.
I thought you wanted 'pure' zips for the tests - that told me!
So how do I create a zip with ext/phar then,
Hi Marcus,
1. include phar in core
2.a. add ext/zip compatible functions and replace ext/zip
2.b. change ext/zip to use zip lib of pahr and add stream support
3. drop ability to disable spl
I have no preference between 2a or 2b. Though technically I guess that 2a
is probably much faster to
Hi Pierre,
Exactly and I'm rather surprised to see this post given the recent
efforts to export the Zip symbols to allow any extension to share the
zip features.
I think until the zip features were shared the library's limitations hadn't
been too obvious.
Most of the discussions have been
The win32 snapshot builds have been done since Jan 20/21, so maybe
there is more than 1 library to fix
No, the errors that caused the original failure were fixed within a day or
two. Also the snaps libxml is up to date, it's just the zip.zip one that
isn't. Machine probably needs a kick.
Be fair, this is an open list. Anyone can join it, and it keeps the noise
levels down on [EMAIL PROTECTED] Please? ;)
http://news.php.net/php.pdo
- Steph
- Original Message -
From: Marcus Boerger [EMAIL PROTECTED]
To: Wez Furlong [EMAIL PROTECTED]
Cc: Steph Fox [EMAIL PROTECTED
If we're going the PECL refurbishment route, can we have some way of
marking non-standard (as in CLA'd or differently-licensed) extensions to
make contributors' lives easier and future discussions of this nature
moot? Possibly even a separate CVS module that hooks into the PECL
infrastructure?
all we need is to extend the PECL database with a license type field and
a
CLA flag. Nothing else is required at that end. But we should still move
as
much from php-src/ext to pecl as we can.
Hm but then when you checked out you'd have CLA'd stuff as well as normal
PECL stuff, as now. Don't
Hi all,
Just so's Marcus and I don't have to keep cross-posting here... The problems
of PECL vs core extensions are many, and exist with or without the PDO/CLA
debate.
Marcus (among others) says he wants to get as many extensions as possible
out of the core and into PECL. I agree fully with
Personally I do a full pecl checkout alongside my php-src checkout, every
time. The problems with that tend to come out during the build.
- Original Message -
From: Marcus Boerger [EMAIL PROTECTED]
To: Steph Fox [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; internals internals
Hi Marcus,
what I want is php-src as minimum you can depend on. And php-default as
release managers playground. The RM can then say what he thinks is mature
enough to make it into a release.
What _I_ want is a PHP core that is really core. By that I mean things like:
date, spl, pcre, zlib,
Hi Marcus,
Anyway my idea is to start everything in PECL and
to to move everything out that can be moved out. And that includes all
MySQL
extensions as well as SQLite. Only this way people will use the PELC
infrastructure. Otherwise we would just reduce functionality of PHP. And
btw
nearly
Hi Lukas,
Correct me if I am wrong or if I am missing something, but currently
things work more or less like this. I think its important that we get
an understanding of how things are right now and what the issues are,
before we go off and solve them (maybe with the above mentioned
I see no point to discuss solutions for some unknown entities willing
to contribute when they do not consider to introduce themselves. When
they don't explain clearly why we should do the move and what will be
the actual gains for us (read: for us not for them). Until a step in
this/our
Hi Lukas,
I am not sure if I misunderstood some other persons proposal, but at
least my proposal was that the final thing we ship as version xyz of PHP
would include a set of PECL extensions along with core that we deem as
necessary for the bulk of our users solving the web problem.
Moin Lukas,
Now, PECL has a couple of CLA'd modules already. I don't like them being
there, and you have stated your own opinion loud and clear. I think we
should be looking for some way to separate out CLA'd PECL modules to
elsewhere but leave the PECL structure in place for those
Ah sorry - I'm not good with multi-tasking, mixed up two ongoing
conversations here.
Well thanks to a separate PEAR channel, we have all the infrastructure
easily setup to have a different place for users to pick up the code. Or
are you more concerned about the CVS, than the distribution of
Hi Lukas,
Well Greg has long been talking about adding the ability to bundle
binaries in PECL packages. Not sure if this is included in the next
generation installer Pyrus. Again, I personally do not think that the
distribution we ship would be so radically different, so this would not
be
Hi, person with no name...
I'd like to know where PHP finally sets the php.ini-values in it's
sourcecode, e.g. max_execution_time, open_basedir, etc...
What I need is to set several static values which must not be editable using
php.ini, httpd.conf, .htaccess, ini_set, or whatever
Hi Marcus,
The rest of the discussion is once again how easy it is to get more than
the
default distribution onto hosters machines. But a) I couldn't care less,
That's... a bit remiss of you :)
b)
it is absolutely a discussion on its own and can addressed somewhere and
somewhen else.
No,
With the risk to repeat myself (and some other having said the same),
the biggest advantage PHP has so far is that you get everything you
may need with the default install.
This hasn't been true of the Windows distribution for the last few years. I
think it should be - I think the default
Good point but I admit that I never understood why our windows
releases have been so different from the source releases, from a
configuration point of view. Many default extensions are (were) not
enabled. But that's not a big problem and can be easily fixed no? :)
It's not a big problem so long
Assuming the aim is to have everything _not_ enabled by default move to
PECL, that's quite a big deal.
That's another topic and I tend to disagree (more later on that).
I'll wait... but I suspect all the arguments against that are based on PECL
as it currently is, with all its distribution
Hi Derick,
I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's annoying enough that
Hi,
Don't know which mail client you're using but it hates mine... no , so I'm
resorting to separators.
==
why do you say old version?
==
Because I've been working with 5.3.0-dev since the day the branch split, and
I have a hard time remembering what was or
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
That's rubbish Richard - in some ways you're the most important person on
the list. Odd, eh?
I think
Hi Alexander,
Stupid question maybe, but why can't you use your given name for this?
Caveat: please don't let this email stand in the way of your giving your
gift.
- Steph
- Original Message -
From: Solar Designer [EMAIL PROTECTED]
To: Dmitry Stogov [EMAIL PROTECTED]
Cc: Stanislav
But this has been discussed to death. Please say +1/-1/0 =)
Pierre: Sorry, I didn't want to add to the noise, but for the sake of
completeness I'll give you my 0.
- Steph
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi both,
I totally agree, most hosts just install what comes as default with a
distribution, they don't care or even bother with PECL in 99% of cases in
my
experience.
Well - that can't be entirely true or there'd be next to no MySQL support
out there!
I just think we make it needlessly
Hi Pierre,
The main reason (from my experiences) for the ISP is lazynes. They
don't care about what the users may need or not but simply run
configure, make make install, or use the xyz distribtutions default
package to run common applications like phpmyadmin or wordpress.
That's a heck of an
Hi Marco,
I think one of the reasons hosts don't like / use PECL is trust, they
trust
what comes with the PHP core packages and consider anything else a
security
risk. Maybe a combination of better distribution, package details,
stability
(beta / alpha) etc and maybe something that deals
By the way:
http://www.nexen.net/articles/dossier/18038-base_configuration_for_php_5.2.5.php
Thanks for that, Pierre. But I think those stats add to the argument for
making PECL easier to deal with, rather than diminishing it.
- Steph
--
Pierre
http://blog.thepimp.net |
I'm going to rock the boat again I guess...
Suggestion to enhance the suggestion: return false + emit E_STRICT
message (but I am also fine with pure return false if people don't like
this suggestion).
Sounds reasonable too. It would be nice to add a deprecate notice in
5.3.x as well.
Hi Marcus,
It's not a real problem to break the win32 build because it's a very simple
fix, but it'd still be kinda nice if the PHP_5_3 checkout would just build
without manual assistance. Snaps would work an' everything.
Please fix last_scope declaration, mini-patch attached.
- Steph
Tell us the names of these entities, companies or persons, who are
going to contribute and what are actually their requirements. What
will they bring (saying expertise is not something I can buy)? I
don't understand what is so hard to understand that it is a minimum to
get before we can even
Hi Chris,
In interests of clarity for all, can you explain what you anticipate
will change for PECL with Phar/Pyrus for Windows and non-Windows?
From my PoV as a Windows user, the primary case for optimisim is based on
the fact that local PEAR installs recently started working properly on
I'm with Dmitry - but syntax aside, the only way this becomes even halfway
important is if the whole PECL scenario is sorted out in a way that makes
good sense to the end users.
Back to square one. Sorry guys but sooner or later this has to be dealt
with. We need to be sure of what a PHP
Hi Marcus,
so here's my take on the matters. For 5.4 we collect ideas and implement
them. So that 5.4 comes out with mostly PECL. I guess we can collect
action
items on Lukas' wiki.
Greg tells me he's been working so hard on ext/phar lately that Pyrus is
still pre-alpha - it's not going
Hi Chris,
I'd like to see pecl4win merged into pecl.php.net (adding to Steph's
idea of releasing binaries on pecl.php.net), and the Windows binaries
being built from their correct branch (whatever happened to this
project - it seemed so close?)
What happened to this idea is there's no
I hate to piss on anybody's bonfire, but...
I'm not, never was, an OO fan. OO is one of those things I'm more and more
forced to deal with... even in C coding (wtf is that all about?). It's OK, I
won't create this OO stuff but I can deal with it when I see it... nowadays.
But I also remember
Hi Marcus,
we changed the behavior as much back as we need be. Fact is that this has
been an oversight. It has been a bug we just fixed. As an eagreement we
decided not to mark all of these as fatal.
Why are _any_ of them fatal?
- Steph
--
PHP Internals - PHP Runtime Development Mailing
Is it clearer why I think PHP 5.x and 6 are different and why I think ICU
dependency in the 5.3 core might be a problem?
FWIW... I also think that bringing in ICU in 5.3 so late in the cycle
- or actually at all in 5.3 - is not such a bright idea.
'so late in the cycle'? We haven't had a beta
No one was considering any such move. Having pecl/intl shipped per default
as symlinked into ext would be as much optional as --enable-zend-multibyte
or --enable-mbstring are right now. This will be more like brining in zip
to 5.2. However it is completely off-topic as it is just one possible
Hi Tony,
Well, lets make it convenient then.
Including everything into the core is not a solution.
You seem to have missed an entire thread on the subject, along with the
conclusion that the mechanisms for really doing a good job on this can't
sanely be in place before 5.3.0 is released.
The very same could be said about phar.
It's going through a final wave of intensive development that *adds* to
existing features; the core functionality's solid, and has been for some
time. Given the end of April 'freeze', we're at least 2 months away from a
5.3 release. Assuming Greg's
throw a warning is in the debug build.
Can you please fix it?
Thanks,
- Steph
ps Sorry for top-posting, the alternative didn't bear thinking about.
Oh. I meant MSVC6-SP5.
Could you please verify the version with cl command.
Dmitry.
Steph Fox wrote:
But not MSVC6?
Why would I get a compiler
Thanks Dmitry!
- Original Message -
From: Dmitry Stogov [EMAIL PROTECTED]
To: Steph Fox [EMAIL PROTECTED]
Cc: internals internals@lists.php.net
Sent: Wednesday, March 12, 2008 8:54 AM
Subject: [PHP-DEV] RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /
zend_API.c
Interesting. I did a clean checkout when Stas' message came through and
can't reproduce the problem here.
Stas, is yours a cygwin-reliant exe?
- Steph
It should be fixed now.
Scott
Stanislav Malyshev wrote:
Hi!
Windows build is broken right now. When trying to build, I get:
Secondly, my $0.02
1. If re2c IS found, try to rebuild the .c versions
2. If re2C is NOT found, use the .c versions in cvs
- this allows not making re2c required but letting people who do have
it get properly generated files every time
Sounds like a plan. (And to pierre too.)
- Steph
--
PHP
Interesting. I did a clean checkout when Stas' message came through and
can't reproduce the problem here.
Stas, is yours a cygwin-reliant exe?
Erm, not sure what you mean here.
I meant 'does it rely on cygwin1.dll or is it native'?
I downloaded re2c.exe from sourceforge
release, did
Hi Stas,
I meant 'does it rely on cygwin1.dll or is it native'?
No idea, whatever the person who put it on sourceforge built.
If people are distributing binaries that rely on the cygwin runtime they
usually say something about it somewhere, so I'll assume not in in this
case. I just
Nevermind, I fixed it.
yes... but given that mine worked in the first place, the question is
whether your (and Scott's) fixes will work here, which means I now need to
check out 5_3 and try again. Sorry, it's going to have to be after I
finish work for the day, taken up too much time
Actually, it should behave like with flex: only rebuild when it is
necessary (due to the file being touched).
This _is_ behaving like flex under doze!
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Greg,
Please look at the stream wrappers in include_path patch I posted last
week.
I went to try this, but the patch doesn't apply to 5_3 any more since the
re2c change. Could you post an updated version please?
Thanks,
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
Elizabeth M Smith wrote:
Wow, noisy...
I've been in the situation where I use php for templating and the short
syntax is much nicer on the eyes. The ability to flick the switch for
short tags would be nice.
However, like Steph, I've also been bitten by having a simple xml
declaration in a
Hi Andrés/Rob,
as usual my are playing up so I'll use ==
=
I'm new to the internals, but I've been reading you for months... now, let
me
ask,
Are there any security issues with short tags?
Is it really harder for the interpreter to have them enabled?
Is the short tags
Hi Stas,
you can already do all you want. We do not have to make it more complex
at all. Ini setting short_open_tags is defined as PHP_INI_PER_DIR, so all
you guys have to do is provide the right configuration, that's all. And
if
Ok, here we go again: this setting is needed to enable
Hi Lars, oh wow no again...
==
as we introduce NOWDOC in 5.3 it would be logical to allow a double
quoted syntax sister of NOWDOC which acts as HEREDOC (same as for $var =
$var vs $var = '$var'). Currently we have the following options:
$var = Hello world;
$str = LABEL
$var
Since multiple namespaces are allowed in the same file we have no
choice but to use this syntax.
Yes we have choice. Leave it as it is and stop raising this topic every
two weeks.
My hero :)
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
1 - 100 of 692 matches
Mail list logo
