SitePoint Sponsor

User Tag List

Page 1 of 4 1234 LastLast
Results 1 to 25 of 95

Hybrid View

  1. #1
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    PHP6 - Direction of PHP

    Hi,

    I've been reading about some of the new features PHp6 may include. Some of them are intriguing.

    PHP6 is supposed to have type hinting for return values. They thought about type hinting for properties, but rejected that idea.

    Source: Minutes PHP Developers Meeting - 5.8 Type-hinted properties and return values

    What are your thoughts on this? I'm somewhat excited about it, because I can see where it could be useful, but I am starting to imagine methods like:

    PHP Code:
    public MyObject function someMethod(MyOtherObject $another_object)
    {
        
    // ...

    This is starting to look more and more like a statically-typed language. I won't say whether that's a good or bad thing, as I think both have their places in development, but it just seems kind of weird in a language that professes to be dynamically-typed. What are your thoughts?

    I like the direction that PHP is starting to go. PHP5 is, in my opinion, leagues ahead of where PHP4 was, and I hope PHP6 will make even more improvements, especially if it includes namespace support. That's excellent for the developers who use PHP's more advanced features, but I'm wondering what will happen to PHP's largest? user base, using procedural programming. Is PHP going to promote object-oriented programming (as I think it is beginning to in PHP5), maybe earning more respect from some developers, while alienating the others? Is PHP still going to be the language with the low barier to entry and shallow learning curve as it was in PHP4 and earlier?

    I don't mind either way. I'm thrilled to see PHP going in the direction it is. I'm just wondering about the effects of this new direction.

  2. #2
    SitePoint Enthusiast
    Join Date
    Jul 2006
    Location
    Australia, Victoria
    Posts
    56
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the namespaces are a great idea and its good they are implementing.

    Im not a big fan of type-hinting only because in some places it can confuse me although i wish they did use delegates as i 'for some reason' like them, and use them abit with C#.

  3. #3
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, as long as it's optional, I can live with it. But it keeps the same circular issue as the interfaces/typehints combo.

    It would be great if they implemented some kind of in-memory persistance, e.g. an application server, at least as an option to be used.

  4. #4
    SitePoint Wizard Mincer's Avatar
    Join Date
    Mar 2001
    Location
    London | UK
    Posts
    1,140
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Well, as long as it's optional, I can live with it. But it keeps the same circular issue as the interfaces/typehints combo.

    It would be great if they implemented some kind of in-memory persistance, e.g. an application server, at least as an option to be used.
    It's fairly simple to implement an object cache using memcache

    php.net/memcache

  5. #5
    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 Mincer
    It's fairly simple to implement an object cache using memcache

    php.net/memcache
    I'll have to look deeper into memcache, so I don't know if it handles what I have in mind. In any case, just today I realized that in PHP it makes more sense to -- when you have a collection object, and for example use DB -- keep just the IDs of individual objects in an array, and then construct an object just when you need it, or at least to keep a single object and use ID to reset it to new values. That's because at the end of a request all objects are destroyed, and it doesn't make sense to create all the collection's objects -- especially if you end up using only some of them, which is often case.

    In other environments full objects get persisted in memory between requests, and don't have to be recreated each time.

  6. #6
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    In other environments full objects get persisted in memory between requests, and don't have to be recreated each time.
    That's true but don't forget that PHP is designed to re-compile at run time every time; whereas those other languages generally are not. The overhead of creating an object in PHP is generally extremely low compared to those languages, and when combined with the Apache DSO, the raw performance is hard to beat and makes things like a PHP application server make little sense where they are quite necessary to get good performance in other languages that were not designed for the web but were adapted to it.

    There's not really any reason performance wise to persist objects between PHP requests. You'd probably end up spending more overhead to persist the object than you would have used to just create a new instance.

    The only times I can think of when it would be handy to persist an object is if it is doing something extremely intensive at construction, such as merging several configuration files together into a single config object. But even with things like this, there are other ways to approach the performance issue, such as merging the config files together first, caching that, and then creating the config object which now only has to read one file instead of several.

    But if an object must be persisted for whatever reason, it is quite easy to persist if the object is serializable. Just serialize it and store/cache it somewhere, whether it be a file, the database, or memory (there are a few PHP extensions to caching items in memory). The caveat is the object must be serializable, even with memcache, so objects like resources, simplexml, or other internal classes that cannot be serialized are not cacheable.

    If most of the objects you are creating during a request are not even being used, rather than look for ways to persist them, I think I would ask the question, "Why are they even being created at all?". Instead of trying to persist all objects that may or may not be needed, why not only create those objects which are most likely necessary (75% or greater chance of being used for example), and reserve creation of the other objects to when you know they are needed (i.e, right before they are used)?

  7. #7
    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 dreamscape
    If most of the objects you are creating during a request are not even being used, rather than look for ways to persist them, I think I would ask the question, "Why are they even being created at all?". Instead of trying to persist all objects that may or may not be needed, why not only create those objects which are most likely necessary (75% or greater chance of being used for example), and reserve creation of the other objects to when you know they are needed (i.e, right before they are used)?
    I agree with that.

    As I see it, you can do a collection of objects in one of three ways (assuming, of course, that the objects' data is somehow persisted between requests, which is mandatory in PHP as you so nicely explained):

    a) Create all objects at the time of collection's creation and hold them in some sort of array. While perhaps the overhead of creating an object might not be too big here, if the objects are large (perhaps with other objects composed into them) and there's a lot of them it can quickly fill up the memory.

    It would look something like this:

    PHP Code:
    class WidgetCollection
    {
        private 
    $widgets = array();

        public function 
    __construct()
        {
            foreach (
    $this->getWidgetsFromDatabase() as $w) {
                
    $this->widgets[] = new Widget($w);
            }
        }

        public 
    doSomethingWithWidgets()
        {
            foreach (
    $this->widgets as $w) {
                
    $w->doSomething();
            }
        }

        
    // ... other code


    b) Keep only the identifiers of the objects in the collection, loading the source and instantiating the object only when needed:

    PHP Code:
    class WidgetCollection
    {
        private 
    $widgetIds = array();

        public function 
    __construct()
        {
            foreach (
    $this->getWidgetIdsFromDatabase() as $w) {
                
    $this->widgetIds[] = $w;
            }
        }

        public 
    doSomethingWithWidgets()
        {
            foreach (
    $this->widgetIds as $w) {
                
    $this->getWidget($w)->doSomething();
            }
        }

        public 
    getWidget($w)
        {
            
    $widget $this->getWidgetDataFromDatabase($w);
            return new 
    Widget($widget);
        }

        
    // ... other code


    c) Keep an object that gets to be reused when necessary:

    PHP Code:
    class WidgetCollection
    {
        private 
    $widgets = array();
        private 
    $widget;

        public function 
    __construct()
        {
            foreach (
    $this->getWidgetsFromDatabase() as $w) {
                
    $this->widgets[] = $w;
            }
            
    $this->widget = new Widget();
        }

        public 
    doSomethingWithWidgets()
        {
            foreach (
    $this->widgets as $w) {
                
    $this->setWidget($w);
                
    $this->widget->doSomething();
            }
        }

        public 
    getWidget($w)
        {
            
    $this->widget->set($w);
        }

        
    // ... other code


    The latest seems like a good compromise, because a) it has only one call to the persistance repository (database in this case), b) has the lowest instantiation count (only one) and c) is fairly object-oriented. On the other hand the Widget class has to follow a strict interface, which should include at least a set() method and a constructor with no parameters; i.e. it should be able to exist uninitialized with data, which is not always possible.

  8. #8
    SitePoint Wizard Mincer's Avatar
    Join Date
    Mar 2001
    Location
    London | UK
    Posts
    1,140
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    In any case, just today I realized that in PHP it makes more sense to -- when you have a collection object, and for example use DB -- keep just the IDs of individual objects in an array, and then construct an object just when you need it
    Take a look at the Proxy Pattern [GoF] and Lazy Load [PoEAA]. They detail possible alternatives to just storing an array of IDs, that you may find useful.*

    Matt.

    * But like any design pattern, Think "Do I really need this", or do I have Patternitis?"

    [GoF] - Design Patterns

    [PoEAA] - Patterns of Enterprise Application Architecture

  9. #9
    SitePoint Zealot Serberus's Avatar
    Join Date
    Oct 2005
    Location
    Herts, UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana
    That's excellent for the developers who use PHP's more advanced features, but I'm wondering what will happen to PHP's largest? user base, using procedural programming. Is PHP going to promote object-oriented programming (as I think it is beginning to in PHP5), maybe earning more respect from some developers, while alienating the others?
    Perl will presumably have the same problem with version 6 - growing pains of the language.

    Quote Originally Posted by devbanana
    Is PHP still going to be the language with the low barier to entry and shallow learning curve as it was in PHP4 and earlier?
    I think it will still have a low barrier to entry, what caught the eye of so many has not changed. What probably (and hopefully) will change is the skill level requirement for professional PHP developers.

    Zend are definately trying to make inroads on Java, I'd think it's now an easy transition to move from Java to PHP5 (although the salary for PHP still hasn't caught up but is improving!). If you are only producing web based systems then Java has a lot of additional complexity (being a jack of all trades language) that just doesn't exist in PHP. However, if Java was my home ground, I still wouldn't have have jumped ship to PHP yet.

    The last company I worked for tried to go PHP -> Java but it didn't work out well, most of the PHP devs OO wasn't strong enough and development time was significantly increase for Java projects. Anyway, I digress...

  10. #10
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    I'm in an airport getting ready to go from orlando, Florida to Pittsburgh, Pennsylvania, but I thought I'd try to make a reply to the replies this thread's already gotten.

    Quote Originally Posted by Serberus
    Perl will presumably have the same problem with version 6 - growing pains of the language.
    That's interesting. So I guess PHP isn't the only language going through this.

    Quote Originally Posted by Serberus
    I think it will still have a low barrier to entry, what caught the eye of so many has not changed. What probably (and hopefully) will change is the skill level requirement for professional PHP developers.

    Zend are definately trying to make inroads on Java, I'd think it's now an easy transition to move from Java to PHP5 (although the salary for PHP still hasn't caught up but is improving!). If you are only producing web based systems then Java has a lot of additional complexity (being a jack of all trades language) that just doesn't exist in PHP. However, if Java was my home ground, I still wouldn't have have jumped ship to PHP yet.

    The last company I worked for tried to go PHP -> Java but it didn't work out well, most of the PHP devs OO wasn't strong enough and development time was significantly increase for Java projects. Anyway, I digress...
    I hope the skill level of PHP developers does increase. Hopefully, a happy balance can be met, where it is easy to learn PHP, but novice developers are heavily encouraged to improve their skill level. Where they can't just forever make insecure, hackish scripts, but where there are a lo tmore resources for advanced topics. That'd be a happy medium.

    Again, I do like these type hinting features. I just find it curious that a dynamic language is implementing such a feature. But I think it's very useful.

    The scary thing is, I've met a fe wnovice developers who are currently using PHP4, and said that they don't want to learn PHP5 because it seems too complicated. That's not helping the process of migrating from most people using PHP4 to most people using PHP5.

    A few of the features mentioned in the link I gave, i would have liked to see in PHP6. But I do see where they are coming from.

    P.S.:

    How far behind is the average salary of PHP developers in comparison to that of Java developers?

  11. #11
    SitePoint Zealot Serberus's Avatar
    Join Date
    Oct 2005
    Location
    Herts, UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana
    Hopefully, a happy balance can be met, where it is easy to learn PHP, but novice developers are heavily encouraged to improve their skill level. Where they can't just forever make insecure, hackish scripts, but where there are a lo tmore resources for advanced topics. That'd be a happy medium.
    I think the majority of more seasoned developers want this as well. PHP is being used to solve bigger problems these days, with that comes better development practices to handle the increased complexity.

    For the longest time the bigger community sites like phpbuilder, phpfreaks etc push a lot of procedural because that's the PHP way. Looking at some of Rasmus' articles he is "procedurally bias" (if there is such a term).

    Quote Originally Posted by devbanana
    The scary thing is, I've met a few novice developers who are currently using PHP4, and said that they don't want to learn PHP5 because it seems too complicated. That's not helping the process of migrating from most people using PHP4 to most people using PHP5.
    I've seen this myself as well, I hope this will seperate the wheat from the chaff as PHP5 and future versions become the norm.

    Quote Originally Posted by devbanana
    How far behind is the average salary of PHP developers in comparison to that of Java developers?
    From my own experience PHP used to top out about low 30's unless you head to London or take on a lead developer / semi-management role. Salaries have increased this year though and I've seen more around 40 - 45k which was almost unheard of 12 - 18 months ago.

    Java can be twice this for an architect / EJB guru position. This is by no means a rule of thumb, just what I've seen advertised.

  12. #12
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Serberus
    I think the majority of more seasoned developers want this as well. PHP is being used to solve bigger problems these days, with that comes better development practices to handle the increased complexity.
    Very true. But I just hope we don't forget about those who still are just creating "personal home pages" as PHP was originally intended for. Again, hopefully PHP can keep developers from both ends of the spectrum happy. Sounds like a challenge.

    Quote Originally Posted by Serberus
    For the longest time the bigger community sites like phpbuilder, phpfreaks etc push a lot of procedural because that's the PHP way. Looking at some of Rasmus' articles he is "procedurally bias" (if there is such a term).
    And until that stops, and until the newer features of PHP5 start to be pushed and encouraged more, I don't think there'll be a mass migration to the newer PHP versions. if there is, they will code in the same style as before and avoid the new classes in PHP5. 'Tis a shame, really.

    Also, what hope does PHP have when one of the major developers of it promotes procedural development? )

    Quote Originally Posted by Serberus
    I've seen this myself as well, I hope this will seperate the wheat from the chaff as PHP5 and future versions become the norm.
    Hopefully. But those developers still shouldn't be alienated, just encouraged more heavily to advance their skills. The problem is that too many developers have the attitude of, "as long as it seems to work well enough, it's fine and I don't need to learn anymore."

    Quote Originally Posted by Serberus
    From my own experience PHP used to top out about low 30's unless you head to London or take on a lead developer / semi-management role. Salaries have increased this year though and I've seen more around 40 - 45k which was almost unheard of 12 - 18 months ago.
    Wow, not bad. Not the best salary, but great improvement.

    Quote Originally Posted by Serberus
    Java can be twice this for an architect / EJB guru position. This is by no means a rule of thumb, just what I've seen advertised.
    Wow, that is a lot. It's a little discouraging for PHP.

  13. #13
    SitePoint Member
    Join Date
    Sep 2006
    Posts
    6
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP6 is definitely a step in the right direction. Personally I'm not sure about the type hinted return values but the general clean up is a very good thing IMO (Ditching of magic quotes, register globals option, long arrays & safe mode etc)

    I think the integration of APC is a smart move too although it is a pity that it does not auto configure itself (and hence be enabled by default).

  14. #14
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'll have to look deeper into memcache, so I don't know if it handles what I have in mind.
    There has been some work on an apache module that works like mod_perl/mod_python, that is allows persistence and gives one the ability to hook into apache. I don't think the project has gotten much attention though (sorry can't seem to find a link to it).
    The overhead of creating an object in PHP is generally extremely low compared to those languages
    Have you actually tested this, because its the opposite. Object instantiation in Java is dramatically faster than PHP (likewise for say C#).

    Also as far as I know tools like memcache can only deal with things that are serializable but a lot of things you want to persist are not, such as connections. In Java connectin pooling is trivial..but in PHP?

    what hope does PHP have when one of the major developers of it promotes procedural development?
    Its only natural, they are after all developing an application writen in a procedural langauge. Maybe they need to switch to C++ : /

  15. #15
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Snaily
    Also as far as I know tools like memcache can only deal with things that are serializable but a lot of things you want to persist are not, such as connections. In Java connectin pooling is trivial..but in PHP?
    This is true (only caching serializable stuff), though in PHP there should be no need to persist a database connection into memcache or APC. Persistent connections are already handled by PHP. Admittedly, they're not identical to connection pools in Java, but they at least help solve the issue of having PHP open & close a new connection on every script invocation.

  16. #16
    SitePoint Evangelist
    Join Date
    Aug 2004
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    the more i learn about other languages

    I started out in php and still use it @ home.

    However, at work i program in .net and at school i program microcontrollers in c.

    Wish list:

    namespaces

    nested classes support [example:
    Authenticate has nested: AuthenticateCookie, AuthenticateSession
    this way storeauth, logout, confirm are clean from actual implementation
    .. perfect for classes only needed by one other class. [cannot be methods.. because these follow an interface also. -- parsing libraries]
    ]



    enums


    c style better procedure support:
    pointers
    function pointers [dispatch tables -- simulate delegates as someone above stated; High order perl book .. is best practices in procedure style programming.. i would recommend it even to oop people like myself.]

    i mean if functions like http://us3.php.net/unpack exist and bitwise operators exist.. why can't i find the location of the bits. why can't i work with addresses instead of values?

    how about stucts so the stack frame isn't as large as a class would be.


    httpmodules ... something better than mod_action ... php.net/pdo needs more examples with advanced database feature. I have an opened item in advanced php forum talking about cursors.. i haven't been able to find any examples. [think it might be that i'm not using a persistant connection... but my laptop crapped out on me.. so i'll let everyone know by friday.]


    better ide tool. [note: i haven't tried the newest zend studio version]


    all the problems with character sets fixed.. or so that i don't have to worry about it. [regex, and inserting into db]


    and those notes are old. Is there no new updates out there? when is php6 expected to be released?

    Leblanc Meneses
    Last edited by leblanc; Dec 22, 2006 at 13:22.

  17. #17
    SitePoint Enthusiast CrucialWebHost's Avatar
    Join Date
    Jun 2006
    Location
    Arizona
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Mmm. PHP6 sounds like fun Personally, I'm waiting for CSS3 to hit the market! Some great, great features they're going to include with that. I'm still touching up on my PHP5 though, and have been diving more into classes. It's really improved my coding, both in terms of function and elegance.
    Crucial Web Hosting Our new site is live!
    Introducing Split-Shared and Split-Dedicated
    hosting products! Join our new Developer Network
    and check out the updated Site Showcase!

  18. #18
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally, I'd be more than happy if PHP remained a procedural-only language, providing that there's another OOP language that is so nicely intergrated with Apache and supported everywhere like PHP is. Python has some support there, but frankly I'd be happiest if the whole wxJS thing -- and particularly mod_wxjs -- gained some traction.

  19. #19
    SitePoint Enthusiast
    Join Date
    Apr 2006
    Posts
    49
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I returned to PHP to get away from the complex syntax of Java and ASP.net which I had been using for the odd project. Ultimately people use PHP to create websites, not control systems for space rockets - so in my view fundamental ease of use and simplicity should come before absolute "correctness" in the eyes of a programming purist.

    v6 looks like Java to me. Java isn't trivial in the same way scripting languages like PHP and ASP are, and moving in that direction would take away the mass appeal. I suggest that the PHP programmers who are looking for a way of programming like BerislavLopac demonstrates have a look at Java today. Might be good for your wallet too

    I disagree that quickly written scripts are inheritantly insecure - I could be true that the more complex something becomes the bigger the holes become. (Internet Explorer being a good example) As program logic becomes obscured by programming "clutter" these flaws can be harder to spot.

    I love php5 - loosely typed with all the benefits of OO. A balance should be found.
    Last edited by neildonald; Sep 13, 2006 at 01:57.

  20. #20
    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 neildonald
    I suggest that the PHP programmers who are looking for a way of programming like BerislavLopac demonstrates have a look at Java today.
    Huh? Would you be so kind to clarify a bit what "way of programming" do I demonstrate? After reading your post, I'm not sure that I understand your (rather complex) sentence, nor that you understand what "way of programming" I personally prefer...

  21. #21
    SitePoint Guru worchyld's Avatar
    Join Date
    Jul 2003
    Location
    Newcastle upon Tyne
    Posts
    909
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just make it like ruby/rails, secure to code without having to worry about XSS issues, easy to understand and get full support by hosting companies to support it.

  22. #22
    SitePoint Enthusiast
    Join Date
    Apr 2006
    Posts
    49
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    changed "you" to "people" and added [take advantage....]

    BerislavLopac, don't take it personally and I apologise if you did. I'm just saying that if you people want to program using objects and [take advantage of other programming features such as] strictly typed variables in a way that PHP5 fully doesn't support (so far as I know), then Java might be the tool for you them. Java has been like that since its conception - so no need to wait for the next version of PHP.

    I didn't make any assumptions about your programming style or preferences. I was merely commenting on the examples (which I don't fully understand) in post #11. Maybe I didn't make this clear.

    I'm sorry that my sentence didn't make perfect sense to you. It makes perfect sense to me. I'm quite happy to be corrected on matters of fact but I find the tone of you response overly hostile / defensive.
    Last edited by neildonald; Sep 13, 2006 at 09:23. Reason: Clarifying use of language relating to BerislavLopac points

  23. #23
    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 neildonald
    BerislavLopac, don't take it personally and I apologise if you did. I'm just saying that if you want to program using objects and strictly typed variables in a way that PHP5 fully doesn't support (so far as I know), then Java might be the tool for you.
    Not at all, I haven't taken it personally -- it was just that I was completly taken aback with your assumption which was't clear in the previous post, but you confirmed it now.

    I really have no idea where you got the impression (again, no offense -- just total confusion) that I want to program using strictly typed variables. I believe that all my posts so far, in all the threads I participated, clearly displayed my inclination towards dynamic typing, and that I wouldn't touch static typing with a ten-foot pole, except where it improves the architecture.

    I've worked in quite a lot of languages, from Basic to C to PHP to Java to Python to XSLT to Javascript, and all in all I have nearly two decades of programming experience.

    Quote Originally Posted by neildonald
    I didn't make any assumptions about your programming style or preferences. I was merely commenting on the examples (which I don't fully understand) in post #11. Maybe I didn't make this clear.
    No you didn't, and especially I don't get where did you see static typing in those examples?
    Last edited by BerislavLopac; Sep 13, 2006 at 09:30.

  24. #24
    SitePoint Enthusiast
    Join Date
    Sep 2006
    Posts
    49
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The return hinting I am looking forward too, solely for use in interface driven design, and assuming it will be optional.

    Up until now, interfaces have always felt like they are 'lacking' because although you can specify the input type, the return type could be wrong for what the method intends and ruin the whole purpose of the interface

  25. #25
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OPTIONAL object-oriented purity. What could be better? Its there for those who want it, and not there for those who don't. It really is the best of both worlds.

    I will be embracing it. All i've been after in php for a while now is OPTIONAL type-hinted return values, and namespaces. If php6 has both, it will be a pleasure to program with.


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
  •