On Thu, 17 Nov 2005, Andi Gutmans wrote:
I'm hoping that in future we can provide better tools for upgrading in between
versions. Both from an auto-conversion perspective and just scanning the code
statically and printing out warnings on what code to check. Coupled with
better upgrading docs
On Thu, 17 Nov 2005, Robert Cummings wrote:
On Thu, 2005-11-17 at 16:42, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
Very few people converted to using {} so the argument about reading old
Ugh, so those of us that did are going
On Fri, 18 Nov 2005, Andreas Korthaus wrote:
If you go and grep through all the public code out there, pretty much none
of it uses {} for character offsets.
That's the problem - also grep does not know if [] is used for arrays or
stings. That's the same for programmers, it's often not
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
On Fri, 2005-11-18 at 03:12, Derick Rethans wrote:
On Thu, 17 Nov 2005, Robert Cummings wrote:
On Thu, 2005-11-17 at 16:42, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
Very few people converted to using {} so the argument
Roman Ivanov wrote:
Ilia Alshanetsky wrote:
You cannot give it
an md5 and have it generate you a string with the same md5 hash, so md5
is still relatively safe.
http://www.google.com/search?q=md5+hash+lookupstart=0start=0ie=utf-8oe=utf-8client=firefox-arls=org.mozilla:en-US:official
I'd
Derick Rethans wrote:
That's the problem - also grep does not know if [] is used for arrays or
stings. That's the same for programmers, it's often not easy to conclude from
context - that's my point.
grep won't, but php -l will.
That's true. But what about reducing complexity?
Don't you
On Fri, 18 Nov 2005, Andreas Korthaus wrote:
Derick Rethans wrote:
That's the problem - also grep does not know if [] is used for arrays or
stings. That's the same for programmers, it's often not easy to conclude
from
context - that's my point.
grep won't, but php -l will.
Hello!
I packed PHP 4.4.2RC1 today, which you can find here:
http://downloads.php.net/derick/ . Windows binaries will follow shortly.
Please test it carefully, and report any bugs in the bug system, but
only if you have a short reproducable test case.
If everything goes well, we can release it
On 18 November 2005 11:48, Derick Rethans wrote:
On Fri, 18 Nov 2005, Andreas Korthaus wrote:
Derick Rethans wrote:
That's the problem - also grep does not know if [] is used for
arrays or stings. That's the same for programmers, it's often
not easy to conclude from context -
On 17 November 2005 21:42, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
Very few people converted to using {} so the argument about
reading old
code doesn't really hold. If you go and grep through all the public
code out there, pretty
- abstract is no longer valid in interfaces.
- that curly brace thing?
I've some fear of terrifying would-be upgraders with an
unnecessarily long list here :)
You're kidding.
If you're intentionally not adding things to that list, better do not
compile the list at all. If people use it as
Derick Rethans wrote:
Don't you think it's useful to allow a convention like {} for strings and []
for arrays, so you can be sure what $str{1} means without looking at any
context?
No.
Derick
ok, next stop: Operator Overloading? ;)
--
Hartmut Holzgraefe, Senior Support Engineer
+1 for keeping {} sintax in PHP6.
It's not fair for all those people who endeavoured to write a good PHP
code and followed the recommendations for it.
And why should this feature be removed while in the mean time PHP
developers are desparately keeping some very very old stuff for BC
reasons?
This
Jani, I'm going to slip that into the upgrade notes - I wasn't aware you
could do this 'til now either!
- Original Message -
From: Jani Taskinen [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; internals@lists.php.net
Sent: Friday, November 18, 2005 8:06 AM
Hi Matthias,
I'm talking about skipping new features, not about skipping changes that
will affect existing code.
'That curly brace thing' is already in. Checking abstraction in interfaces,
thanks for your input!
- Steph
- Original Message -
From: Matthias Pigulla [EMAIL PROTECTED]
On Fri, 18 Nov 2005, Steph Fox wrote:
Jani, I'm going to slip that into the upgrade notes - I wasn't aware you
could do this 'til now either!
- Original Message -
From: Jani Taskinen [EMAIL PROTECTED]
To: Andi Gutmans [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; internals@lists.php.net
I hear a lot of opinions here on the curly braces issue, and while I don't
use them, they're not in the way. I'd say let's keep them in.
As far a code readability and obviousness goes, I doubt anybody would
guess their way to the $str{5} syntax. If you were new to
PHP and you
were
The shell script we use here at work can be found here:
http://www.php.net/~jani/patches/syntax_check.sh.txt
We have this line in our CVSROOT/commitinfo file:
ALL $CVSROOT/CVSROOT/syntax_check.sh %r/%p %s
--Jani
On Fri, 18 Nov 2005, Steph Fox wrote:
Jani, I'm
Anybody interested in my two cents? (I shouldn't have asked as I'm going
to tell you anyway.)
rant mode on
You will break many more scripts by dropping [] for strings than the
other way around. Do you agree? - Heck, this sounds as if you're doing
a let's drop stuff for some technical reason no
Matthias Pigulla wrote:
Even the attempt of trying to change or remove some language feature
like the {} thing IN A RC5 is unbelievably unprofessional.
For the 13th time. {} is not going away in 5.1.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
And it really should not be going away in PHP 6 either. I
don't get why you are suggesting to expend so many resources
as part of a migration effort while it is obvious that there
are no advantages at all in dropping {}. It makes no sense.
- Sascha
On Fri, 18 Nov 2005,
On Fri, 18 Nov 2005, Sascha Schumann wrote:
And it really should not be going away in PHP 6 either. I
don't get why you are suggesting to expend so many resources
as part of a migration effort while it is obvious that there
are no advantages at all in dropping {}. It makes
Hey, you're still alive?
Alive and kicking.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The PHP 6 stuff is still up in the air. The original suggestion was to
carry through with the deprecation of [] which I strongly vetoed since
it would break everything. We can revisit whether we want to remove {}
in PHP 6. I didn't think people had such strong feelings about it.
From my
Maybe you have spoken to the wrong people then. Since {} has
been advocated for quite some time as the Right Way to access
string offsets, basically all PHP books teach that syntax.
As such {} is used very frequently. There are vast amounts
of code with that syntax.
Ford, Mike wrote on Friday, November 18, 2005 7:58 AM:
On 17 November 2005 21:42, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
Very few people converted to using {} so the argument about reading old
code doesn't really hold.
For the 13th time. {} is not going away in 5.1.
From the NEWS file:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
That is, code that has been tested with RC4 and that worked (not even a
notice on whatever
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
I suggest removing that warning immediately until the matter
is resolved.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To
I suggest removing that warning immediately until the matter
is resolved.
+1 ( times the discount-for-rants-factor )
-mp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi.
Is there really a good reason to drop {} string access? Does it make
the engine better? Are you going to use {} for something else? If not,
then wouldn't it make logical sense to do what was documented and drop
the [] syntax? Sure, I've read the argument that [] is used in other
languages but
I've recently opened a bug report #35243, and was requested to send the patch
in unified diff format to this list. Here it is, as requested, both in
plaintext, and uuencoded (in case the mailer really messes things up).
I'd appreciate any feedback, as this is my first time posting a patch.
Following an offline discussion with some internals folks, I've put together
a general hashing extensions which could potentially find a place in core as
an enabled by default extension:
ext/hash:
string hash(string $algo, string $value[,$raw=false])
string hash_file(string $algo, string
As requested, the patch as a plain-text MIME attachment.
Unfortunately, I don't have easy access to a public server where I can post the
file.
David.
--- On Fri 11/18, Wez Furlong [EMAIL PROTECTED] wrote:
From: Wez Furlong [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hello,
no matter if we get another hash extension or not. Here is a simple
extension, that gives you access to sha256() and sha256_file() when
loaded. If you load it into a PHP that already knows about these
functions (Hardening-Patch) you will get a warning.
Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6 comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.
We had something similar to (a)
I'm just putting on some finishing touches and will post a tarball later
today.
Meh... It'll be easier to discuss within CVS... It's in pecl/hash as of now.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon wrote:
string hash(string $algo, string $value[,$raw=false])
string hash_file(string $algo, string $filename[,$raw=false])
Hm... hash(string $value[, $algo='sha256' [,$raw=false]])?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Assuming that sha256 is always going to be the best default is pretty
short-sighted.
It's only a matter of time before that one is partially broken in some
way too; we won't be able to change the default value of the function
by then, because everyone using the default will have code that
depends
Jason Garber wrote:
Hello Internals,
Remember the ifsetor() discussion? There were many, many people for
it, and many people that did not see the point. To this day, it's
not been allowed into the source tree, and I don't see any way to
change that. So...
Please consider (some
Roman Ivanov wrote:
I dare to suggest PHP replacement:
...
Clarification: this does not mean I endorse macroses in any way.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2005-11-18, Robert Cummings [EMAIL PROTECTED] wrote:
On Fri, 2005-11-18 at 03:12, Derick Rethans wrote:
On Thu, 17 Nov 2005, Robert Cummings wrote:
On Thu, 2005-11-17 at 16:42, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
42 matches
Mail list logo
