Jump to content


Photo

Flaw In Php's Namespace, Cannot Import An Entire Namespace,


  • Please log in to reply
37 replies to this topic

#21 Hall of Famer

Hall of Famer

    OOP Fanboi

  • Members
  • PipPipPip
  • 315 posts
  • LocationIthaca

Posted 27 December 2012 - 10:34 AM

If he answers my questions, then yes I will respond to his.

Welcome to the world of OOPHP! In a perfect script, everything is an object. You cannot be perfect, but you can approach as close as can.

zog841.jpg


#22 Jessica

Jessica

    This is not my name.

  • Gurus
  • 8,982 posts
  • LocationDallas, TX
  • Age:26

Posted 27 December 2012 - 11:12 AM

::) so you can't. It's okay.
My goal in replying to posts is to help you become a better programmer, including learning how to debug your own code and research problems. For that reason, rather than posting the solution, I reply with tips and hints on how to find the solution yourself. See below for useful links when you get stuck.

How to Get Good Help: How to Ask Questions | Don't be a help vampire
Debugging Your Code: Debugging your SQL | What does a php function do? | What does a term mean? | Don't see any errors?
Things You Should Do: Normalize Your Data | use print_r() or var_dump()
Lulz: "Functions should not have side effects." - trq

Please take a look at my new PHP/Web Dev blog: The Web Mason - Thanks!!

#23 Philip

Philip

    Phailip

  • Staff Alumni
  • 4,750 posts

Posted 27 December 2012 - 11:24 AM

Well ask Java's developers how they handle situations like this with their wildcard import.


From a SO comment.

The only problem with it is that it clutters your local namespace. For example, let's say that you're writing a Swing app, and so need java.awt.Event, and are also interfacing with the campany's calendaring system, which has com.mycompany.calendar.Event. If you import both using the wildcard method, one of two things happens:

  • You have an outright naming conflict between java.awt.Event andcom.mycompany.calendar.Event, and so you can't even compile
  • You actually manage only to import one (only one of your two imports does .*), but it's the wrong one, and you struggle to figure out why your code is claiming the type is wrong
  • In actuality, when you start your code, there is no com.mycompany.calendar.Event, but when they later add one, your previously valid code suddenly stops working (thanks to @Stanchfield for pointing that out)
The advantage of explicitly listing all imports is that I can tell at a glance which class you meant to use, which simply makes reading the code that much easier. If you're just doing a quick one-off thing, there's nothing explicitly wrong, but future maintainers will thank you for your clarity otherwise.




In the event you do have a conflict, you still have to list some of them out:
import java.sql.*;
import java.util.*;
import java.sql.Date;
More:
http://javadude.com/...mandisevil.html

#24 Hall of Famer

Hall of Famer

    OOP Fanboi

  • Members
  • PipPipPip
  • 315 posts
  • LocationIthaca

Posted 28 December 2012 - 12:03 PM

Yeah, there are ups and downs with wildcard import, I agree. But you have to understand that there are circumstances that you wont run into naming conflict while its more convenient to import an entire namespace. For instance, with PHP's built-in classes you want to use ArrayObject and Exception without having to add that backslash infront of their names. Another example is utility namespace package, in which all classes are used in the script. Like I pointed out before, there are always programmers who make mistakes, if they mistakenly import two namespaces that have naming conflict its their own problem. Just like newbies missing semicolons, there are always people who make this kind of errors, it cant be helped.

Edited by Hall of Famer, 28 December 2012 - 12:04 PM.

Welcome to the world of OOPHP! In a perfect script, everything is an object. You cannot be perfect, but you can approach as close as can.

zog841.jpg


#25 Philip

Philip

    Phailip

  • Staff Alumni
  • 4,750 posts

Posted 28 December 2012 - 12:05 PM

I won't disagree with you on ArrayObject / Exception, those should be auto-imported IMO.

Wildcard support could be added, but I likely would never use it.

#26 Hall of Famer

Hall of Famer

    OOP Fanboi

  • Members
  • PipPipPip
  • 315 posts
  • LocationIthaca

Posted 28 December 2012 - 01:42 PM

Thank for the support then. XD

