SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 79
  1. #1
    SitePoint Enthusiast
    Join Date
    Nov 2004
    Location
    Canberra, Australia
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Namespaces cannot come soon enough to PHP

    I wonder who was the bright spark that decided to add a class named "date" to the core PHP 5.1 distribution? I mean really, that must break a hell of a lot of stuff out there... hence the reason for the rather swift 5.1.1 release I suppose. Plus the notion of the SPL concerns me also, I mean, PHP does need some standards, but with each addition they cause potential for further name clashes, especially for those of us that do heavy OO with PHP. :\

  2. #2
    SitePoint Member
    Join Date
    Nov 2005
    Location
    Arnhem, The Netherlands
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    From what I heard, it was Derick Rethans himself who 'secretly' pushed the date-class into a RC version...

    Looks like a mess in php-dev-camp if you ask me...

    First priority: Get the team work like a team again.
    Second priority: Get namespaces.

    Well if it was up to me at least :P

  3. #3
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JointFillah
    From what I heard, it was Derick Rethans himself who 'secretly' pushed the date-class into a RC version...
    Seems like that Derick guy has been doing quite a lot of harm to the core team, I'd say. An overblown ego problems?

  4. #4
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A lot of good too if you look at the commits he has made, the docs he contributed and so on. He may be maverick sometimes but look at some of the ways others act. Pierre is basically on a witch hunt and is going around calling several devs (not just Derick) liars. Basically, this is dirty laundry being aired in a public forum. Sometimes mistakes are made during the development process and typically that means the process isn't good enough not that one or another developer is a bad egg. I hope we don't start pointing fingers.

  5. #5
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    naperville
    Posts
    189
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  6. #6
    SitePoint Enthusiast
    Join Date
    Nov 2004
    Location
    Canberra, Australia
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > I move that the class is renamed for the time being as to not
    > conflict with existing codebases, and release 5.1.1
    > expediently.

    Yes, and that will break code again as I just explained to Sebastian
    Kettler. And it will break *my* code ;-)

    Derick
    > Using generic names for core functionality in the global name space is a bad
    > thing, no matter how convenient the name might be. That's a lesson PHP has
    > learned for function names quite a while ago, let's not repeat the same
    > mistake for class names.

    No no, the core reserves the right to name whatever they want, it's the
    userland code that is responsible for prefixing their classes.

    Derick

  7. #7
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    {RainmakeR} you are stirring the pot -- and for what? What will come of this (or what we can hope will come of this) is a better development/release process as well as a defined standard for introducing symbols into the namespace both from core and perhaps even userland. As you noted, this whole mess is largely the result of OOP without the lack of namespaces/modules/packages or what-have-you. Fairly much all of the procedural stuff was appropriately prefixed.

    In other words, because a very important feature wasn't included, clashes like this were inevitable and we shouldn't be ready to pounce on the first dev that crossed the line (nor was Derick first -- Marcus did plenty with SPL before he was made to prefix it during the RC build of 5.1) So can we please avoid having another round of flaming PHP devs on this forum?

  8. #8
    SitePoint Enthusiast
    Join Date
    Nov 2004
    Location
    Canberra, Australia
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sorry, pot stirring was not my intention, and I agree that good can come of mistakes like this in terms of namespace development and such. I guess it's part of PHP's growing pains but there have just been so many occasions lately where this sort of thing is happening. I mean, I've committed to developing in PHP now for several years, this is where the core of my coding experience lies, so I care about the direction it takes. What annoys me and many others I'm sure is when certain members of the core PHP team act recklessly and seem to make changes willy nilly as they see fit, seemingly with a complete disregard for PHP userland. Then when asked to explain their actions the typical response is "I did this for me, I am right, you are wrong, change your code". Each time something like this happens it only pushes me more and more towards considering something else, perhaps Ruby. Some of the core devs really need to tone down their arrogance and start considering how they are impacting the development community.

  9. #9
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by jayboots
    So can we please avoid having another round of flaming PHP devs on this forum?
    Free speech means that you will hear things that you don't like. It's a good thing.

    Regarding the comment that everyone else has to add namespaces...yer what? Almost every langauge makes an effort not to pollute the namespaces once the core libraries have been defined. These things need long periods of deprecation to allow enterprise code to catch up. Look at "assert" in Java breaking JUnit for the kind of trouble it causes. C++ created the "std" namespace as soon as it had namespaces just avoid polluting "userland" (that name says it all). As the application code sits on the top of the stack, it should be free to call things by whatever it wants. And Date is likely to be a domain term.

    This is not a simple popularity contest, where if someone makes three positive contributions the dodgy one is declared good. It's still a dodgy decision. Anything that breaks backward compatibility is potentially very bad and has to have careful consideration placed behind it. Anything else is cavalier.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  10. #10
    SitePoint Member
    Join Date
    Sep 2005
    Posts
    22
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yet another example of how PHP is not ready for enterprise?

    And I'm talking about developer attitude here, not namespaces.

  11. #11
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Free speech means that you will hear things that you don't like. It's a good thing.
    Hi. Just to be clear, I didn't say don't express your opinion -- I just hope that everyone will remember to keep decorum and so refrain from pointing fingers and flaming people. Surely you've seen some of the similar threads on this very forum that sparked such behaviour, particularly against the php devs. It is one thing to talk about process (or lack thereof) and how it impacts things, it is quite another to single out someone -- who isn't even here to defend themself. BTW, I didn't say that flaming has happened here in this thread so far; I am saying that this thread has the possiblity of leading towards that direction and I for one would see it as a pity if it did.

    Best Regards.

  12. #12
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    An overblown ego problems?
    I don't think so... You are talking about standards, and it would be typical for a generic Date class anyways. I would expect more generic classes to crop up in the future, as for Namespaces, I suppose that's something that we'll have to do without for the time being.

    Ie Observer and Observable for example.

    Free speech means that you will hear things that you don't like. It's a good thing.
    Except when you are slandering someone, yes I would agree.

  13. #13
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    I don't think so... You are talking about standards, and it would be typical for a generic Date class anyways. I would expect more generic classes to crop up in the future, as for Namespaces, I suppose that's something that we'll have to do without for the time being.

    Ie Observer and Observable for example.



    Except when you are slandering someone, yes I would agree.
    Hey no one is getting slandered on the web......... now libel on the other hand.... or maybe even slashdotted .

  14. #14
    SitePoint Enthusiast
    Join Date
    Aug 2005
    Location
    Santa Rosa, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What's going on here? I totally and utterly agree with the core devs on this -- the onus is on PEAR to use a name that does not conflict with what needs to be in the PHP core distro.

    Everyone talks about all the flaws of PHP...guess what? Those flaws are there because core devs did not put their foot down and implement the correct and proper way of doing things from the get-go. I applaud their current efforts to improve PHP at a more rapid and logical pace, and BC be damned, I say. I'd much rather update code to work with the latest release when it means I get a better and more powerful language.

    I honestly don't know how we can have it both ways. If PHP is to get better and more sophisticated in order to compete with Ruby/Python/whatever, it's going to have to break BC for sure and without a doubt in both its core language as well as third-party libraries. That's just the way it is. If that isn't acceptable for you, then you could just switch to Ruby now, but that's sort of silly considering it's easier to stick with PHP and tweak things as the language improves.

    Jared
    Willowgarden: rapid application platform for PHP 5
    xajax: fast and easy PHP Ajax library
    Web software architecture blog: The Idea Basket

  15. #15
    SitePoint Enthusiast
    Join Date
    Aug 2005
    Location
    Santa Rosa, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    P. S. And namespaces will be awesome and help with this particular sort of problem in the future, certainly. Yay, yay, and double-yay.
    Willowgarden: rapid application platform for PHP 5
    xajax: fast and easy PHP Ajax library
    Web software architecture blog: The Idea Basket

  16. #16
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...I'd much rather update code to work with the latest release when it means I get a better and more powerful language.

    I honestly don't know how we can have it both ways. If PHP is to get better and more sophisticated in order to compete with Ruby/Python/whatever, it's going to have to break BC for sure and without a doubt in both its core language as well as third-party libraries. That's just the way it is. ...
    Ahem to that, well said. I get the feeling, that it had to be said but I wasn't prepared to say anything, in the event that it would inflame the thread, but I'm glad someone has said it.

  17. #17
    SitePoint Enthusiast
    Join Date
    Aug 2005
    Location
    Santa Rosa, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh, well thanks. I wasn't trying to inflame anything, of course -- I was just feeling sorry for the PHP devs who have 50% of the folks telling them never to break anything, and the other 50% yelling at them for holding back on a bazillion new language features and improvements!
    Willowgarden: rapid application platform for PHP 5
    xajax: fast and easy PHP Ajax library
    Web software architecture blog: The Idea Basket

  18. #18
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JaredWhite
    I honestly don't know how we can have it both ways. If PHP is to get better and more sophisticated in order to compete with Ruby/Python/whatever, it's going to have to break BC for sure and without a doubt in both its core language as well as third-party libraries. That's just the way it is. If that isn't acceptable for you, then you could just switch to Ruby now, but that's sort of silly considering it's easier to stick with PHP and tweak things as the language improves.
    This may be stating the obvious, but the pain associated with BC is directly coupled to your target audiance. At work I control the server environment, I can code things for PHP5 and be happy. When php5.1.0 comes along I can build it on our development system, run the unit tests on the code and bang around in the apps and have a great degree of comfort in rolling out the new version as well as having access to the latest and greatest features.

    Now when I work on WACT or SimpleTest I am faced with a different problem. Both of these code bases aim to as wide of an audiance as possible, meaning all sorts of php hosting configurations, etc. Both of these code bases are intended to support both PHP4 and PHP5, especially since PHP5 just has not penetrated the hosting demographics like you think it should have. This is the area where dealing with BC issues is particularly sticky: how do you code the app for the latest and the ancient at the same time without forking the code base?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  19. #19
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    This is the area where dealing with BC issues is particularly sticky: how do you code the app for the latest and the ancient at the same time without forking the code base?
    I suggest that when dealing with incompatible target systems you do the reasonable thing: you create a new branch and support the old branch for "as long as it makes sense". Similarly, the amount of effort you put into the new branch should correspond to the payback you expect for that branch. Yes, it is more work but that is the choice you must make for yourself: do you want to support and target two different platforms or not? There is no free lunch

  20. #20
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by JaredWhite
    I honestly don't know how we can have it both ways.
    Easy.

    A new feature is announced well in advance so that well ahead of time we don't write code that will end up using it. Once a feature is changed, the old version is marked deprecated for a version or so, so that code that has used it in the past can migrate over.

    That way we have continuous improvement and "userland" don't suddenly find they can't upgrade someday. Say when a new feature appears in a "release candidate" .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  21. #21
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    A new feature is announced well in advance so that well ahead of time we don't write code that will end up using it. Once a feature is changed, the old version is marked deprecated for a version or so, so that code that has used it in the past can migrate over.
    You mean like the addition of a Date class in RC5 ? (Admitted, plans to add it existed already a couple of months)

    Quote Originally Posted by lastcraft
    That way we have continuous improvement and "userland" don't suddenly find they can't upgrade someday. Say when a new feature appears in a "release candidate" .
    The issue i have with programming PHP is that for every project you need to figure out the installed version, the applied restrictions, (not) installed extensions. And choosing for the lowest common denominator doesn't seem very practical either..

  22. #22
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JaredWhite
    What's going on here? I totally and utterly agree with the core devs on this -- the onus is on PEAR to use a name that does not conflict with what needs to be in the PHP core distro.

    Everyone talks about all the flaws of PHP...guess what? Those flaws are there because core devs did not put their foot down and implement the correct and proper way of doing things from the get-go.
    I don't get this. When PEAR Date was introduced -- how many years ago? -- was there anyone who even considered the possibility that there might be a Date class built into PHP (or any class for that matter)?

    Java has a Date class, but you do have to import it. So if when "the correct and proper way of doing things from the get-go", perhaps you mean implementing namespaces first? That would have helped.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  23. #23
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    Java has a Date class, but you do have to import it. So if when "the correct and proper way of doing things from the get-go", perhaps you mean implementing namespaces first? That would have helped.
    I agree. It was the lack of a consistent (and consistently followed) naming policy for different groups (userland/pecl/core), a lack of features that could prevent toe-stepping and some short-sightedness when introducing more OOP features in a decidedly procedural language.

    Note that the naming issues in the procedural side are fairly much non-existant. OOP designs have a tendancy to want to grab a lot of generic names so without policy and/or namespacing (or similar), clashes between groups are inevitable. The date example is fundamental for a few reasons. Some could argue that "date" wasn't even an appropriate name for the class based on what it was doing which is probably more akin to datetime; however, neither name should have been introduced as a builtin class.

    I agree with lastcraft in that userland should be given the leeway to own the general/default namespace. The language already sucks up good names via reserved keywords, function and constant names; allowing it to encroach further by adding class names to the mix -- especially without namespace support -- is unreasonable and unwarrented. The core should prefix their classes. Not doing so dramatically increases the instances where they will break userland code without any good reason.

  24. #24
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    I get the feeling that we need to go right back... Look at the lack of cohesion with the PHP library functions as one example, which make me ponder, is PHP continueing down that road without much thought, with object oriented methodologies?

    In that sense, is there a lack of direction, or more to the point, standards of how a name is used by a core feature - in this case, the Date class - which brings us to the Standard PHP Library.

    Will that fail us as well, much like the way the function library has? Another though - will namespaces actually render that problem irrevelant for us developers?

    Personally, I don't actually think that it would to be honest. Ideally, for any core feature, there has to be discussion and there has to be documentation. There needs to be a consensus, and I haven't seen that.

    Without doing the job properly in the first place, and it's something that may well do well to begin with PHP6 - and to hell and damnation with BC issues - that we will be able to use PHP effectively in the future.

    PHP6 is another 2 years or so away, so I would like to think that there is time yet to do something with PHP, to bring it to more maturity.

  25. #25
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the problem with PHP is that PHP developers got too drunk with "getting the job done" philosophy.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •