Hi,
I just wanted a clarification on this. Currently many of us have class names such as:
Zend_Validate_Interface
Foo_Utils_Array
...and so on. This works fine as it's just a single T_STRING.
As you know, with the new convention, the parser will not encounter T_STRING "Zend\Validate\Interface" but rather:
T_STRING "Zend"
T_NS_SEPARATOR ""
T_STRING "Validate"
T_NS_SEPARATOR ""
T_INTERFACE <-- parse error
I understand it's not trivial to fix this, but I wanted a clarification: is there a plan to do something about it, or it'll remain an invalid syntax by the time of release of 5.3.
Regards,
Stan Vassilev
On Wednesday 05 November 2008 9:24:15 pm Stan Vassilev | FM wrote:
Hi,
I just wanted a clarification on this. Currently many of us have class
names such as:Zend_Validate_Interface
Foo_Utils_Array...and so on. This works fine as it's just a single T_STRING.
As you know, with the new convention, the parser will not encounter
T_STRING"Zend\Validate\Interface" but rather:
T_STRING"Zend"
T_NS_SEPARATOR""
T_STRING"Validate"
T_NS_SEPARATOR""
T_INTERFACE<-- parse errorI understand it's not trivial to fix this, but I wanted a clarification: is
there a plan to do something about it, or it'll remain an invalid syntax by
the time of release of 5.3.Regards,
Stan Vassilev
Since I don't see why anyone would want to map the name that directly in the
first place, I don't see anything here to fix. In that example, if you
imported Zend\Validate\Interface you would then have to use it as:
class Bob implements Interface { }
Which is of course wrong on many levels. I'd file this under "if it breaks
when you do that, don't do that". :-)
--
Larry Garfield
larry@garfieldtech.com
What if you want to provide a set of helper/wrapper classes, appropriately
namespaced, something along the lines of:
MyFramework\Helpers\Array
MyFramework\Helpers\Database
MyFramework\Helpers\Session
etc.
If I want to use that naming convention, I don't want to have to name some
of my classes differently just because PHP can't deal with it. It may not be
trivial to fix, but to the end-developer, it's a trivial problem and it's
something that should just work.
Dan
On Thu, Nov 6, 2008 at 3:54 AM, Larry Garfield larry@garfieldtech.comwrote:
On Wednesday 05 November 2008 9:24:15 pm Stan Vassilev | FM wrote:
Hi,
I just wanted a clarification on this. Currently many of us have class
names such as:Zend_Validate_Interface
Foo_Utils_Array...and so on. This works fine as it's just a single T_STRING.
As you know, with the new convention, the parser will not encounter
T_STRING"Zend\Validate\Interface" but rather:
T_STRING"Zend"
T_NS_SEPARATOR""
T_STRING"Validate"
T_NS_SEPARATOR""
T_INTERFACE<-- parse errorI understand it's not trivial to fix this, but I wanted a clarification:
is
there a plan to do something about it, or it'll remain an invalid syntax
by
the time of release of 5.3.Regards,
Stan VassilevSince I don't see why anyone would want to map the name that directly in
the
first place, I don't see anything here to fix. In that example, if you
imported Zend\Validate\Interface you would then have to use it as:class Bob implements Interface { }
Which is of course wrong on many levels. I'd file this under "if it breaks
when you do that, don't do that". :-)--
Larry Garfield
larry@garfieldtech.com
What if you want to provide a set of helper/wrapper classes, appropriately
namespaced, something along the lines of:
MyFramework\Helpers\Array
MyFramework\Helpers\Database
MyFramework\Helpers\Session
etc.If I want to use that naming convention, I don't want to have to name some
of my classes differently just because PHP can't deal with it. It may not be
trivial to fix, but to the end-developer, it's a trivial problem and it's
something that should just work.
I think the point is the same as with Zend_Validate_Interface ; While
MyFramework\Helpers is a fair namespace, Array is a bad classname. You
should use something like MyFramework\Helpers\ArrayHelper
FWIW Zend_Validate_Interface looks odd to me today already, for that
reason exactly. I read two namespaces and a classname, and that
classname doesn't make much sense.
--
troels
Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to suffix
the class name with 'Helper' to reconfirm that, just because the PHP engine
doesn't like it.
Dan
On Thu, Nov 6, 2008 at 9:50 AM, troels knak-nielsen troelskn@gmail.comwrote:
What if you want to provide a set of helper/wrapper classes,
appropriately
namespaced, something along the lines of:
MyFramework\Helpers\Array
MyFramework\Helpers\Database
MyFramework\Helpers\Session
etc.If I want to use that naming convention, I don't want to have to name
some
of my classes differently just because PHP can't deal with it. It may not
be
trivial to fix, but to the end-developer, it's a trivial problem and it's
something that should just work.I think the point is the same as with Zend_Validate_Interface ; While
MyFramework\Helpers is a fair namespace, Array is a bad classname. You
should use something like MyFramework\Helpers\ArrayHelperFWIW Zend_Validate_Interface looks odd to me today already, for that
reason exactly. I read two namespaces and a classname, and that
classname doesn't make much sense.--
troels
Hi Dan,
Am 06.11.2008 um 11:03 schrieb Dan:
Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer
that it's
a Helper for Arrays in the MyFramework framework. I shouldn't need
to suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.
we also had lots of classes like "F3\MVC\Controller\Interface",
"F3\MVC\Controller\Default" etc. ("default" is also a reserved word
unfortunately).
So we had to rename all these classes and interfaces.
After doing that though, I think it's much better this way. IMO a
class name should
speak for itself even without namespaces, the namespaces should only
put into a
certain context:
"DefaultController" is a default controller.
"F3\FooPackage\Controller\DefaultController" is the default controller
of the FooPackage,
"F3\BarPackage\Controller\DefaultController" is the default controller
of the BarPackage etc.
So, even though I was annoyed having to refactor so much code, I am
now happy with
the results.
Cheers,
robert
Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.
This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er...
- Steph
This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er...
+1
my favourite example:
"class class extends namespace implements interface"
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.
"This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er..."
I think you might be deliberately missing Dan's point here: array is a
reserved word because it is not namespaced. If the PHP native function
array() was namespaced to PHPCore\array() then Dan could create a class or
function called array under his own namespace. This is exactly what
namespacing affords us.
array() is only a reserved word because it is not a directly accessable
native datatype. If array() was an object Array, this wouldn't be a problem.
This namespaces issues highlights the very fundamental issues with PHP, and
glib, childish responses like yours only serve to score points.
Grow up and join the conversation.
Ben Davies | Lead Developer | Stickyeyes
6th Floor,
West One,
Wellington Street,
Leeds, LS1 1BA
Email: ben@stickyeyes.com
0113 391 2929 | <telephone> | Fax 0113 391 2939
This e-mail may contain information that is privileged, confidential or
otherwise protected from disclosure. It must not be used by, or its contents
copied or disclosed to persons other than the intended recipient. Any
liability (in negligence or otherwise) arising from any third party acting,
or refraining from acting, on any information contained in this e-mail is
excluded. The views expressed may not be official company policy, but
instead, the personal views of the originator. If you have received this
e-mail in error please notify the sender and delete the e-mail.
-----Original Message-----
From: Steph Fox [mailto:steph@php.net]
Sent: 06 November 2008 11:01
To: Dan; troels knak-nielsen
Cc: Larry Garfield; internals@lists.php.net; ben@stickyeyes.com
Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not?
Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.
This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er...
- Steph
Quite.
It does appear as though, as a group, that you're struggling with the entire
concept of namespaces. As demonstrated by this discussion, the resolution
issues, the separator farce, and so on.
It may be due to weaknesses in the PHP engine as a whole, I don't know...
but it strikes me that most of these issues should be trivial ones, or ones
that could be eliminated simply by approaching language design decisions
with some common sense.
In .NET, I can stick an Array class into my own namespace, extending the
System.Array type if I want to and use it in my code without issue. Why can
I not do that here? Is it simply that you're so worried about backwards
compatibility that you feel that you can't make the necessary changes to the
language to implement something fully?
Dan
Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it."This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er..."I think you might be deliberately missing Dan's point here: array is a
reserved word because it is not namespaced. If the PHP native function
array() was namespaced to PHPCore\array() then Dan could create a class or
function called array under his own namespace. This is exactly what
namespacing affords us.array() is only a reserved word because it is not a directly accessable
native datatype. If array() was an object Array, this wouldn't be a
problem.This namespaces issues highlights the very fundamental issues with PHP, and
glib, childish responses like yours only serve to score points.Grow up and join the conversation.
Ben Davies | Lead Developer | Stickyeyes
6th Floor,
West One,
Wellington Street,
Leeds, LS1 1BA
Email: ben@stickyeyes.com
0113 391 2929 | <telephone> | Fax 0113 391 2939This e-mail may contain information that is privileged, confidential or
otherwise protected from disclosure. It must not be used by, or its
contents
copied or disclosed to persons other than the intended recipient. Any
liability (in negligence or otherwise) arising from any third party acting,
or refraining from acting, on any information contained in this e-mail is
excluded. The views expressed may not be official company policy, but
instead, the personal views of the originator. If you have received this
e-mail in error please notify the sender and delete the e-mail.-----Original Message-----
From: Steph Fox [mailto:steph@php.net]
Sent: 06 November 2008 11:01
To: Dan; troels knak-nielsen
Cc: Larry Garfield; internals@lists.php.net; ben@stickyeyes.com
Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not?Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er...
- Steph
In .NET, I can stick an Array class into my own namespace, extending the
System.Array type if I want to and use it in my code without issue. Why
can
I not do that here? Is it simply that you're so worried about backwards
compatibility that you feel that you can't make the necessary changes to
the
language to implement something fully?
.NET is an object oriented language. It has something called System.Array.
PHP is a hybrid language. It does not and hopefully never will have
something called System.Array.
It's like the difference between English and Esperanto... and you're telling
us 'cough' should rhyme with 'cow' because that's how Esperanto would have
it. But English is so much easier to learn, if more difficult to master,
that it's become the lingua franca for the 'net.
- Steph
Dan
On Thu, Nov 6, 2008 at 11:43 AM, Ben Davies bdavies@stickyeyes.com
wrote:Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it."This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er..."I think you might be deliberately missing Dan's point here: array is a
reserved word because it is not namespaced. If the PHP native function
array() was namespaced to PHPCore\array() then Dan could create a class
or
function called array under his own namespace. This is exactly what
namespacing affords us.array() is only a reserved word because it is not a directly accessable
native datatype. If array() was an object Array, this wouldn't be a
problem.This namespaces issues highlights the very fundamental issues with PHP,
and
glib, childish responses like yours only serve to score points.Grow up and join the conversation.
Ben Davies | Lead Developer | Stickyeyes
6th Floor,
West One,
Wellington Street,
Leeds, LS1 1BA
Email: ben@stickyeyes.com
0113 391 2929 | <telephone> | Fax 0113 391 2939This e-mail may contain information that is privileged, confidential or
otherwise protected from disclosure. It must not be used by, or its
contents
copied or disclosed to persons other than the intended recipient. Any
liability (in negligence or otherwise) arising from any third party
acting,
or refraining from acting, on any information contained in this e-mail is
excluded. The views expressed may not be official company policy, but
instead, the personal views of the originator. If you have received this
e-mail in error please notify the sender and delete the e-mail.-----Original Message-----
From: Steph Fox [mailto:steph@php.net]
Sent: 06 November 2008 11:01
To: Dan; troels knak-nielsen
Cc: Larry Garfield; internals@lists.php.net; ben@stickyeyes.com
Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not?Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er...
- Steph
Okay, I'm not going to sit and argue it... but to anyone looking at these
issues from outside the PHP internals world (like I am), that argument is
worthy of ridicule.
PHP may be a hybrid language, but the fact is you're implementing object
oriented functionality, and as such should be implementing it in a way that
follows de-facto standards in object oriented language design. I should be
able to overload your internal array object, and yes, arraysshould be
objects.
Javascript would be a prime example of a non-standard object oriented
approach, and yet that still manages to support the basics in a way that
make sense.
Dan
In .NET, I can stick an Array class into my own namespace, extending the
System.Array type if I want to and use it in my code without issue. Why
can
I not do that here? Is it simply that you're so worried about backwards
compatibility that you feel that you can't make the necessary changes to
the
language to implement something fully?.NET is an object oriented language. It has something called System.Array.
PHP is a hybrid language. It does not and hopefully never will have
something called System.Array.It's like the difference between English and Esperanto... and you're
telling us 'cough' should rhyme with 'cow' because that's how Esperanto
would have it. But English is so much easier to learn, if more difficult to
master, that it's become the lingua franca for the 'net.
- Steph
Dan
On Thu, Nov 6, 2008 at 11:43 AM, Ben Davies bdavies@stickyeyes.com
wrote:Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it."This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er..."I think you might be deliberately missing Dan's point here: array is a
reserved word because it is not namespaced. If the PHP native function
array() was namespaced to PHPCore\array() then Dan could create a class
or
function called array under his own namespace. This is exactly what
namespacing affords us.array() is only a reserved word because it is not a directly accessable
native datatype. If array() was an object Array, this wouldn't be a
problem.This namespaces issues highlights the very fundamental issues with PHP,
and
glib, childish responses like yours only serve to score points.Grow up and join the conversation.
Ben Davies | Lead Developer | Stickyeyes
6th Floor,
West One,
Wellington Street,
Leeds, LS1 1BA
Email: ben@stickyeyes.com
0113 391 2929 | <telephone> | Fax 0113 391 2939This e-mail may contain information that is privileged, confidential or
otherwise protected from disclosure. It must not be used by, or its
contents
copied or disclosed to persons other than the intended recipient. Any
liability (in negligence or otherwise) arising from any third party
acting,
or refraining from acting, on any information contained in this e-mail is
excluded. The views expressed may not be official company policy, but
instead, the personal views of the originator. If you have received this
e-mail in error please notify the sender and delete the e-mail.-----Original Message-----
From: Steph Fox [mailto:steph@php.net]
Sent: 06 November 2008 11:01
To: Dan; troels knak-nielsen
Cc: Larry Garfield; internals@lists.php.net; ben@stickyeyes.com
Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not?Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er...
- Steph
Dan,
PHP may be a hybrid language, but the fact is you're implementing object
oriented functionality, and as such should be implementing it in a way
that
follows de-facto standards in object oriented language design. I should be
able to overload your internal array object, and yes, arraysshould be
objects.
I'm really confused as to why you'd want to overload something that doesn't
exist. Can't we just deal with reality here?
Several million PHP scripts written over the last decade will still able to
run without change under PHP 5.3. Several PHP developers are not OO
programmers and some - maybe even most - never will be. Don't you think that
suddenly turning arrays into objects might cause just the teeniest bit of a
problem here?
Javascript would be a prime example of a non-standard object oriented
approach, and yet that still manages to support the basics in a way that
make sense.
Great, so drop PHP and go use Javascript. Oh wait - you can't. Because it
wasn't designed do the same job.
- Steph
Okay, I'm not going to sit and argue it... but to anyone looking at these
issues from outside the PHP internals world (like I am), that argument is
worthy of ridicule.
What argument? Due to top-posting you're kind of killing the ability
to follow the thread.
PHP may be a hybrid language, but the fact is you're implementing object
oriented functionality, and as such should be implementing it in a way that
follows de-facto standards in object oriented language design. I should be
able to overload your internal array object, and yes, arraysshould be
objects.
Wouldn't this mean that also primitive types such as integer and
string should be objects? Doing something like this would break about
all the code out there without a major gain.
One of the strenghts of PHP is that it balances well between
procedural and object oriented approaches. There is ArrayObject,
ArrayAccess etc for people who wish to use OO and array for the people
who don't.
Javascript would be a prime example of a non-standard object oriented
approach, and yet that still manages to support the basics in a way that
make sense.
I think you are missing a point here. PHP is not Javascript or .NET.
--
Mikko Koppanen
PHP may be a hybrid language, but the fact is you're implementing object
oriented functionality, and as such should be implementing it in a way that
follows de-facto standards in object oriented language design. I should be
able to overload your internal array object, and yes, arraysshould be
objects.
Why should all arrays be objects? Because that's the way Java and
.NET do it? Should PHP then take it one step further and adopt the OO
model where all primitive data types become objects as well, so you can
overload an Int, Char, or Float? That seems to be the logical extension
of your argument, and not only is it incompatible with PHP's hybrid
nature, it'd be a downside for adoption of the language as a whole. One
of the reasons PHP has the penetration that it does is that it has a
very low barrier to entry, you don't need to be an OO programmer, or
even know what object oriented programming is, to write effective,
efficient PHP scripts and applications that solve a task for you.
If you want to use an Array object, there's one available in the SPL,
ArrayObject. Breaking everyone's code in the name of blind obedience to
principles of object oriented programming seems silly, to say the least,
especially when there's an option already available within PHP that
allows you to use OO-Arrays.
Yes, it will be mildly irritating for people who have classes named
things like MyHelperInterface, who then break it out into
My\Helper\Interface . Of course, they could solve those problems by
breaking it out into My\HelperInterface or My\Helpers\HelperInterface
(or InterfaceHelper), and to say that that minor renaming of a class
invalidates the usefulness of PHP namespaces is like saying that
removing the ability to have a function named public() post-PHP4 (or
whenever public became a reserved word) invalidates PHP's OO usefulness.
No solution to namespacing will be all things to all people. Lots of
people don't like the use of \ as opposed to :: (I'm one of them,
although I am convinced by the arguments the \ people have put forward
that it's necessary), but do their objections render PHP namespacing
useless? Does the lack of multiple inheritance support render PHP's OO
useless? No, of course not. It's all a compromise between (sometimes)
competing desires to develop the language in a way that is most useful
to most people.
Matt
In .NET, I can stick an Array class into my own namespace, extending the
System.Array type if I want to and use it in my code without issue. Why
can
I not do that here? Is it simply that you're so worried about backwards
compatibility that you feel that you can't make the necessary changes to
the
language to implement something fully?.NET is an object oriented language. It has something called System.Array.
PHP is a hybrid language. It does not and hopefully never will have
something called System.Array.It's like the difference between English and Esperanto... and you're
telling us 'cough' should rhyme with 'cow' because that's how Esperanto
would have it. But English is so much easier to learn, if more difficult to
master, that it's become the lingua franca for the 'net.
- Steph
Dan
On Thu, Nov 6, 2008 at 11:43 AM, Ben Davies bdavies@stickyeyes.com
wrote:Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.
"This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er..."I think you might be deliberately missing Dan's point here: array is a
reserved word because it is not namespaced. If the PHP native function
array() was namespaced to PHPCore\array() then Dan could create a class
or
function called array under his own namespace. This is exactly what
namespacing affords us.array() is only a reserved word because it is not a directly accessable
native datatype. If array() was an object Array, this wouldn't be a
problem.This namespaces issues highlights the very fundamental issues with PHP,
and
glib, childish responses like yours only serve to score points.Grow up and join the conversation.
Ben Davies | Lead Developer | Stickyeyes
6th Floor,
West One,
Wellington Street,
Leeds, LS1 1BA
Email: ben@stickyeyes.com
0113 391 2929 | <telephone> | Fax 0113 391 2939This e-mail may contain information that is privileged, confidential or
otherwise protected from disclosure. It must not be used by, or its
contents
copied or disclosed to persons other than the intended recipient. Any
liability (in negligence or otherwise) arising from any third party
acting,
or refraining from acting, on any information contained in this e-mail is
excluded. The views expressed may not be official company policy, but
instead, the personal views of the originator. If you have received this
e-mail in error please notify the sender and delete the e-mail.-----Original Message-----
From: Steph Fox [mailto:steph@php.net]
Sent: 06 November 2008 11:01
To: Dan; troels knak-nielsen
Cc: Larry Garfield; internals@lists.php.net; ben@stickyeyes.com
Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not?Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class name with 'Helper' to reconfirm that, just because the PHP
engine
doesn't like it.
This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the question
would be so obvious that there would be no thread... oo-er...
- Steph
--
Matt Schiros
Hi,
Watching my thread devolve into a blamefest wasn't the intention. I just
wanted a clear answer if something's done about it or not.
To everyone participating in the thread: guys it's NOT trivial in the
current situation. To the parser, a separate string matching a keyword is
the token keyword.
Reverting this or making it context sensitive is not trivial by any means.
Still though: it IS possible, you'll find plenty of examples of
context-specific keywords in other languages (including C# which was quoted
here).
Oh and btw, greg, in your example: you should print "1".
There's one trivial solution: make the keywords and class names
case-sensitive. Then classes "If", "Array", "Interface" will never class
with the all-lowercase keywords. I have to say, we sorely do need
consistency on that front as well, and since vars are already case
sensitive, making it all case sensitive is one way to go forward.
Why is this a problem at all? Well as people said, in .NET words like
"array" are not a reserrved word.
Even more, if I have Foo.Utils.FooUtils, that's some redundancy I can easily
avoid in .NET by "using Foo.Utils.*". In PHP, we can't do star-imports since
the parser doesn't know what's there to import at runtime. So we can't
easily avoid the redundancy, unless we manually import the classes we want
to use, one by one.
So that's one more hassle which make redundant names a pain.
Regards,
Stan Vassilev
2008/11/6 Stan Vassilev | FM sv_forums@fmethod.com:
There's one trivial solution: make the keywords and class names
case-sensitive. Then classes "If", "Array", "Interface" will never class
with the all-lowercase keywords.
As much as I'd love to see more case-sensitivity, I'm afraid it would
break quite a lot of existing apps, according to Google Code.
http://www.google.com/codesearch?q=lang%3Aphp+%3D%5Cs%2AArray
-JD
Dan wrote:
Quite.
It does appear as though, as a group, that you're struggling with the entire
concept of namespaces. As demonstrated by this discussion, the resolution
issues, the separator farce, and so on.It may be due to weaknesses in the PHP engine as a whole, I don't know...
but it strikes me that most of these issues should be trivial ones, or ones
that could be eliminated simply by approaching language design decisions
with some common sense.In .NET, I can stick an Array class into my own namespace, extending the
System.Array type if I want to and use it in my code without issue. Why can
I not do that here? Is it simply that you're so worried about backwards
compatibility that you feel that you can't make the necessary changes to the
language to implement something fully?
Hi Dan,
OSS = show us a working patch and we'll consider it. Do this before
saying the issues "should be trivial ones."
Not too long ago I spent a significant amount of time trying to make it
possible to use a few reserved words as method names or function names,
and the result was a patch that made the parser and lexer significantly
more complex, with lots of bugs that were very difficult to fix, and
some edge cases where parsing simply failed.
As an example of why your suggestion is not logically possible to
implement, what should the following code print, 1 or 2?
<?php
namespace namespace\namespace;
function test(){echo "1\n";}
namespace namespace;
function test(){echo "2\n";}
echo namespace\test();
?>
No human can tell whether you mean to call the
namespace\namespace\test() function, or simply to call the test()
function from the current namespace. Do you really expect a machine to
do any better?
Please spend at least 2 minutes carefully trying to think of an edge
case before lamenting any feature in the language, otherwise your posts
kill your credibility on the list and are frankly nothing other than
annoying noise.
Greg
This namespaces issues highlights the very fundamental issues with PHP, and
glib, childish responses like yours only serve to score points.
The 'very fundamental issue' here is that you're expecting namespaces to
allow things that are not legal in non-namespaced PHP code. The entire
thrust of the internals discussion preceding this has been that preserving
similar resolution rules in namespaced PHP code to those that already exist,
will avoid potential confusion.
And don't tell me to 'grow up' or I'll set my grandchildren on you ;)
- Steph
Ben Davies | Lead Developer | Stickyeyes
-----Original Message-----
From: Steph Fox [mailto:steph@php.net]
Sent: 06 November 2008 11:59
To: Ben Davies; 'Dan'; 'troels knak-nielsen'
Cc: 'Larry Garfield'; internals@lists.php.net
Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not?
This namespaces issues highlights the very fundamental issues with PHP, and
glib, childish responses like yours only serve to score points.
The 'very fundamental issue' here is that you're expecting namespaces to
allow things that are not legal in non-namespaced PHP code. The entire
thrust of the internals discussion preceding this has been that preserving
similar resolution rules in namespaced PHP code to those that already exist,
will avoid potential confusion.
And don't tell me to 'grow up' or I'll set my grandchildren on you ;)
- Steph
Hi.
Steph Fox wrote:
This thread really should be re-titled to "allow reserved words as a
classname or not". Then perhaps the only logical response to the
question would be so obvious that there would be no thread... oo-er...
Right, the subject indicates a different question that what seems to be
discusssed here.
The way I understood it was about allowing methods named "clone" in a
class. That would come in handy for me, porting interfaces from Java to
PHP. Currently I have to go back to "klone" to make it legal.
Regards,
Karsten
Hi!
As you know, with the new convention, the parser will not encounter
T_STRING"Zend\Validate\Interface" but rather:
With namespaces, class name would not be Zend\Validate\Interface. Having
namespaces, it would make much more sense to make last component a
descriptive name, so you won't have code like this:
if($object instanceof Interface) { // wtf am I checking here?
...
As for how exactly that descriptive name should look - I guess each
framework's developers that plan to support namespaces think about it
hard right now. I know ZF developers do :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
As you know, with the new convention, the parser will not encounter
T_STRING"Zend\Validate\Interface" but rather:With namespaces, class name would not be Zend\Validate\Interface. Having
namespaces, it would make much more sense to make last component a
descriptive name, so you won't have code like this:if($object instanceof Interface) { // wtf am I checking here?
...As for how exactly that descriptive name should look - I guess each
framework's developers that plan to support namespaces think about it hard
right now. I know ZF developers do :)
Hi,
Fully agreed. Though since we (PHP users) will all be using namespaces
together, it makes much more sense that we have a paradigm, recommendation
for namespace usage that all frameworks will follow.
Maybe the ZF, Agavi, CI, CakePHP etc. authors should get together and craft
a single recommendation list for people to use.
It's not just a matter of consistency, it's a matter of makming the language
work well with the recommended scenario and use patterns of namespaces.
Two things are obvious:
-
What worked with underscores won't work with namespaces.
-
What scenario above with "instanceof Interface" isn't very likely. Why?
Well imagine you want to use 5 classes in namespace foo\bar, called A, B, C,
D, E (ex. foo\bar\A). In most any language with packaging system, to flatten
the space you simply do this:
use foo\bar*;
$a = new A();
$b = new B();
...
In PHP, due to lack of packaging system and knowledge of the user resources
at parse time, instead we're painfully explicit:
use foo\bar\A;
use foo\bar\B;
use foo\bar\C;
use foo\bar\D;
use foo\bar\E;
$a = new A();
$b = new B();
Which makes this usage pattern with aliases much more likely to see:
use foo\bar as fb;
$a = new fb\A();
$b = new fb\B();
So your example above would rather be:
use Zend\Validate as ZV;
... instanceof ZV\Interface;
And this is why it's worth it to arrive at a single list of recommendations
for namespace usage, and see what works there and what might not work, and
tweak the language for it.
Regards,
Stan Vassilev
Stan Vassilev | FM wrote:
use foo\bar*;
$a = new A();
$b = new B();
...
I may be asking this question out of ignorance, but here goes:
What is the difference between the following snippets?
// global.php
use \foo\bar*;
$a = new A();
$b = new B();
// namespaced.php
namespace \foo\bar;
$a = new A();
$b = new B();
I don't understand why in the namespaced example no one seems to have a
problem with new A() meaning new \foo\bar\A(), but we can't use the *
wildcard to do the same thing?
--
Joshua Thompson
Mechanical Engineer/Software Developer
http://www.schmalls.com
I don't understand why in the namespaced example no one seems to have a
problem with new A() meaning new \foo\bar\A(), but we can't use the *
wildcard to do the same thing?
Since we don't reliable know all possible classes, think about
_-autoloading classes, which means we'd have to do more work during
execution, which can be a slowdown.
johannes