SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 82
  1. #26
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Brazil,Maringá-PR
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I almost cry when I read this http://www.php.net/~derick/meeting-notes.html
    Very Very disapoint.
    I can't understand why they force to keep PHP in the "cave" and don't see excelent features of Ruby and Python.
    My notes:

    Delegates(Decorators) would be very usefull. I use it all the time to decorate my iterators.

    Named Parameters I use in almost all my classes to setup my objects. All methods that needs a list of configurations, I have to use array as parameters to simulate Named Parameters.

    Type-hinted properties and return values
    No coments

  2. #27
    Web developer Carl's Avatar
    Join Date
    Sep 2003
    Location
    sweden
    Posts
    320
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    They are doing somethings I really don't like.

    4.3
    4.4

    Getting rid of dl() rather than fixing it is a simple way of getting rid of any potential competion for the Zend engine functions. It's a rip-off and very diasppointing. There should be an API for running c code (jalied) to replace this but that won't happen either.
    ================================
    This is total crap:

    $foo = ifsetor($_GET['foo'], 42); even more confusing than the original.

    moving ereg() to PECL to make it even more of a resource hog.
    ====================
    5.5
    5.6

    Are good.

    Aside from the attempts to improve OOP the rest is very disappointing and smacks of commercialism.

  3. #28
    Web developer chrisranjana's Avatar
    Join Date
    Jan 2001
    Location
    chennai , tamil nadu , India
    Posts
    710
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hopefully they listen and implement only the well thought out changes.
    Chris, Programmer/Developer,
    Laravel Php Developers, Ruby on Rails programmers,
    Moodle, Opencart, Magento, Geodesic Classifieds/Auctions,
    www.chrisranjana.com

  4. #29
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Aside from the attempts to improve OOP the rest is very disappointing and smacks of commercialism.
    In what way? What specifically are the features that are being added - or removed for that matter - that have upset you?

    From the brief look I took at it yersterday, there was not enough - I was looking for a lot more in fact. On the point about Type Hinting from Marcus, I'm sorry, but I'd have to completely disagree with you - we need type hinting.

    I know a few members disagree with it, with PHP being PHP but PHP5 object model didn't go far enough in my view. As for GOTO, well, we could pretty much do without that, thank you very much.

    I have a suggestion where you could goto

  5. #30
    SitePoint Enthusiast MstrBob's Avatar
    Join Date
    Dec 2004
    Location
    New York City
    Posts
    86
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    There will be two string types: Binary (which is non-unicode) and String (which can be unicode or not, depending on ini setting). Similarly, there will be two integers: Int64 (which is always 64 bit) and Int (which is 32- or 64-bit depending on the current machine's word size). I've a strange feeling this can cause some portability troubles...
    Isn't that currrently how PHP works anyway? Integers on 64bit systems are 64bits. They're only adding a new int64 which will be 64bits regardless of the system.

    I don't know, from the discussions it looks pretty good. They're cleaning up the language, which is a good thing. Yes, of course that causes compatability issues, it always will. But that's part of upgrading, isn't it? It's not like they're suddenly dropping features, they're removing depreceated, archaic, and unused stuff.

    XMLReader and XMLWriter in the default distribution seems handy as well. All in all this seems like a pretty positive step for PHP. It needs a cleanup, sometimes things just get clunky. Goto support is not decided on yet, so we can't really complain yet.

    My main concern, of course, is this focus to PHP 6. Most of my clients have hosting with PHP 4. With PHP 5 penetration not that deep yet, they're already jumping to another major version?

  6. #31
    Web developer Carl's Avatar
    Join Date
    Sep 2003
    Location
    sweden
    Posts
    320
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    In what way? What specifically are the features that are being added - or removed for that matter - that have upset you?

    From the brief look I took at it yersterday, there was not enough - I was looking for a lot more in fact. On the point about Type Hinting from Marcus, I'm sorry, but I'd have to completely disagree with you - we need type hinting.

    I know a few members disagree with it, with PHP being PHP but PHP5 object model didn't go far enough in my view. As for GOTO, well, we could pretty much do without that, thank you very much.

    I have a suggestion where you could goto
    Specifically the removall of dl() seems commercial. I poured over Schlossnagle's book for 2 months before I coluld write and compile an extension to PHP. It is a pain in the ... because the c syntax and library of the Zend Engine is overly verbose, undocumented (at least for us normal humans) and clunky. I longed that they would change this and also change dl() to make it more reliable, easier and safer to run in a hosting environment. They claim that people don't use some items when in fact they aren't used because they never seemed to be completed. As you know they are coming out with a framework this is most likely going to cost. A php framework would have to be built into the core inorder to be on the same level as rails. It could also be done in the form of an extension to PHP. The reason no one has done something like this before is because dl() was never really given the finishing touches that would allow it, documentation or API. Now that they are going with their home rolled framework they are pulling dl()?

    They might want to put some effort into bettering things before they just kill them. Especially the stuff that has the potential to set PHP apart without it being a "Zend" product.

    About the addition of APC and hardened PHP, if you remember turckMMcache disappearing for a while you see the connection. The rest seems like an effort to simplify code detection in a certain IDE

    I am no conspiracy theorist but something in this list just does not feel right.

  7. #32
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If PHP is seen as a Zend Product, that may well not be a bad thing in it's self is the idea I have. The very thing that if PHP by some could be seen as a Zend Product has it's advantages.

    If the product in question is viable, then it makes sense to commercialise it, to profit from it - that is business. If there is a market for the product - a demand, then it's this demand that drives the product.

    It's that motivation I think, that has inspired the forward thinking for PHP6 - that, at the end of the day, is what we need. It's the route that we want PHP to go, if we want to compete against the other enterprise level langauges and technologies

  8. #33
    SitePoint Addict n0other's Avatar
    Join Date
    Feb 2005
    Posts
    290
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Dr Livingston, could you explain why do we need type hinting?

  9. #34
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In PHP4.yuk you can only do this for example,

    PHP Code:
    // ...
    public function SomeClassConstructor$datasource) { 
    But with PHP5, we can do this,

    PHP Code:
    // ...
    public function __constructIDataSource $datasource) { 
    That adheres to a given Interface, so I could pass in any type of data source, such as an XML or SQL data source, and both would still be legal - you can't do that without type hinting.

    To validate that, you would need to physically check for the object passed into the class method yourself - not so with type hinting. One gripe that I do have is that you can't throw an exception, if you pass in the wrong object, as you can throw an exception in that event, in Java.

    Also, you can't cast in PHP5, like you can in Java either - two areas where the object model fall down on in my view, in regards to PHP5

  10. #35
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by n0other
    Dr Livingston, could you explain why do we need type hinting?
    Can you proove that you do not need type hinting at all ?

    Static vs dynamic wars are very old and boring, but the truth as always lies somewhere in the middle.
    The perfect programming language for me is one that has optional type hinting.
    As Erik Meijer and Peter Drayton correclty said in the following paper:
    http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Meijer.pdf
    "Static Typing Where Possible, Dynamic Typing When Needed"

    I think that's the right approach, and I also think PHP cannot be enterprise ready without optional type hinting. Also, some type hinting here and there can also improove performance.
    And in case you are going to mention Ruby ... Matz is thinking of introducing optional type-hinting in Ruby 2.0.


    About that document (http://www.php.net/~derick/meeting-notes.html) ->
    they are about to make some mistakes, like point 6.5 which was concluded with "We are not going to make exceptions out of any error level". To bad, because Ruby and Python do throw exceptions all over the place.

  11. #36
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i find their abuse using the kiss principle rather annoying, especially for a company aiming to be known as an enterprize ready company. They are adding goto and not even adding a keyword for property... 0.o you know they have thrown out goto in other languges cause of the evil it causes.

  12. #37
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    GOTO is still used today, but mostly for optimisations. For example a function call is much more expensive than a goto jump. And when you call the same function in a loop thoudsands of times, goto can really speed up things.

    GOTO does not belong in PHP indeed.

  13. #38
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    i find their abuse using the kiss principle rather annoying,
    Yeah, seriously. "We're not gonna implement feature X. KISS." Delegates, accessors, operator overloading, proper error handlers... Well, I guess they're not going for enjoyable OO, then.

    Here's to waiting Ruby get as widespread as PHP.

  14. #39
    SitePoint Addict
    Join Date
    Apr 2002
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    delegates eh? that's interesting

  15. #40
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    did you guys actually read the section about goto??
    this is what i read:

    Issue: Goto is currently missing in PHP, and although there is a limited use for this construct in some cases it can reduce the amount of code a lot.

    Discussion: There are some inherent problems with implementing goto, as jumping into a foreach() loop will almost be impossible as at the start of the loop something is initialised. The same is most likely true for other loop constructs.

    As goto will most often be used to jump out of nested if statements, we think that restricting the construct so that you can only jump out of a construct is possible. Similarly restricting the construct so that you can only jump down should satisfy people who do not want the ability to jump all over the place.

    The name "goto" is misleading, and often associated with BAD THINGS(tm). Because our proposed solution is not a real GOTO construct, we will instead reuse the "break" keyword, and extend it with a static label.

    An example of using a labeled break:

    <?php
    for ($i = 0; $i < 9; $i++)
    {
    if (true) {
    break blah;
    }
    echo "not shown";
    blah:
    echo "iteration $i\n";
    }
    ?>

    Conclusions:

    1. We extend "break" by allowing breaking to a label.
    2. We ask Sara to make a patch for this, and we see how it is going to look like. We decide on that.
    its a fancy break statement, nothing more.. with many limitations compared to a regular goto(which is a good thing).. imho there is nothing wrong with this at all.. i'm not sure it should be in high priority for the next php release, but if its something easy to implement, i don't see anything wrong with it.

  16. #41
    SitePoint Addict n0other's Avatar
    Join Date
    Feb 2005
    Posts
    290
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Dr Livingston, bonefry, thanks for the explanation. I'm not here to start a war, just to learn. I now understand, that type hinting in function parameters coupled with interfaces enables you to make sure different classes have the same public methods, so we can avoid run time errors. If the class doesn't implement the type-hinted interface, we get a fatal error, but we get the same fatal error while trying to access a non-existing method. What's the difference? You could then think, that some methods might be called only on specific circumstances and you wouldn't be able to spot the error at run time, but then again, you can easily catch such errors while running unit tests. But this something new and something I can't see a use for - type hinting on return values? Again a way to 'stay safe' using random methods returned? I didn't say we don't need type hinting, I just want to find out if we do and if so, how would it benefit us. There are lot's of stuff in PHP that I don't use, but I don't mind, maybe there are others who use it and maybe some day, I will find a use for it also.

  17. #42
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you know they have thrown out goto in other languges cause of the evil it causes.


    They will learn the hard way the non value that GOTO brings to the language. Let me say it for one final time - there is absolutely no need nor the desire for GOTO in PHP.

    It's actually sickening, to think that it will eventually be part of PHP

  18. #43
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    maybe some day, I will find a use for it also.
    I hope you do, and I hope you note the benifits of it, more than what I could ever describe

  19. #44
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by n0other
    But this something new and something I can't see a use for - type hinting on return values?
    There are many cases where documenting the return value is very usefull because it minimizes surprizes.
    For example, take the following code:
    Code:
    function getArray($n) {
       if ($n) {
          return array(1,2,3,4,5); 
       }
       return 0;
    }
    
    if (count(getArray(false))) {
       // DO SOMETHING ...
    }
    In case you don't know, for non-array variables, count always returns positive values. So the code marked with DO SOMETHING ... is always executed.

    To be on the safe side, with functions that I haven't written myself, I ussualy use a long condition like this:
    Code:
    if (!empty($var) && is_array($var) && count($var)) 
       foreach ($var as $row) {
    
           // DO SOMETHING ...
       }
    Not to mention that when I expect an array given as argument to a function I do something like this:
    Code:
    function doSomething($array) {
        if (!is_array($array)) $array = array();
        // ...
    }
    
    // now the following works properly
    doSomething(getArray(false));
    There are many examples like this. And sometimes it lowers productivity, that's why sometimes it is usefull to give type hinting to both parameters *and* return values.

  20. #45
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston


    They will learn the hard way the non value that GOTO brings to the language. Let me say it for one final time - there is absolutely no need nor the desire for GOTO in PHP.

    It's actually sickening, to think that it will eventually be part of PHP
    Quote Originally Posted by http://c2.com/cgi/wiki?GoTo
    The apprentice uses it without thinking. The journeyman avoids it without thinking. The master uses it thoughtfully.
    Don't dismiss it out of hand based on heresay and old-school mentality.

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

    Take the language Pascal for example, that I have some experience with. You would be lost without the use of GOTO, due to the very nature of that language.

    Now we are talking about PHP, and in my point of view, we are talking about object oriented modelling, in which regard the use of GOTO would basically break the model you are trying to develop.

    Procedurally, it may well be different but I still think it's something we can pretty much do without

  22. #47
    Employed Again Viflux's Avatar
    Join Date
    May 2003
    Location
    London, On.
    Posts
    1,127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Have you read the notes?

    They aren't talking about a classic 'goto'.

    They're proposing a labelled break system, something very similar to what PHP already has. They're even proposing limiting the functionality to "forward" jumps.

    Meaning you can break out of a loop upon a certain condition, and skip way down to the end of your application.

    This could be very useful.

  23. #48
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by n0other
    Dr Livingston, bonefry, thanks for the explanation. I'm not here to start a war, just to learn.
    I found an interesting article on the Zend website about interfaces and type hinting if anyone's interested, written last year by Matt Zandstra (of php 5 O,P,P fame). He uses the example of the strategy pattern from his book if i remember. Its a good heads up on the benefits of interfaces.

    Link here

  24. #49
    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 Viflux
    Meaning you can break out of a loop upon a certain condition, and skip way down to the end of your application.
    Isn't that already possible by throwing an extension?

    Right, sure, this labeled break is better for procedural apps.

  25. #50
    SitePoint Guru mwolfe's Avatar
    Join Date
    Mar 2005
    Posts
    912
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    how do you throw an extension? and where do you throw it.. usually i throw them on the end of filenames..


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
  •