hi,
While reading the various discussions about what we should change,
kill, remove, rename and similar operations, I thought it would be
good to put things back in perspective.
It is indeed very appealing to think about killing every single little
annoyances PHP has accumulated. The idea to be able to write "nice and
clean" code makes me feel good.
However it has drawback, adoption.
One thing I would very strongly consider is the actual gains brought
by a change.
-
rename or alias functions to fulfill our naming conventions or
coding standards
. where is the gain in the long term?
. most of the functions are procedural and string/array/scalar
related. I would prefer to think about alternative solutions like the
NIkic's proposal using OO-like APIs. Keeps BC, brings cleaner APIs
into the game -
Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.
--
Pierre
@pierrejoye | http://www.libgd.org
clicked too early, more to come, but feel free to reply to this part alreay :)
hi,
While reading the various discussions about what we should change,
kill, remove, rename and similar operations, I thought it would be
good to put things back in perspective.It is indeed very appealing to think about killing every single little
annoyances PHP has accumulated. The idea to be able to write "nice and
clean" code makes me feel good.However it has drawback, adoption.
One thing I would very strongly consider is the actual gains brought
by a change.
rename or alias functions to fulfill our naming conventions or
coding standards
. where is the gain in the long term?
. most of the functions are procedural and string/array/scalar
related. I would prefer to think about alternative solutions like the
NIkic's proposal using OO-like APIs. Keeps BC, brings cleaner APIs
into the gameCase sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.--
Pierre@pierrejoye | http://www.libgd.org
--
Pierre
@pierrejoye | http://www.libgd.org
Pierre,
hi,
While reading the various discussions about what we should change,
kill, remove, rename and similar operations, I thought it would be
good to put things back in perspective.It is indeed very appealing to think about killing every single little
annoyances PHP has accumulated. The idea to be able to write "nice and
clean" code makes me feel good.However it has drawback, adoption.
One thing I would very strongly consider is the actual gains brought
by a change.
rename or alias functions to fulfill our naming conventions or
coding standards
. where is the gain in the long term?
. most of the functions are procedural and string/array/scalar
related. I would prefer to think about alternative solutions like the
NIkic's proposal using OO-like APIs. Keeps BC, brings cleaner APIs
into the gameCase sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.
Amen!
Andrey
- Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.
On the contrary, I'd argue a lot of applications use lowercase names
anyhow. And as I've mentioned before, it'd be trivial to write a tool to
automatically correct existing source.
--
Andrea Faulds
http://ajf.me/
- Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.On the contrary, I'd argue a lot of applications use lowercase names anyhow.
And as I've mentioned before, it'd be trivial to write a tool to
automatically correct existing source.
Anyone not being a developer will never use it. Let alone conservative
projects, or already released applications. There is no gain. However
there are tools already to apply whatever CS one wishes to existing
source code, or to check CS on commit. That's what one can uses case
sensitive naming without us having to break everything out there. I
think we can disagree on that and do not discuss that forever, if
there is a RFC about it, we will vote on it and that's it :) My
mistake was to send this mail too early, more important points coming
:)
CHeErs,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
- Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.On the contrary, I'd argue a lot of applications use lowercase names anyhow.
And as I've mentioned before, it'd be trivial to write a tool to
automatically correct existing source.
Anyone not being a developer will never use it. Let alone conservative
projects, or already released applications. There is no gain. However
there are tools already to apply whatever CS one wishes to existing
source code, or to check CS on commit. That's what one can uses case
sensitive naming without us having to break everything out there. I
think we can disagree on that and do not discuss that forever, if
there is a RFC about it, we will vote on it and that's it:) My
mistake was to send this mail too early, more important points coming
:)
For people who only work on Windows systems then the problem does not exist as
such, but continually fighting legacy projects that originated in that
environment, trying to clear up lax case usage, pinning this down makes sense to
me. Add to this the problem that allowing proper Unicode support across the
board, then simply allowing limited case 'insensitivity' going forward does not
make sense either. Comments have been made about not allowing foo/Foo at the
same time, and yes this can be a problem when involving Windows file names but I
think that is a different problem anyway. I am open to some mechanism to help
flag that problem, but I don't see the general simplification would cause any
problem if a project has used the same case everywhere.
I've just been reworking a project that works fine on windows, but fell flat on
Linux because a number of directory names used were different cases to the
classes in them ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Anyone not being a developer will never use it. Let alone conservative
projects, or already released applications. There is no gain. However
there are tools already to apply whatever CS one wishes to existing
source code, or to check CS on commit. That's what one can uses case
sensitive naming without us having to break everything out there. I
think we can disagree on that and do not discuss that forever, if
there is a RFC about it, we will vote on it and that's it :) My
mistake was to send this mail too early, more important points coming
:)
I don't care about coding style. I care about sanity here, and I think
case-insensitivity leads to more problems than it solves, especially, as
others have pointed out, when autoloading comes into play.
A case-fixing tool could be run once on existing codebases, break no
backwards compatibility, and make those codebases work on PHP 6.
--
Andrea Faulds
http://ajf.me/
Anyone not being a developer will never use it. Let alone conservative
projects, or already released applications. There is no gain. However
there are tools already to apply whatever CS one wishes to existing
source code, or to check CS on commit. That's what one can uses case
sensitive naming without us having to break everything out there. I
think we can disagree on that and do not discuss that forever, if
there is a RFC about it, we will vote on it and that's it :) My
mistake was to send this mail too early, more important points coming
:)I don't care about coding style.
Coding standards are part of the problem, that's not something we can ignore.
I care about sanity here,
Why pre commit checks do add sanity checks to existing projects, today.
and I think
case-insensitivity leads to more problems than it solves, especially, as
others have pointed out, when autoloading comes into play.
Right, while I did not meet one for years but we may work with
different projects or developers.
A case-fixing tool could be run once on existing codebases, break no
backwards compatibility, and make those codebases work on PHP 6.
I will 200% surely change my mind the day I see such tool working with
all major frameworks and applications out there without a single point
of failure.
However, I would suggest to waste too much time arguing about case
sensitivity, almost all of us agree that it is a good thing to have.
Only question is if it is a good idea at all to do it and only the
votes will solve this question.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Anyone not being a developer will never use it. Let alone conservative
projects, or already released applications. There is no gain. However
there are tools already to apply whatever CS one wishes to existing
source code, or to check CS on commit. That's what one can uses case
sensitive naming without us having to break everything out there. I
think we can disagree on that and do not discuss that forever, if
there is a RFC about it, we will vote on it and that's it :) My
mistake was to send this mail too early, more important points coming
:)I don't care about coding style. I care about sanity here, and I think case-insensitivity leads to more problems than it solves, especially, as others have pointed out, when autoloading comes into play.
A case-fixing tool could be run once on existing codebases, break no backwards compatibility, and make those codebases work on PHP 6.
Regardless of how we might wish the language had originally been
created, keeping compatibility is a very, very strong argument against
some of the recent compatibility-breaking RFCs and internals
discussions. Whether the pros outweigh the cons on a particular RFC is
a case-by-case question.
I agree with Pierre: make a strong RFC (and patch etc) and it can be
voted on.
The Python community has similar "discussions", e.g. see the link in:
https://twitter.com/ghrd/status/427879604070526976
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Christopher Jones wrote:
The Python community has similar "discussions", e.g. see the link in:
https://twitter.com/ghrd/status/427879604070526976
The best comment from that is
The solution is clear: build a full compatibility layer, not a conversion tool, into 3.x that makes 2.x code run without change and ABRUPTLY stop development on 2.x.
The simple fact that conversion of PY2 code so it will work in PY3 was the
problem since there is a MUCH smaller pool of programmers who are capable of the
work? It's not unlike PHP4 to 5 since there was little incentive to upgrade
systems that were working fine already.
Basically as long as PHP6 runs at least the bulk of PHP5.? code then there will
not be any major block. The only problem is should it run PHP5.2 code, or only
PHP5.6? Little things like only supporting e_strict?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
The best comment from that is
The solution is clear: build a full compatibility layer, not a
conversion tool, into 3.x that makes 2.x code run without change and
ABRUPTLY stop development on 2.x.
What this basically means, is "maintain backwards compatibility, but
make it an opt-in feature".
The only problem is should it run PHP5.2 code, or only PHP5.6? Little
things like only supporting e_strict?
No, the biggest problem (apart from implementing and maintaining it!) is
how to scope this compatibility layer.
If you have to turn it on with an ini setting - which generally means
for the whole deployment, or at least the whole application - then you
still have to have an almighty push to upgrade your application before
turning it off.
What might be more interesting is if it could be limited by namespace,
or by file, or something like that. Then you could include an entire
PHP5 library in a project which was otherwise taking advantage of PHP5++
features, right down to invoking a different parser if necessary.
I was pondering a similar idea for existing notices - particularly
E_STRICT, E_DEPRECATED, and E_NOTICE. The code base I work with relies
on some really old PEAR modules, which we're planning to phase out in
favour of something else. If we turn up error_reporting, we get a whole
load of notices from code we're never going to maintain, drowning out
any useful hints in code that was written last week.
Of course, to truly solve the adoption problem, the compatibility would
have to be 100%...
--
Rowan Collins
[IMSoP]
- Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.
Really? I'd definitely love to see it for class and function names. Have
you ever tried to deploy or develop an application with a team on different
operating systems, and had the entire code puke because someone
accidentally did casing wrong on a class name and the autoloader barfed
trying to load the file on a case-sensitive operating system?
I work with many developers using silly Mac OS X and it's case insensitive
file names. We deal with someone fat-fingering a class name on a regular
basis.
Really? I'd definitely love to see it for class and function names. Have you
ever tried to deploy or develop an application with a team on different
operating systems, and had the entire code puke because someone accidentally
did casing wrong on a class name and the autoloader barfed trying to load
the file on a case-sensitive operating system?I work with many developers using silly Mac OS X and it's case insensitive
file names. We deal with someone fat-fingering a class name on a regular
basis.
We are not talking about file paths here but method, function, constant names.
Cheersm
Pierre
@pierrejoye | http://www.libgd.org
On Tue, Jan 28, 2014 at 5:34 PM, Kristopher kristopherwilson@gmail.com
wrote:Really? I'd definitely love to see it for class and function names. Have
you
ever tried to deploy or develop an application with a team on different
operating systems, and had the entire code puke because someone
accidentally
did casing wrong on a class name and the autoloader barfed trying to load
the file on a case-sensitive operating system?I work with many developers using silly Mac OS X and it's case
insensitive
file names. We deal with someone fat-fingering a class name on a regular
basis.We are not talking about file paths here but method, function, constant
names.
Are we taking class and namespace names as well? Not sure why we would
address method, function and constant names and not address class and
namespace names.
And if we are addressing class names, then my point stands. When using
autoloaders, most often class and namespace names dictate path names.
So if we are talking class names, then we are most definitely talking paths
as well.
Kristopher wrote:
We are not talking about file paths here but method, function, constant
names.
Are we taking class and namespace names as well? Not sure why we would
address method, function and constant names and not address class and
namespace names.And if we are addressing class names, then my point stands. When using
autoloaders, most often class and namespace names dictate path names.So if we are talking class names, then we are most definitely talking paths
as well.
Exactly the one I'm hitting ... This automatic loading is not something I
actually like at all but just something else we have to live with these days? :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
- Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.Really? I'd definitely love to see it for class and function names. Have
you ever tried to deploy or develop an application with a team on different
operating systems, and had the entire code puke because someone
accidentally did casing wrong on a class name and the autoloader barfed
trying to load the file on a case-sensitive operating system?I work with many developers using silly Mac OS X and it's case insensitive
file names. We deal with someone fat-fingering a class name on a regular
basis.
then you are missing staging/CI servers on Linux to catch the problem.
Best,
Andrey
then you are missing staging/CI servers on Linux to catch the problem.
So since we have band-aid solutions, we can ignore silliness in the
language, then?
On Tue, Jan 28, 2014 at 9:32 AM, Pierre Joye pierre.php@gmail.com
wrote:
- Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.Really? I'd definitely love to see it for class and function names. Have
you ever tried to deploy or develop an application with a team on
different
operating systems, and had the entire code puke because someone
accidentally did casing wrong on a class name and the autoloader barfed
trying to load the file on a case-sensitive operating system?I work with many developers using silly Mac OS X and it's case
insensitive
file names. We deal with someone fat-fingering a class name on a regular
basis.then you are missing staging/CI servers on Linux to catch the problem.
not the language is silly, the developers are. Why C doesn't forbid out
of range accesses on arrays. Is the language silly?
Best,
Andrey
Andrey
not the language is silly, the developers are. Why C doesn't forbid out of
range accesses on arrays. Is the language silly?
Yes, I do think PHP is being silly. Again, treating "T" and "t" like
they're the same thing? They're not. One is an upper case T, one is a
lowercase t. They look different. They are different ascii and unicode
character codes. Languages that conform to this: Python, Ruby, C and Java.
Why does PHP feel the need to try to translate this developer typo?
Is this a beneficial "feature" of PHP? I don't think so. As I've harped on,
it definitely creates issues with autoloading across different platforms
when namespace or class names are cased improperly.
It's a big backwards comparability break, but one that's very easily fixed
with a third party tool that analyzes the code base for violations during
an upgrade phase.
I'd love to see it fixed in the next major PHP release. It is silly. I'm
sticking by that.
Really? I'd definitely love to see it for class and function names. Have
you ever tried to deploy or develop an application with a team on different
operating systems, and had the entire code puke because someone
accidentally did casing wrong on a class name and the autoloader barfed
trying to load the file on a case-sensitive operating system?
Why not just make your filenames all lowercase and use strtolower() in
the autoloader?
Seems like "someclassname.php" wouldn't be such an awful filename for
"class SomeClassName" if you can't rely on consistency of case handling
in the OS.
While I can kind of see the point, the case-sensitive check would still
presumably be made at run-time, so you'd still need to ensure you had
case coverage in case someone wrote CLassName in a branch of code they
didn't actually execute.
--
Rowan Collins
[IMSoP]
Hi Pierre,
However it has drawback, adoption.
One thing I would very strongly consider is the actual gains brought
by a change.
- rename or alias functions to fulfill our naming conventions or
coding standards
. where is the gain in the long term?
. most of the functions are procedural and string/array/scalar
related. I would prefer to think about alternative solutions like the
NIkic's proposal using OO-like APIs. Keeps BC, brings cleaner APIs
into the game
I agree it's nicer.
My only concern is that the same discussion was done about 10 years
ago and still don't have them. We may be able to clean up string/array
functions. However it seems odds are high that we still have live legacy
names
around next 10 years or more especially in modules...
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote:
. most of the functions are procedural and string/array/scalar
related. I would prefer to think about alternative solutions like the
NIkic's proposal using OO-like APIs. Keeps BC, brings cleaner APIs
into the gameI agree it's nicer.
My only concern is that the same discussion was done about 10 years
ago and still don't have them. We may be able to clean up string/array
functions. However it seems odds are high that we still have live legacy
names around next 10 years or more especially in modules..
I think what is missing here is simply an identification on what names people
think need changing? Certainly creating an alternative set of objects and
leaving the 'non-OO' baggage alone would be a lot more practical longer term?
The problem will be that some people will want a means of turning off the legacy
stuff and I am not sure that is really practical? e_strict currently seems to be
a millstone rather than a help, and unravelling the impact of that is something
that is key to PHP6 even before looking at moving things forward.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Just chiming in from the user point of view:
after being a PHP developer since PHP4 and using OO principles since
PHP4 (yes, it happened) and now living the dream with 5.3+ I
personally see absolutely no reason to change the function names etc.
Or even the camelcasing issues that might be there... As a user i'd
just like to see something that someone already mentioned: PHP growing
as a language to support the modern way of HTTP: sockets,
non-blocking, etc etc. Performance is everything. What i type (and how
i type it) is my business. If that's needle/haystack or
haystack/needle, doesnt matter in my book. As long as my IDE / muscle
memory kicks in when needed i'll be just fine.
Now for PHP to actually move towars a faster engine / JIT /
whathaveyou thát would be something i'd love to see. Also being able
to move my codebase to newer major releases with 'varying' ease is a
PLUS! The whole python2/3 issue should be avoided when possible.
(imho)
I really like the upgrade path starting from 5.3: minor breakage and
where it might break it would be for the better anyway...
(performance / security POV)
As to give my personal list of priorities for the language as a whole:
- really make the new(er) features shine vs the old and gray
array_walk / callbacks are still a fraction slower than 'simple',
but less elegant, foreach structures.... - improve the 32/64 bit differences
as already being discussed in a seperate RFC - better tooling for finding bottle necks right out of the box
I'd like a built in syntax / compiler / hhvm style checker to
analyze my project ... Without having to resort to external seperately
built tooling. Allowing some kind of compiler to actually tell me
where i could improve / cleanup my codebase would help me a lot.
If people are really adamant in creating OO versions of string / array
functions: nothing stops them from doing that in userspace today. (the
same goes for the aliasing of functions)
ok. that's me done ranting ... Just a small fish in a large ocean of
PHP sharks :)
In any case; good luck shepherding the development of such an
important and widely used language!
Regards,
Robin Speekenbrink
If people are really adamant in creating OO versions of string / array
functions: nothing stops them from doing that in userspace today. (the
same goes for the aliasing of functions)
I shouldn't need userspace addons to be able to remember the parameter
orders and names of string and array functions ;)
--
Andrea Faulds
http://ajf.me/
If people are really adamant in creating OO versions of string / array
functions: nothing stops them from doing that in userspace today.
While it's possible to do in extensions (as someone else linked to),
there's no way you could make anything remotely like this work in userspace:
$foo = 'Hello World';
$foo .= '!';
echo $foo->length;
I think that's more like what people mean by "OO-style strings".
--
Rowan Collins
[IMSoP]
Like Robin Speekenbrink already written from the view of the userland
As to give my personal list of priorities for the language as a whole:
- really make the new(er) features shine vs the old and gray
- 1 changes
- consistent 64 bit support (hopefully already 5.6)
- constistent Multibyte support
- string/array/scalar OOP style (like suggested from Pierre in his first
post with BC compability) - everything which improves performance
-1 changes
- rename functions names
- reorder function parameters
- case sensitivity
Hi all,
On Thu, Jan 30, 2014 at 4:16 PM, Martin Keckeis
martin.keckeis1@gmail.comwrote:
- 1 changes
- consistent 64 bit support (hopefully already 5.6)
- constistent Multibyte support
- string/array/scalar OOP style (like suggested from Pierre in his first
post with BC compability)- everything which improves performance
-1 changes
- rename functions names
- reorder function parameters
- case sensitivity
The same for me except case sensitivity. Full case sensitivity would be good
for performance and users should have consistent name even if they use
case insensitive file system, etc. IMO. There are to many strtolower() calls
and it impacts performance a lot...
BTW, I'm against rename functions. I don't want to rename functions but add
aliases.
These are totally different. Aliases would good for scalar OO API. We are
better to
have intuitive names
$str->something()
and
str_something($str)
To have consistent parameter order, we may have new name for them for both
OO and procedural API.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
2014-01-30 Martin Keckeis martin.keckeis1@gmail.com
Like Robin Speekenbrink already written from the view of the userland
As to give my personal list of priorities for the language as a whole:
- really make the new(er) features shine vs the old and gray
- 1 changes
- consistent 64 bit support (hopefully already 5.6)
- constistent Multibyte support
- string/array/scalar OOP style (like suggested from Pierre in his first
post with BC compability)- everything which improves performance
-1 changes
- rename functions names
Just because I had this in mind for days now, but didn't know, if that
comes up already, or if it is just a stupid idea: Wouldn't it be possible,
that somebody maintains a PECL-extension (or even userland), that keeps the
compatibility to pre-PHP6 function names and parameter order? So the core
could become "clean" of inconsistencies, but legacy code should still work.
- reorder function parameters
- case sensitivity
On the subject of 64-bit improvement, there was an argument to wait until
PHP6 so that extension maintainers had to deal with one extension
conversion, but a more broad one (because there will be other things
changing). I actually think it is not such a great idea, because when
dealing with multiple things to update, it is far easier to break something
or mess it up.
I want to point out, that although the adoption of PHP picked up the pace,
new versions are not adopted that fast. Many leaped over 5.4 to 5.5 because
5.4 does not have a working opcode cache and that is a major no go for
almost everyone.
Nethertheless, when PHP 6 is released, many will leap from 5.3 or 5.5
straight to it. 5.6 can be a kind of grace period to port and test the
extensions, so the majority of them is updated when PHP 6 comes. This will
also spread the workload and give a chance for everyone to catch up with
the 64 bit support. As part of this effort, there has to be an
informational campaign to inform people that extension developers have to
convert them. This has to be shown clearly and loudly (php.net front page
pinned announcement with linkage to the explanation of what the heck is
going on, also we should announce it all on any other channels that are out
there).
On the case of concerns of Yahoo and alike - it does not really matter,
because they have to do this work anyway - sooner or later, but the amount
of the required work does not change. Actually, if you cram too many
changes in a single release (PHP 6), you end up with even bigger workload,
because now you have to implement 64 bit support and other PHP 6
compatibility things - you end up in a state when for extension to work,
you have to do all the changes at once without the ability to separately
test if you 64 porting was done correctly. You end up with multiple changes
in one place and have to debug them all simultaneously.
The fact, that some companies still stick with 5.3 and don't update their
own code base does not concern the PHP developer team. It does not matter
if you do 64 bit support in 5.6 or 6.0 - Yahoo has it's own schedule and
they might migrate from 5.3 to 5.5 (well, because 5.4 has issues with
opcode cache - it's understandable to skip it over) and that plan may be
already in motion. So it will not matter for them if 5.6 has 64 bit support
or not. They might just wait for the PHP 6 after 5.5 (and it kind'a makes
sense).
So, I say you go with the 64 bit improvements for 5.6, set all the things
in motion, do the porting docs and make a hell lot of noise about this. I'm
willing to help with the information campaign, because this lack of proper
64 bit support has gave me a few "WTF?!" situations when I had to figure
out why things do not work and realize it's due to the 64 vs 32 bit issues.
Arvids.
So, I say you go with the 64 bit improvements for 5.6, set all the things
in motion, do the porting docs and make a hell lot of noise about this. I'm
willing to help with the information campaign, because this lack of proper
64 bit support has gave me a few "WTF?!" situations when I had to figure
out why things do not work and realize it's due to the 64 vs 32 bit issues.
You make it sound like 64-bit vs. 32-bit issues will go away with this
patch. If you are writing portable code that should run the same
everywhere you still have to worry about it. This change does not
suddenly give you 64-bit integers on a 32-bit platform. The main thing
this does is it makes 64-bit Windows no longer look like a 32-bit
platform. Other true 32-bit platforms remain 32-bit. It also makes it
possible to have >2g strings on 64-bit platforms, but this is hopefully
a rather rare requirement. Imagine running that code on a server with
MaxClients set to 50...
I am all for this change, but I still think it is too big of an API
break for a point release.
-Rasmus
30 янв. 2014 г. 17:45 пользователь "Rasmus Lerdorf" rasmus@lerdorf.com
написал:
So, I say you go with the 64 bit improvements for 5.6, set all the
things
in motion, do the porting docs and make a hell lot of noise about this.
I'm
willing to help with the information campaign, because this lack of
proper
64 bit support has gave me a few "WTF?!" situations when I had to figure
out why things do not work and realize it's due to the 64 vs 32 bit
issues.You make it sound like 64-bit vs. 32-bit issues will go away with this
patch. If you are writing portable code that should run the same
everywhere you still have to worry about it. This change does not
suddenly give you 64-bit integers on a 32-bit platform. The main thing
this does is it makes 64-bit Windows no longer look like a 32-bit
platform. Other true 32-bit platforms remain 32-bit. It also makes it
possible to have >2g strings on 64-bit platforms, but this is hopefully
a rather rare requirement. Imagine running that code on a server with
MaxClients set to 50...I am all for this change, but I still think it is too big of an API
break for a point release.-Rasmus
I've hit exactly the 32 bit ints on 64 bit windows. I know that 32 bit os
is 32, but i don't use those period for ages (due to some spesific stuff i
need big 64 ints).
Arvids.
So, I say you go with the 64 bit improvements for 5.6, set all the things
in motion, do the porting docs and make a hell lot of noise about this. I'm
willing to help with the information campaign, because this lack of proper
64 bit support has gave me a few "WTF?!" situations when I had to figure
out why things do not work and realize it's due to the 64 vs 32 bit issues.You make it sound like 64-bit vs. 32-bit issues will go away with this
patch. If you are writing portable code that should run the same
everywhere you still have to worry about it.
Right, for anything outside php's API&types usage. But that's already
a huge step forward.
This change does not
suddenly give you 64-bit integers on a 32-bit platform. The main thing
this does is it makes 64-bit Windows no longer look like a 32-bit
platform.
That's not accurate. The main things this patch does is to ensure
correct types for 64bit, ensure that large buffer length can be
managed correctly. It also provides compile time checks for 64bit
types where it was harder to figure them out before. The Windows
support for 64bit integer is a good side effect of this patch and why
we could assign resources to work on it. Please keep in mind that the
initial steps had nothing to do with Windows specific features.
Other true 32-bit platforms remain 32-bit. It also makes it
possible to have >2g strings on 64-bit platforms, but this is hopefully
a rather rare requirement. Imagine running that code on a server with
MaxClients set to 50...
I am all for this change, but I still think it is too big of an API
break for a point release.
I tried a couple of exts, it is really not that big. I will try to
improve the replace.php script to automate more things, especially
around zpp and related variables. That will ease the port of most of
the extensions.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
2014-01-30 Martin Keckeis martin.keckeis1@gmail.com
Like Robin Speekenbrink already written from the view of the userland
As to give my personal list of priorities for the language as a whole:
- really make the new(er) features shine vs the old and gray
- 1 changes
- consistent 64 bit support (hopefully already 5.6)
- constistent Multibyte support
- string/array/scalar OOP style (like suggested from Pierre in his first
post with BC compability)- everything which improves performance
-1 changes
- rename functions names
Just because I had this in mind for days now, but didn't know, if that
comes up already, or if it is just a stupid idea: Wouldn't it be possible,
that somebody maintains a PECL-extension (or even userland), that keeps the
compatibility to pre-PHP6 function names and parameter order? So the core
could become "clean" of inconsistencies, but legacy code should still work.
That sounds like the PHP_Compat PEAR package [1], which is looking for a
maintainer.
[1] http://pear.php.net/package/php_compat
- reorder function parameters
- case sensitivity
Hi!
- Case sensitivity
. Even with ini setting, which will be most likely system wild, will
bring a major breakage for almost every single app out there. I do not
see any gain to do it.
I would definitely not want to see any ini settings. There should not be
ini settings that change language semantics, it'd be a nightmare to
maintain and trying to write supported reqs for an app would look like
whole page of settings eventually if we do it.
With that, I don't think it'd break every single app - many apps
actually now, thanks to modern IDEs, are pretty consistent with names,
and most problems can be figured out by a tool. But I agree that such
things should not be a top priority. There are many things that would
have much better impact on much broader category of developers than
fixing small annoyance with a change having huge price tag (the same
goes for renaming functions, etc.).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227