Yeah, lets take a break from the general auto-import feature. Anyone here actually disagree that built-in classes should be auto-imported? I mean, dont you get tired of having to remind yourself of writing a backslash in front of the class names such as ArrayObject and Exception? Even if you dont think its a problem that many programmers end up getting errors for forgetting to put this backslash, its just way too inconvenient and ugly.

Edited by Hall of Famer, 28 December 2012 - 01:43 PM.

Welcome to the world of OOPHP! In a perfect script, everything is an object. You cannot be perfect, but you can approach as close as can.

zog841.jpg


#27 Maq

Maq

    Advanced Member

  • Moderators
  • 9,362 posts
  • LocationPennsylvania, USA

Posted 28 December 2012 - 03:19 PM

Use a decent IDE that automatically imports only the used classes, then .* is longer longer a concern.

tjmothy

ini_set ("display_errors", "1");
error_reporting(E_ALL);

#28 trq

trq

    Advanced Member

  • Administrators
  • 31,032 posts
  • LocationSydney, Australia.

Posted 28 December 2012 - 05:30 PM

Thank for the support then. XD

Yeah, lets take a break from the general auto-import feature. Anyone here actually disagree that built-in classes should be auto-imported? I mean, dont you get tired of having to remind yourself of writing a backslash in front of the class names such as ArrayObject and Exception? Even if you dont think its a problem that many programmers end up getting errors for forgetting to put this backslash, its just way too inconvenient and ugly.


It's just a non-issue IMO. Who really cares? It's one character and is part of the language. Learn to use it, and get on with things.

http://thorpesystems.com | http://proemframework.org | http://github.com/trq

SmtpCatcher - A very simple mock sendmail useful for testing PHP mail scripts.
OPM - My Linux package manager.


#29 Hall of Famer

Hall of Famer

    OOP Fanboi

  • Members
  • PipPipPip
  • 315 posts
  • LocationIthaca

Posted 29 December 2012 - 01:25 PM

It's just a non-issue IMO. Who really cares? It's one character and is part of the language. Learn to use it, and get on with things.


So we should get used to PHP being purely procedural and stop requesting for object oriented features back in the 90s, 'cause its 'part of the language'?

Welcome to the world of OOPHP! In a perfect script, everything is an object. You cannot be perfect, but you can approach as close as can.

zog841.jpg


#30 Andy-H

Andy-H

    Web developer

  • Members
  • PipPipPip
  • 2,007 posts
  • LocationManchester - UK
  • Age:22

Posted 29 December 2012 - 02:07 PM

I think autoloading makes this feature redundant, take kicken's example, is it really that much of a burden to have to type 5 more characters to make your code far more self-explanatory and easier to debug? Not to mention that you're only loading the classes that you actually use...

As for Exception and ArrayObject, couldn't you just:

use \Exception as Exception;
use \ArrayObject as ArrayObject;

I can't test this as I'm on my Dad's laptop which doesn't have PHP installed, but it should work?

No, you only have to write one line like this:

use \Model\User;

Then when you use those classes, do:
new User\Member
or 
new User\Admin


Are you a PHP Developer looking for work in Stockport? See http://forums.phpfre...oper-stockport/


#31 trq

trq

    Advanced Member

  • Administrators
  • 31,032 posts
  • LocationSydney, Australia.

Posted 29 December 2012 - 04:03 PM

So we should get used to PHP being purely procedural and stop requesting for object oriented features back in the 90s, 'cause its 'part of the language'?


It is comments like these that make your opinions less and less respectable.

http://thorpesystems.com | http://proemframework.org | http://github.com/trq

SmtpCatcher - A very simple mock sendmail useful for testing PHP mail scripts.
OPM - My Linux package manager.


#32 Hall of Famer

Hall of Famer

    OOP Fanboi

  • Members
  • PipPipPip
  • 315 posts
  • LocationIthaca

Posted 29 December 2012 - 05:50 PM

I think autoloading makes this feature redundant, take kicken's example, is it really that much of a burden to have to type 5 more characters to make your code far more self-explanatory and easier to debug? Not to mention that you're only loading the classes that you actually use...

As for Exception and ArrayObject, couldn't you just:

use \Exception as Exception;
use \ArrayObject as ArrayObject;

I can't test this as I'm on my Dad's laptop which doesn't have PHP installed, but it should work?

