2015-03-12 4:08 GMT+02:00 Lester Caine les...@lsces.co.uk:
On 11/03/15 22:44, Yasuo Ohgaki wrote:
Having namespace for internals would bring much flexibility for API
changes, both
OO and procedural API. I may try my best to have consensus.
I think you also like to have OO style API for
On 12/03/15 09:21, Arvids Godjuks wrote:
Basically this.
Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one
now, and adding a new subset of it looks pointless. It has it's problems
and legacy, you
Do you mean the PostgreSQL driver needs to be changed from pg_blah() to
pgBlah() ?
It was that extra underscores having been added to the pg_ functions is
being put forward as a reason for adding them everywhere else. That is
perhaps when this discussion should have been undertaken, but
2015-03-12 11:41 GMT+02:00 Lester Caine les...@lsces.co.uk:
On 12/03/15 09:21, Arvids Godjuks wrote:
Basically this.
Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one
now, and adding a new
Hi Rowan,
On Wed, Mar 11, 2015 at 9:32 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Lester Caine wrote on 10/03/2015 21:12:
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface, but
my original question still applies consistent with
Lester Caine wrote on 10/03/2015 21:12:
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface, but
my original question still applies consistent with what rules?
It's possible choice.
I agree that names without _ looks more consistent.
On 11/03/15 12:32, Rowan Collins wrote:
Lester Caine wrote on 10/03/2015 21:12:
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface,
but
my original question still applies consistent with what rules?
It's possible choice.
I agree that
On 3/11/2015 8:08 PM, Lester Caine wrote:
Personally I just want to keep the current name set and so the sheer
volume of changes proposed is a big kick in the face to me.
YES!
The time to make such a change to the names is about 1998 or maybe 2000.
Every person who learns the current names
On 11/03/15 22:44, Yasuo Ohgaki wrote:
Having namespace for internals would bring much flexibility for API changes,
both
OO and procedural API. I may try my best to have consensus.
I think you also like to have OO style API for basic
variables(int/float/array) as I am.
Unless we have
On 10/03/15 01:59, Yasuo Ohgaki wrote:
The same argument applies to fresh new OO APIs. It's just a matter of
targeted PHP version to be supported. There are many things to be
considered to decide targeted PHP version other than this RFC. We have many
new features/behaviors in newer PHP
Hi Lester,
On Tue, Mar 10, 2015 at 6:27 PM, Lester Caine les...@lsces.co.uk wrote:
On 10/03/15 01:59, Yasuo Ohgaki wrote:
The same argument applies to fresh new OO APIs. It's just a matter of
targeted PHP version to be supported. There are many things to be
considered to decide targeted
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface, but
my original question still applies consistent with what rules?
It's possible choice.
I agree that names without _ looks more consistent.
Personally, I don't care much about
Hi Gregory,
On Sun, Mar 8, 2015 at 7:03 PM, Grégory Planchat greg...@luni.fr wrote:
Le 08/03/2015 00:44, Yasuo Ohgaki a écrit :
Hi Gregory,
On Sun, Mar 8, 2015 at 2:12 AM, Grégory Planchat greg...@luni.fr wrote:
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and
Hi Rowan,
On Mon, Mar 9, 2015 at 7:42 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 08/03/2015 01:15, Yasuo Ohgaki wrote:
On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
To an extent, yes. Part of the point that I and
Le 08/03/2015 16:53, Lester Caine a écrit :
Lorem ipsum dolor sit amet-length();
Lorem ipsum dolor sit amet-search('lorem');
Lorem ipsum dolor sit amet-replace('lorem', 'Lorem');
This is actually the problem that trying to ignore unicode then creates
a black hole. The amount of space needed to
On 08/03/15 01:15, Yasuo Ohgaki wrote:
Let's agree to disagree. Otherwise, discussion will be circular.
I would like to keep/maintain legacy procedural functions forever.
You would like to replace/remove legacy procedural functions by OO like API
if it's possible.
Discussions like this need
Hi Yasuo,
Le 08/03/2015 00:44, Yasuo Ohgaki a écrit :
Hi Gregory,
On Sun, Mar 8, 2015 at 2:12 AM, Grégory Planchat greg...@luni.fr wrote:
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is alias or namespace
On 08/03/2015 01:15, Yasuo Ohgaki wrote:
On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
To an extent, yes. Part of the point that I and others are making
is that this is not a simple change to make. Whatever we do to try
On 08/03/15 10:03, Grégory Planchat wrote:
Then using multiple encodings in a same script or using a same script
for multiple encodings becomes straightforward and standard. Most PHP
developers doesn't even know what is Unicode or a character encoding,
they just see odd characters that are
Le 08/03/2015 12:17, Lester Caine a écrit :
On 08/03/15 10:03, Grégory Planchat wrote:
Then using multiple encodings in a same script or using a same script
for multiple encodings becomes straightforward and standard. Most PHP
developers doesn't even know what is Unicode or a character
On 08/03/15 13:53, Grégory Planchat wrote:
On 08/03/15 10:03, Grégory Planchat wrote:
Then using multiple encodings in a same script or using a same script
for multiple encodings becomes straightforward and standard. Most PHP
developers doesn't even know what is Unicode or a character
On 07/03/2015 01:30, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki yohg...@ohgaki.net
mailto:yohg...@ohgaki.net wrote:
Hi Rowan,
On Fri,
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is alias or namespace basically. I don't object to use
namespace for it at all. In fact, I would love to have it even if there is
issue
like writing extremely difficult
Hi Gregory,
On Sun, Mar 8, 2015 at 2:12 AM, Grégory Planchat greg...@luni.fr wrote:
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is alias or namespace basically. I don't object to use
namespace for it at all.
On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 07/03/2015 01:30, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki
Hi Pierre,
On Sat, Mar 7, 2015 at 7:18 AM, Pierre Joye pierre@gmail.com wrote:
Please suggest better/right way. Having namespace is not alternative for
having consistent names.
I think I did, and many other. But you seem to be convinced that
consistency in names is the top priority
Hi Rowan,
On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Ardids,
On Fri, Mar 6, 2015 at 8:22 AM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Why not take advantage of namespaces and do the new API, building it up
version by version (sure it can't be done in one go), so probably the
extensions gonna follow too.
That allows you to use as OO
On Sat, Mar 7, 2015 at 7:09 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Please suggest better/right way. Having namespace is not alternative for
having consistent names.
I think I did, and many other. But you seem to be convinced that
consistency in names is the top priority and will suddenly
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
2015-03-05 13:49 GMT+02:00 Pierre Joye pierre@gmail.com:
I will say it again a last time, in my opinion only a clean API;
object-like or real object as long as performance is not affected is
Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
arvids.godj...@gmail.com mailto:arvids.godj...@gmail.com wrote:
2015-03-05 13:49 GMT+02:00 Pierre Joye pierre@gmail.com
mailto:pierre@gmail.com:
I will say it
On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
arvids.godj...@gmail.com
On 5 March 2015 23:22:35 GMT, Arvids Godjuks arvids.godj...@gmail.com wrote:
Why not take advantage of namespaces and do the new API, building it up
version by version (sure it can't be done in one go), so probably the
extensions gonna follow too.
That allows you to use as OO interface, so do the
If PHP has macro or userspace aliasing!
This is one possible solution for this.
The engine has support for aliases. See
http://php.net/manual/en/internals2.ze1.zendapi.php
If I thought this “consistency” was very important (I do not, and I fully
expect an RFC on this to fail if this thread
Hi Rowan,
On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks arvids.godj...@gmail.com
mailto:arvids.godj...@gmail.com wrote:
2015-03-05 13:49 GMT+02:00 Pierre
2015-03-05 22:20 GMT+02:00 Yasuo Ohgaki yohg...@ohgaki.net:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
2015-03-05 13:49 GMT+02:00 Pierre Joye pierre@gmail.com:
I will say it again a last time, in my opinion only a clean API;
Hi Christian,
On Thu, Mar 5, 2015 at 4:34 PM, Christian Stoller stol...@leonex.de wrote:
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo
Ohgaki, Sent: Thursday, March 05, 2015 7:21 AM
For example, ctype extension has ctype_ prefix. It replaces
is to ctype_.
we may
Hi Rasmus,
On Thu, Mar 5, 2015 at 4:57 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/04/2015 10:21 PM, Yasuo Ohgaki wrote:
The same could be done for new names.
Manual pages for localtime()/mktime()/etc would look a lot nicer.
I hope there will be more favored developers with the
On 5 March 2015 03:59:00 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins
rowan.coll...@gmail.com
wrote:
On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
We cannot remove all issue at once. We are better to adopt
Hi Rowan,
On Thu, Mar 5, 2015 at 5:51 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 5 March 2015 03:59:00 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins
rowan.coll...@gmail.com
wrote:
On 4 March 2015 21:27:53 GMT, Yasuo
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki,
Sent: Thursday, March 05, 2015 9:45 AM
On Thu, Mar 5, 2015 at 4:34 PM, Christian Stoller stol...@leonex.de wrote:
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki,
Sent: Thursday, March
On Thu, Mar 5, 2015 at 3:21 AM, Rowan Collins rowan.coll...@gmail.com wrote:
Yasuo Ohgaki wrote on 05/03/2015 09:24:
I would love to have new OO APIs for variables. I also like to write
procedural
code for simple scripts. Therefore, even if we have new OO APIs, I would
like to
Hi Christian,
On Thu, Mar 5, 2015 at 7:15 PM, Christian Stoller stol...@leonex.de wrote:
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo
Ohgaki, Sent: Thursday, March 05, 2015 9:45 AM
On Thu, Mar 5, 2015 at 4:34 PM, Christian Stoller stol...@leonex.de
wrote:
From:
2015-03-05 13:49 GMT+02:00 Pierre Joye pierre@gmail.com:
I will say it again a last time, in my opinion only a clean API;
object-like or real object as long as performance is not affected is
the only way I could see to actually solve this problem.
Changing the names, argument order
Le 03/03/2015 00:02, Larry Garfield a écrit :
On 3/2/15 4:50 PM, Rowan Collins wrote:
On 02/03/2015 22:36, Yasuo Ohgaki wrote:
I like scalar objects, but it does not resolve that PHP has non standard
function names.
It does not change old names, therefore it's impossible to resolve
issue.
This
Yasuo Ohgaki wrote on 05/03/2015 09:24:
I would love to have new OO APIs for variables. I also like to write
procedural
code for simple scripts. Therefore, even if we have new OO APIs, I
would like to
improve/maintain procedural functions and make them not legacy functions.
I don't see
Pierre Joye wrote on 05/03/2015 11:49:
On Thu, Mar 5, 2015 at 3:21 AM, Rowan Collins rowan.coll...@gmail.com wrote:
Yasuo Ohgaki wrote on 05/03/2015 09:24:
I would love to have new OO APIs for variables. I also like to write
procedural
code for simple scripts. Therefore, even if we have new OO
@Rasmus:
I don't see what's the problem of aliasing functions for the next 1-2
majors, deprecate the inconsistent one in the following and remove later.
On Wed, Mar 4, 2015 at 10:33 AM, Trevor Suarez ric...@gmail.com wrote:
... well that's a constructive way of going about it. I don't think
On 03/03/2015 07:34 PM, Yasuo Ohgaki wrote:
Hi Michael,
On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett michaeljs1...@gmail.com
wrote:
Your evaluation is pretty anecdotal. I agree with some points but you need
some solid evidence if you are going to rate these languages. Also do you
On Wed, Mar 4, 2015 at 10:24 AM Rasmus Lerdorf ras...@lerdorf.com wrote:
Yasuo, please stop. This isn't going to happen. Changing strlen() to
str_len() is just ridiculous. -Rasmus
Trevor Suarez wrote on 04/03/2015 15:33:
... well that's a constructive way of going about it. I don't think
On 04/03/15 17:03, Rowan Collins wrote:
so if you're looking for something constructive, help move those ideas
forward, rather than flogging the dead horse.
The extensive changes documented in this RFC are well over the top, but
a much better approach would be to identify blocks which do allow
On 03/04/2015 08:26 AM, guilhermebla...@gmail.com wrote:
@Rasmus:
I don't see what's the problem of aliasing functions for the next 1-2
majors, deprecate the inconsistent one in the following and remove later.
As far as I am concerned str_len() would be the inconsistent one. Like I
explained
On 3/4/15 9:03 AM, Rowan Collins wrote:
On Wed, Mar 4, 2015 at 10:24 AM Rasmus Lerdorf ras...@lerdorf.com wrote:
Yasuo, please stop. This isn't going to happen. Changing strlen() to str_len()
is just ridiculous. -Rasmus
Trevor Suarez wrote on 04/03/2015 15:33:
... well that's a
Hi Rowan,
On Wed, Mar 4, 2015 at 6:16 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Several of the costs I listed are for new users, and several will continue
indefinitely if we don't remove the old names, and are therefore long term.
Could you be more explicit in the benefits you see?
Hi Leigh,
On Thu, Mar 5, 2015 at 4:30 AM, Leigh lei...@gmail.com wrote:
On 1 March 2015 at 11:29, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely
... well that's a constructive way of going about it. I don't think Yasuo
did anything harmful or rude in making his proposal. Regardless of how
realistic the idea may be, I don't think its ever appropriate or
constructive to tell someone to simply stop because something is just
ridiculous.
On
On 1 March 2015 at 11:29, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely no reason for this to be in core, and absolutely
not worth the trouble it
Hi Michael,
On Wed, Mar 4, 2015 at 12:58 PM, Michael Schuett michaeljs1...@gmail.com
wrote:
So i find this kind of odd since you use err every other place in bz. but
this is a minor nitpick.
- bz_error → bzerror
- bz_error_str → bzerrstr
Overall I fell this change would be nice for
Leigh wrote:
On 1 March 2015 at 11:29, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Thoughts?
require 'function_aliases.php'; // End of discussion.
It is not possible to my knowledge, however, to define function aliases
in PHP (a wrapper function would have an obvious performance penalty).
On 3/3/15 6:46 PM, Yasuo Ohgaki wrote:
Whether we like it or not, people evaluate languages by matrix like
PHP RubyPython
OO support5 5 5
Flexible syntax 3 5 5
AOP
Hi Pierre,
On Thu, Mar 5, 2015 at 8:54 AM, Pierre Joye pierre@gmail.com wrote:
On Wed, Mar 4, 2015 at 1:36 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Leigh,
On Thu, Mar 5, 2015 at 4:30 AM, Leigh lei...@gmail.com wrote:
On 1 March 2015 at 11:29, Yasuo Ohgaki yohg...@ohgaki.net
On Wed, Mar 4, 2015 at 1:36 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Leigh,
On Thu, Mar 5, 2015 at 4:30 AM, Leigh lei...@gmail.com wrote:
On 1 March 2015 at 11:29, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it
Hi Rowan,
On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
We cannot remove all issue at once. We are better to adopt incremental
improvement, aren't we?
I think this, more than anything else,
Hi Rasmus,
On Thu, Mar 5, 2015 at 2:14 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
Every function name defined by IEEE Std 1003.1 along with the arguments
and argument order would be on that list. When we have procedural
functions that are either thin wrappers around or otherwise behave
On 03/04/2015 10:21 PM, Yasuo Ohgaki wrote:
The same could be done for new names.
Manual pages for localtime()/mktime()/etc would look a lot nicer.
I hope there will be more favored developers with the RFC. Since I'm
going to
update manual to have alias search feature, developers used to
On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
We cannot remove all issue at once. We are better to adopt incremental
improvement, aren't we?
I think this, more than anything else, is where I disagree (having been
persuaded by arguments in previous discussions). Incremental
Hi Rasmus,
On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/04/2015 08:26 AM, guilhermebla...@gmail.com wrote:
@Rasmus:
I don't see what's the problem of aliasing functions for the next 1-2
majors, deprecate the inconsistent one in the following and remove
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki,
Sent: Thursday, March 05, 2015 7:21 AM
For example, ctype extension has ctype_ prefix. It replaces
is to ctype_.
we may have isalpha alias as IEEE compliant name. There are many
IEEE confirmed names already. Only
On 03/04/2015 08:25 PM, Yasuo Ohgaki wrote:
Hi Rasmus,
On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf ras...@lerdorf.com
mailto:ras...@lerdorf.com wrote:
On 03/04/2015 08:26 AM, guilhermebla...@gmail.com
mailto:guilhermebla...@gmail.com wrote:
@Rasmus:
I don't
On 04/03/15 03:34, Yasuo Ohgaki wrote:
I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
If you have suggestions, I appreciate!
Taking the starting point ... the coding standard for writing C code for
PHP ... personally I would
On 04/03/15 10:16, Michael Wallner wrote:
While http has been rejected for bundling, it is another example of not
following the C coding standard …
Lester, please stop posting walls of unrelated text. You’re totally off
track. If we’re talking about coding standards, we’re not talking about
On 4 March 2015 00:46:49 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
You are measuring the wrong cost. The cost of adding new names is to
people writing code:
- additional confusion for new users about why
On 04/03/15 00:44, Pierre Joye wrote:
For a php developer point of view, for someone not knowing c or php
internals APIs, I highly recommend https://github.com/phalcon/zephir
Yasuo is pushing function names on the basis of following the coding
standard, but again these secondary tools muddy the
On 04 03 2015, at 09:58, Lester Caine les...@lsces.co.uk wrote:
On 04/03/15 03:34, Yasuo Ohgaki wrote:
I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
If you have suggestions, I appreciate!
Taking the starting point ...
Yasuo Ohgaki wrote on 03/03/2015 04:01:
Hi Lester,
On Tue, Mar 3, 2015 at 9:19 AM, Lester Caine les...@lsces.co.uk wrote:
On 02/03/15 23:54, Yasuo Ohgaki wrote:
This looks awful... just cannot put up with...
Rasmus has already answered, but are you prposing to rewrite -
On 03/03/15 18:54, Yasuo Ohgaki wrote:
More or less, we do need maintenance, otherwise phpversion() will remain
inconsistent forever. IMO.
Is there any reason why a few peripheral functions like that can't
simply remain as is?
ADDING an object with what I will simply describe as 'the new style
Hi Rowan,
On Tue, Mar 3, 2015 at 7:13 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 03/03/2015 04:01:
Hi Lester,
On Tue, Mar 3, 2015 at 9:19 AM, Lester Caine les...@lsces.co.uk wrote:
On 02/03/15 23:54, Yasuo Ohgaki wrote:
This looks awful... just cannot put up
On 3 March 2015 18:54:56 GMT, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Tue, Mar 3, 2015 at 7:13 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 03/03/2015 04:01:
Hi Lester,
On Tue, Mar 3, 2015 at 9:19 AM, Lester Caine les...@lsces.co.uk
wrote:
On
On 3 March 2015 20:08:45 GMT, Lester Caine les...@lsces.co.uk wrote:
The piece of the jigsaw I am missing is at which point does it become
better to create a new extension for a complex object rather than
simply
writing a set of PHP classes?
A good question, wrappers can achieve a lot here. An
Hi Rowan,
On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
You are measuring the wrong cost. The cost of adding new names is to
people writing code:
- additional confusion for new users about why everything has two names
and which they should use
- extra effort
On Mar 4, 2015 9:18 AM, Rowan Collins rowan.coll...@gmail.com wrote:
On 3 March 2015 20:08:45 GMT, Lester Caine les...@lsces.co.uk wrote:
The piece of the jigsaw I am missing is at which point does it become
better to create a new extension for a complex object rather than
simply
writing a
On Wed, Mar 4, 2015 at 12:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
(Security should be evaluated by how difficult to make mistakes, not
how easy to
fix mistakes generally. IMHO)
And the consequence of the security breach, of course.
--
Yasuo Ohgaki
yohg...@ohgaki.net
So i find this kind of odd since you use err every other place in bz. but
this is a minor nitpick.
- bz_error → bzerror
- bz_error_str → bzerrstr
Overall I fell this change would be nice for new people coming to PHP and
alienate some long time users. We also run the risk at this point
Hi Michael,
On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett michaeljs1...@gmail.com
wrote:
Your evaluation is pretty anecdotal. I agree with some points but you need
some solid evidence if you are going to rate these languages. Also do you
have a list of all the functions you would like to
Your evaluation is pretty anecdotal. I agree with some points but you need
some solid evidence if you are going to rate these languages. Also do you
have a list of all the functions you would like to rename or is this a
sweeping lets just change everything so it matches and deprecate all the
old
Hi Pierre,
On Tue, Mar 3, 2015 at 6:40 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Mar 1, 2015 at 3:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time.
On Mon, Mar 2, 2015 at 1:58 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Tue, Mar 3, 2015 at 6:40 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Mar 1, 2015 at 3:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
First of all, I have no intention removing old
On 3/2/15 4:01 PM, Pierre Joye wrote:
Sorry, I do not see how a new thread helps. Namespace either. These
will only be duplicated APIs for little to no gain. Existing codes
won't move as they won't be compatible with 5.x.
We should really consider Nikita's experiment instead,as it acutally
On 02/03/2015 22:09, Yasuo Ohgaki wrote:
I think old function names should exist forever, so there wouldn't be
issue you mentioned.
...
The issue here is PHP will keep inconsistent names forever or not.
IMHO.
Have you noticed the slight contradiction here? You want to get rid of
the
On 3/2/15 5:10 PM, Yasuo Ohgaki wrote:
I would love to have new clean APIs.
Please think my proposal as legacy API cleanups. Many of candidates will
remain
without CORDING_STANDARSDS confirmed names almost forever. This is what
I would like to improve. If you don't care about legacy stuff
hi,
On Sun, Mar 1, 2015 at 3:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time.
http://www.phpsadness.com/sad/4
http://www.phpsadness.com/sad/15
On 02/03/2015 22:59, Yasuo Ohgaki wrote:
Hi Rowan,
On Tue, Mar 3, 2015 at 7:50 AM, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
On 02/03/2015 22:36, Yasuo Ohgaki wrote:
I like scalar objects, but it does not resolve that PHP has
non
Hi Markus,
On Mon, Mar 2, 2015 at 4:47 PM, Markus Fischer mar...@fischer.name wrote:
On 01.03.15 21:19, Yasuo Ohgaki wrote:
The answer is no, it's just not worth it. Having a function called
str_pos which is an alias of strpos, but only on some versions, is more
confusing, not less.
On 03.03.15 00:10, Yasuo Ohgaki wrote:
I would love to have new clean APIs.
Please think my proposal as legacy API cleanups. Many of candidates will
remain
without CORDING_STANDARSDS confirmed names almost forever. This is what
I would like to improve. If you don't care about legacy stuff
On 02/03/15 21:39, Yasuo Ohgaki wrote:
I wrote almost complete list. Please take a look at
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
While the idea of this is well meant, this is another major problem for
developers working with substantial legacy code
Hi Lester,
On Tue, Mar 3, 2015 at 7:00 AM, Lester Caine les...@lsces.co.uk wrote:
On 02/03/15 21:39, Yasuo Ohgaki wrote:
I wrote almost complete list. Please take a look at
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
While the idea of this is well
On 02/03/15 22:09, Yasuo Ohgaki wrote:
Old names works. No one forces users to use new names.
I'll update PHP documents. It's a lot of work, but I'll.
3rd party documents may be update if they would like to.
Some developers will drop PHP5 support for third party libraries in much
the same
On 02/03/2015 22:36, Yasuo Ohgaki wrote:
I like scalar objects, but it does not resolve that PHP has non standard
function names.
It does not change old names, therefore it's impossible to resolve issue.
This is the reason why I'm proposing while I like scalar object, use of
namespace, etc.
On Mon, Mar 2, 2015 at 2:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Tue, Mar 3, 2015 at 7:40 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
The issue here is PHP will keep inconsistent names forever or not.
IMHO.
Have you noticed the slight contradiction here? You want
Hi Larry,
On Tue, Mar 3, 2015 at 7:22 AM, Larry Garfield la...@garfieldtech.com
wrote:
Sorry, I do not see how a new thread helps. Namespace either. These
will only be duplicated APIs for little to no gain. Existing codes
won't move as they won't be compatible with 5.x.
We should really
1 - 100 of 123 matches
Mail list logo
