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
and "fix" the current inconsistencies comes at a cost, and we need
to be very careful in justifying that cost.
I agree. You are right.
The cost of introducing new names disappears over time. The cost of
having inconsistent name accumulates.
You've said this a couple of times, but I'm not sure what you mean. What
is the cost which is accumulating in the current situation, and how will
your proposal stop or reverse this accumulation?
>My proposal only requires simple replace. [...]
You have to do at least a bit of code parsing, because you
wouldn't want to change things like echo 'Your site has
exploded!'; or function check_blob_is_in_array_twice() { ... }
Only because old names/parameter order is inconsistent, making old
function names deprecated/removed is not a good idea. IMO. It should
be available as valid/official name/function for a long time if it is
ever removed/deprecated.
Can you please try to respond to the actual points I make, rather than
repeating the same ones? You said changing names would be a "simple
replace"; I pointed out that it would be more complicated than that
(automatable, but not as trivial as find-and-replace in a text editor).
This has nothing to do with parameter order, and nothing to do with the
old names being removed - just that, if people want to make use of your
new function names, they will need a tool to update their code.
No, no, no, and no. ArrayObject is a rarely-used class allowing
users to have something that's halfway between an array and an
object. It was introduced in PHP 5, but only guaranteed to be
available in PHP 5.3 (because distributions could disable the SPL
extension by default before that); the majority of users of PHP
have probably never heard of it. It also can't, and isn't intended
to, replace the normal array type, which is incredibly flexible,
and at the heart of many parts of PHP.
Then we may be better to declare deprecation of ArrayObject now.
No, because it probably still has its uses, and nobody is being
encouraged to use it in a way that will interfere with our ability to
create "scalar methods" later.
An important point you may have missed is that some of the proposals
around methods on scalar values don't really propose turning the values
into objects, just adding some syntactic sugar to the language so that
'foo'->toUppercase() is a way of writing strtoupper('foo').
Contrast that to, say, in_array(), which has been around for at
least 15 years, probably more, and is probably used in about 90%
of PHP scripts written in that time, including thousands which are
still maintained, or publically available to be used as examples
by new programmers. Any argument treating the two as equivalent is
a straw man.
I agree that there will be confusions in short term. We have very fast
release cycle, PHP 5.6 is only supported for 3 years from now.
If only it were true that "not supported" meant "nobody cares about".
AFAIK, Wordpress is still actively supporting PHP 5.2, which has been
unsupported for over 4 years already. The time scale you need to worry
about is how long until people start using your new names, and how long
after that until they use the old ones rarely enough that people don't
need to learn them anyway.
PHP will introduce new way of programming, including OO, why do you
care much about 3rd party documents? They have to rewrite documents
for new PHP anyway.
Why do I care about third parties? Because they are the backbone of the
language. The language is not you and me debating its future on a single
mailing list, it's thousands of people all over the world actually using it.
As I have said repeatedly, I prefer to have some kind of brand new
API, so that it is really obvious to users that they are using
"the new API" or "the old API", rather than a bunch of minor
variations which you can only learn by studying the manual and
remembering which is which. Adding methods on scalars and arrays
(which doesn't necessarily mean making them objects in any
meaningful way) is just a way of achieving that goal. If someone
comes up with a procedural API that feels new and fresh, I'm all
for it; a few changes to the existing API, I'm against.
The change is about "consistency". Many users complain about it for a
long time. New API should have consistent API as well as old API, IMHO.
But the old API already isn't consistent, and unless you remove all the
current function names, it will *never* be consistent, because those
names will be there, inconsistently.
But if nobody adopts the new functions, all your effort will have
been in vain. If every PHP script was written in complete
isolation, used for a while, and thrown away, a free choice makes
sense. But old code *evolves* into new code, and now more than
ever, PHP has an eco-system of interoperable shared libraries, and
people need to be able to read and contribute to each other's
code. For any new names or API to be successful at all, people
have got to WANT to change their code.
Users don't have to rush into new names. It's OK for not adopting new
names in short term at all. Old names/functions are valid
names/functions. I think it is enough if users use new names mostly
decades later.
This is basically the reasoning that led to the Y2K bug: "if we wait
long enough, people won't be looking at this old code, they'll have
replaced it all. It turns out, code tends to proceed by evolution not
revolution, so however long you wait, there will still be the same
reasons not to switch over to the new names.
It's not that namespaces would make code hard to read as such.
What would make code hard to read would be having the same
function work differently depending on a setting at the top of the
file. You'd be replacing one kind of inconsistency with another.
Many languages support creating whole new function/class names
including PHP. We can have strlen() which returns string length rather
than bytes with current namespace. To find out what really happens on
function call, we need to check "namespace". I don't see much
difference between default namespace by INI and namespace used in
script. Both are the declaration of namespace to be used.
I agree that adding place to look will be additional work.
Yes, it's not so much that it's not *possible* right now, as that it's
not explicitly *encouraged*. If the authors of Symfony decided they were
going to write a function called Symfony\replacement\strlen and "use
function" it at the top of every file in their distributed code and
coding guidelines, it would not be a popular move. Using namespace
imports to alter behaviour as a hack around BC concerns means explicitly
encouraging people to do something that makes their code harder to read.
I would re-word point 1 as "...replaced by new/better API,
probably OO or OO-like". The emphasis is on the new, not the OO, IMHO.
I think this is the root of our opinion differences.
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.
I'm going to say this one more time, and in a very short sentence, in
the hope that you'll actually understand/believe me:
I do not see it as a choice between OO and procedural API.
I estimate cost of inconsistency is long term and huge.
You estimate introduction cost of consistent names is huge, even if
it's short term cost disappears over time.
I estimate that the cost of introducing new names if fairly large, and
fairly long-term.
I also take from the phenomenal success of PHP over the last twenty
years the knowledge that the cost of the inconsistency is not
cripplingly large.
I don't think users have to rewrite their existing code at all, so
no/little confusions.
You think users will try to rewrite their existing code, and there is
confusions.
No, I think users *won't* rewrite their existing code, but since they
won't, the new functions will simply be unused aliases, and the old
functions will remain the de facto "real" names.
More specifically, this is what I see happening if your proposal passes:
- Existing projects, both public and private, will debate whether to
convert their code to the new names. Most will see little benefit in
doing so. Many will maintain compatibility with extremely old versions
of PHP, and be basically unable to do so.
- Coding standards will be forced to choose which names to use; because
it's not obvious looking at a name whether it's "old", "new", or
"unchanged", they will have to create whole lists of banned function names.
- PHP-FIG will debate things at great length, and come to a conclusion
that not everyone likes, causing friction in the community.
- New contributors will submit patches using the new names to projects
whose policies require the old names, and be confused by the comments
they get back.
- New developers will read through eixsting tutorials and code,
including cutting-edge code written to the above standards, and still
see the same inconsistencies they see now.
- Small projects will adopt the new names, forcing developers to learn
both. People used to only the new names will keep having to check the
manual to be sure the functions are actually just aliases.
- The people who like to find excuses to criticise PHP will look at the
situation, and say it proves how awful PHP is.
This is, I admit, a pessimistic scenario. But the worst case scenario
for *not* changing the names appears to be "people will carry on using
PHP, but be a bit annoyed at the naming inconsistencies occasionally,
and maybe write blog posts about it; some people will be annoyed enough
to choose a different language". Do you have a different worst case
scenario that makes you so keen to change the names?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php