Yes it does work, but PHP has more than just Exception and ArrayObject in their built-in class library. Do you want to import them all manually? If so, write 20-30 lines of code that look completely the same in every script file.


It is comments like these that make your opinions less and less respectable.


How so? I see no difference between your post and mine. 'Its part of the language, PHP isnt Java/C#, you have to get used to it'. Gotta love this kind of quote.

Edited by Hall of Famer, 29 December 2012 - 05:54 PM.

Welcome to the world of OOPHP! In a perfect script, everything is an object. You cannot be perfect, but you can approach as close as can.

zog841.jpg


#33 trq

trq

    Advanced Member

  • Administrators
  • 31,032 posts
  • LocationSydney, Australia.

Posted 29 December 2012 - 05:58 PM

How so?



It illustrates a general lack of understanding.

http://thorpesystems.com | http://proemframework.org | http://github.com/trq

SmtpCatcher - A very simple mock sendmail useful for testing PHP mail scripts.
OPM - My Linux package manager.


#34 Hall of Famer

Hall of Famer

    OOP Fanboi

  • Members
  • PipPipPip
  • 315 posts
  • LocationIthaca

Posted 30 December 2012 - 11:46 AM

[/font][/color]

It illustrates a general lack of understanding.


Nope, not at all. It is the shallowness of your comment that triggered my reply. Yes, lets just stop developing PHP and make PHP 5.5 its final version already. Why keep requesting new features? Whatever we have now is part of the language, lets get used to it and get on with things.

Welcome to the world of OOPHP! In a perfect script, everything is an object. You cannot be perfect, but you can approach as close as can.

zog841.jpg


#35 KevinM1

KevinM1

    Snarkimus Prime

  • Moderators
  • 5,243 posts
  • LocationNew Hampshire, USA

Posted 30 December 2012 - 12:36 PM

Yes, lets just stop developing PHP and make PHP 5.5 its final version already. Why keep requesting new features?


Have you actually taken part in the development process? Or made RFCs? Because wishcasting here isn't 'developing PHP' nor is it officially requesting new features. We're not tied to Zend. That's why we're generally amused/bemused at your quest to make PHP better. Writing posts here isn't actually accomplishing any of that.

#36 Hall of Famer

Hall of Famer

    OOP Fanboi

  • Members
  • PipPipPip
  • 315 posts
  • LocationIthaca

Posted 31 December 2012 - 05:39 AM

Of course I am not expecting people from this forum to engage in PHP's development process. Its a board where everyone can freely speak his opinion, and I have a point to discuss about PHP's lacking features that need to be improved. Its a matter of point, not a request to make something happen.

Welcome to the world of OOPHP! In a perfect script, everything is an object. You cannot be perfect, but you can approach as close as can.

zog841.jpg


#37 KevinM1

KevinM1

    Snarkimus Prime

  • Moderators
  • 5,243 posts
  • LocationNew Hampshire, USA

Posted 31 December 2012 - 10:50 AM

Which is fine, and believe me, we don't want to stifle discussion. It's just that, after having the same discussion over and over, we tend to get a bit annoyed with how masturbatory it all is. I mean, if you put in the same effort and passion that you put into your posts here in a RFC, you might actually be able to steer PHP in the direction you want. Which is pretty cool.

I dunno... it seems like if this is the part that you're most passionate about (and, looking at your post history, it seems like it), then why not harness that passion into something tangible? Why waste time trying to convince us when you can actually convince the powers that be?

Again, not saying that you can't, or don't have the right to talk about it here. Just pointing out that you can actually have a hand in the changes you want to see materialize, if you so choose. That's the beauty of open source. You don't need to be on the sidelines.

#38 salathe

salathe

    Badger

  • Staff Alumni
  • 1,859 posts
  • LocationEdinburgh, Scotland

Posted 31 December 2012 - 03:37 PM

Before allowing anything like wildcards or "importing" entire namespaces, I'd like to see namespaces implemented more as black boxes (e.g. namespace-scoped variables and such like).  Currently they are essentially used as class/function/constant name aliases.
PHP Documentation Team




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Cheap Linux VPS from $5
SSD Storage, 30 day Guarantee
1 TB of BW, 100% Network Uptime

AlphaBit.com