Hi again,
I was asked to explain why I hadn't included ClassName->Method(); in the
list of ideas that solve the ambiguity problem. I added a brief section
to the RFC that does so:
http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work
Thanks,
Greg
Hi again,
I was asked to explain why I hadn't included ClassName->Method(); in the
list of ideas that solve the ambiguity problem. I added a brief section
Can we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.
-Hannes
Hannes Magnusson wrote:
I was asked to explain why I hadn't included ClassName->Method(); in the
list of ideas that solve the ambiguity problem. I added a brief sectionCan we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.
The problem with that statement is that if it is used to ignore the other
problems, then at some point it may be necessary to re-write all the new
namespace code simply to allow additional features to be added!
While I think it would be NICE to see a different separator, ':::' seems to
annoy people, and using something else may cause problems for people with
'non-standard' keyboards who have trouble with some characters already?
So 'USE' ?
I'm I understanding things right on this one that one would 'define' the
namespace in one sort of header file, and then add the use namespace to those
files that build on the basic definition? I'm looking in particular here at a
library like ADOdb, where 'adodb.inc.php' has a number of global functions
which are then used by the various drivers. So 'adodb.inc.php' would define
'ADOdb' as a namespace and each driver would
'use namespace ADOdb'
This seems a good example to work with and is the reason that simply dropping
functions rang alarm bells with me. In fact it was the Date stuff from ADOdb
that caused so much trouble with 'Date' in earlier releases so it seems
appropriate to investigate how namespace would work with it? There are
obviously other ways the problem could be solved, but a simply wrapper is the
right approach initially?
Or am I barking up the wrong tree?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hannes Magnusson wrote:
I was asked to explain why I hadn't included ClassName->Method(); in the
list of ideas that solve the ambiguity problem. I added a brief sectionCan we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.The problem with that statement is that if it is used to ignore the other
problems, then at some point it may be necessary to re-write all the new
namespace code simply to allow additional features to be added!
tough luck. If it needs total rewrite in the future then it needs
total rewrite now to support the additional features anyway.
-Hannes
Hannes, Lester...
Can we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.The problem with that statement is that if it is used to ignore the other
problems, then at some point it may be necessary to re-write all the new
namespace code simply to allow additional features to be added!tough luck. If it needs total rewrite in the future then it needs
total rewrite now to support the additional features anyway.
That was my argument for the entire first half of this week. If either of
you had looked at Greg's latest idea, you'd know that it removes that
problem entirely.
Please go and look at his proposals at
http://wiki.php.net/rfc/namespaceissues, and then vote?
Thanks,
- Steph
I vote for option 3.
http://wiki.php.net/rfc/namespaceissues
Seems like the best fit all around.
Steph Fox wrote:
Hannes, Lester...
Can we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.The problem with that statement is that if it is used to ignore the
other
problems, then at some point it may be necessary to re-write all the
new
namespace code simply to allow additional features to be added!tough luck. If it needs total rewrite in the future then it needs
total rewrite now to support the additional features anyway.That was my argument for the entire first half of this week. If either
of you had looked at Greg's latest idea, you'd know that it removes
that problem entirely.Please go and look at his proposals at
http://wiki.php.net/rfc/namespaceissues, and then vote?Thanks,
- Steph
The thread where your vote has to go is:
[PHP-DEV] my last attempt at sanity with namespaces
started also by Gregory.
On Thu, Oct 16, 2008 at 5:30 PM, Justin Carlson justin.carlson@gmail.comwrote:
I vote for option 3.
http://wiki.php.net/rfc/namespaceissues
Seems like the best fit all around.
Steph Fox wrote:
Hannes, Lester...
Can we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.
The problem with that statement is that if it is used to ignore the
other
problems, then at some point it may be necessary to re-write all the new
namespace code simply to allow additional features to be added!tough luck. If it needs total rewrite in the future then it needs
total rewrite now to support the additional features anyway.That was my argument for the entire first half of this week. If either of
you had looked at Greg's latest idea, you'd know that it removes that
problem entirely.Please go and look at his proposals at
http://wiki.php.net/rfc/namespaceissues, and then vote?Thanks,
- Steph
--
--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
Hi!
The problem with that statement is that if it is used to ignore the
other problems, then at some point it may be necessary to re-write all
the new namespace code simply to allow additional features to be added!
So? We rewrote pretty much every other part of PHP - engine, object
model, filesystem, etc. - and nobody died. Suddently with this
particular feature there's tremendous fear of commitment. But we aren't
going anywhere by sitting and talking about "what if". We get anywhere
only by releasing features and seeing what they do.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
The problem with that statement is that if it is used to ignore the
other problems, then at some point it may be necessary to re-write all
the new namespace code simply to allow additional features to be added!So? We rewrote pretty much every other part of PHP - engine, object
model, filesystem, etc. - and nobody died. Suddently with this
particular feature there's tremendous fear of commitment. But we aren't
going anywhere by sitting and talking about "what if". We get anywhere
only by releasing features and seeing what they do.
My point is that for this code:
<?php
Classname::Method();
?>
The proposal does not solve the name conflict. If no one rewrites their
code to use Classname->Method(), then no one will be protected from the
ambiguity. I am thinking of the case where a user adds a new feature to
their existing code that uses a 3rd-party library with namespaced
functions that accidentally conflict with the user's classes without
their knowledge. As third-party libraries become easier to distribute
(which both phar and pyrus plan to do), this will become more of an issue.
Our experience with other changes forced upon existing code has shown
that user inertia is high, and we can't expect to fix things simply by
asking the users to rewrite their code unless PHP tells them to with
E_STRICT or other warnings.
Should I add this to the explanation or is it clear enough?
Greg
Hi!
My point is that for this code:
<?php
Classname::Method();
?>The proposal does not solve the name conflict. If no one rewrites their
Right, it does not. So doesn't yours - you need to modify the code in
both cases.
code to use Classname->Method(), then no one will be protected from the
ambiguity. I am thinking of the case where a user adds a new feature to
If nobody changes existing code then there's no ambiguity by definition.
If the code is changed, then of course one needs to change it in the
right way, there's no way around that - you always can think of some
wrong code that works, well, wrong.
their existing code that uses a 3rd-party library with namespaced
functions that accidentally conflict with the user's classes without
If you use 3rd party library that has same namespace as yours somebody
had screwed up here - either you used namespace that doesn't belong to
you or they used namespace that doesn't belong to them. In both cases
the fix is un-screw-up the naming.
their knowledge. As third-party libraries become easier to distribute
(which both phar and pyrus plan to do), this will become more of an issue.
Nobody should put their classes in PEAR namespace unless they are part
of PEAR library, thus this scenario - when somebody outside of PEAR has
conflict with PEAR functions/classes - is imaginary.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
My point is that for this code:
<?php
Classname::Method();
?>The proposal does not solve the name conflict. If no one rewrites their
Right, it does not. So doesn't yours - you need to modify the code in
both cases.
the solution I proposed emits anE_WARNINGon the conflict.
Greg
Hi!
<?php
Classname::Method();
?>The proposal does not solve the name conflict. If no one rewrites their
Right, it does not. So doesn't yours - you need to modify the code in
both cases.
the solution I proposed emits anE_WARNINGon the conflict.
You proposed a number of solutions, apparently. That's why I asked to
restrict the number of variants - even people who watch the discussion
can't be sure what we are talking about now. Do you propose to always
throw E_WARNING even if there was no actual conflict? Then I am against
it - in 99.9% of the code this warning would be useless and would only
annoy people. If you propose to throw warning only if actual conflict
exists - the question stays how do you know it exists.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Since this got cut without am answer I'll repeat it since I would still like
to know the answer!
Lester Caine wrote:
So 'USE' ?
I'm I understanding things right on this one that one would 'define' the
namespace in one sort of header file, and then add the use namespace to
those files that build on the basic definition? I'm looking in
particular here at a library like ADOdb, where 'adodb.inc.php' has a
number of global functions which are then used by the various drivers.
So 'adodb.inc.php' would define 'ADOdb' as a namespace and each driver
would
'use namespace ADOdb'This seems a good example to work with and is the reason that simply
dropping functions rang alarm bells with me. In fact it was the Date
stuff from ADOdb that caused so much trouble with 'Date' in earlier
releases so it seems appropriate to investigate how namespace would work
with it? There are obviously other ways the problem could be solved, but
a simply wrapper is the right approach initially?Or am I barking up the wrong tree?
If #3 is intended to work this way then it gets my vote.
Trying to apply namespace something substantial and understanding where the
code needs to be changed to work seems more logical than some of the academic
examples.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
Gregory Beaver wrote:
Hi again,
I was asked to explain why I hadn't included ClassName->Method(); in the
list of ideas that solve the ambiguity problem. I added a brief section
to the RFC that does so:http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work
What you wrote is incorrect - it does not require changing syntax
everywhere, but only in very rare cases where actual ambiguity exists.
Actual ambiguity would exist only when different people without any
communication between them or common design plan work on one namespace
(which should never happen, but we know our users, so we give them some
help even if they don't follow good practices). There's absolutely no
need to rewrite any existing code.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com