SitePoint Sponsor

User Tag List

View Poll Results: How well would Java's class library API serve as a base for a PHP implementation?

Voters
58. You may not vote on this poll
  • It would work well with little modification.

    16 27.59%
  • It would work with significant modification.

    19 32.76%
  • A PHP class library would be better off not basing itself off the Java class library API at all.

    14 24.14%
  • Unsure or not familiar with Java's class library API.

    9 15.52%
Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 82
  1. #26
    SitePoint Evangelist cyngon's Avatar
    Join Date
    Aug 2001
    Location
    Livonia, MI, USA
    Posts
    513
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    anode, I think my example does qualify as refactoring.

    In Fowler's book, Refactoring: Improving the Design of Existing Code, there is a catalog of refactorings, one of which is "Move Method."

    Quote Originally Posted by Martin Fowler
    Moving methods is the bread and butter of refactoring
    And also states:

    Quote Originally Posted by Martin Fowler
    Either turn the old method into a simple delegation, or remove it altogther.
    Anyway, that's besides the point. Any further suggestions on the design of the class library?

  2. #27
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    With all this, it's starting to sound more like a strong-typed language. If there were to be specific methods associated with strings and such, then they would need to be explicitly declared, such as
    PHP Code:
    $var = new String 'foobar' ); 
    So that $var could be made an object and contain the necessary method that are associated as String members within the class library. A generic object could parse the input and define it's "type" but that could be risky.

    And since the PHP environment is dynamically-type all the way through you would need to explicitly define types like
    PHP Code:
    $return_var = (string)/(int)/(float)/(bool)some_function((string)/(int)/(float)/(bool)$var); 
    and that would, in a way, remove one of PHPs greatest advantages in not needing to define types.

    Seems to me that PHP is heading towards C# or Java. I put C# first because I don't have enough experience in Java to comment but yeah.. same deal mostly.

  3. #28
    SitePoint Evangelist cyngon's Avatar
    Join Date
    Aug 2001
    Location
    Livonia, MI, USA
    Posts
    513
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DJ P@CkMaN
    With all this, it's starting to sound more like a strong-typed language.
    The phrase "strongly typed" has a very specific meaning in regards to programming languages. In order for PHP to become strongly typed, changes would have to be made in the Zend Engine itself, not a class library.

    Quote Originally Posted by DJ P@CkMaN
    If there were to be specific methods associated with strings and such, then they would need to be explicitly declared, such as
    PHP Code:
    $var = new String 'foobar' ); 
    So that $var could be made an object and contain the necessary method that are associated as String members within the class library.
    I think what you are saying is that code using the library would have to convert its primitive strings to String objects to call methods in the library that expect String objects as parameters. According to the design principles I proposed earlier in this thread this would never be necessary because all of the public methods of the classes in the library would take primitive strings as parameters and then perform such conversion internally if needed.

    Quote Originally Posted by DJ P@CkMaN
    A generic object could parse the input and define it's "type" but that could be risky.
    I don't understand what you mean. Can you please clarify this statement?

  4. #29
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Me
    A generic object could parse the input and define it's "type" but that could be risky.
    What I meant was that the object could attempt to parse the input and define it's type, but I'm not entirely sure that it could be done easily and correctly identify everything thrown at it. I'm sure that somehow this sort of system could be tricked and while I really couldn't be bothered looking for a way at the moment, I'm sure it could be done.

    After having a bit of a read through this thread, I've gone and written the System.String namespace from .NET into a PHP object just to see what things would feel like being used in that way. I personally quite like it and if someone or a group could be bothered to go and convert the .NET class library into PHP (which woldn't be too tricky, just time consuming) it would be pretty nifty. That would however, competely change PHP as a language as variables would become objects and blah blah we've all heard that before.

    Off Topic:


    Can this be done in PHP? I have an object and if it's called like this
    PHP Code:
    $var = new String 'foobar' );
    echo 
    $var
    That it automatically calls the method String::ReturnVar()?

  5. #30
    Sidewalking anode's Avatar
    Join Date
    Mar 2001
    Location
    Philadelphia, US
    Posts
    2,205
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DJ P@CkMaN
    Off Topic:


    Can this be done in PHP? I have an object and if it's called like this
    PHP Code:
    $var = new String 'foobar' );
    echo 
    $var
    That it automatically calls the method String::ReturnVar()?
    Through overload(), maybe? I'm leaning towards no, it sounds like something that would have to be built in to the language (as does most of this messing with basic types stuff.)
    TuitionFree a free library for the self-taught
    Anode Says... Blogging For Your Pleasure

  6. #31
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Finally getting a little time at last. Great discussion.

    Just some quick thoughts while taking it all in.

    First, as lastcraft pointed out, the Python library is probably a better place to get ideas from than Java.

    Second don't think it's worth trying to release something like this with PHP4 - PHP5 has some "shortcuts" that make constructing such a library at least a little easier, it particular;

    + Object Overloading (PHP style) - put up some notes on this here. Towards the end have some ideas on gathing native PHP functions into classes (with an example using a possible String class). Although this doesn't add significant value it would be a chance to unify some of the functions like strstr() and in_array() where the needles and haystacks tend to swap places as well is implementing any relevant interfaces such as iterators.

    + Abstract Data Types Extension - it's worth checking out what Sterling Hughes et al have been doing here ( PDF: http://www.nme.at/download/phpcon03a...data_types.pdf ). Some of the more complex data types like stacks and queues will probably be available at an engine level.

    + The SPL (Standard PHP Library !) extension currently provides engine level iterators which if a PHP collection object implements, allows elements of the collection to be accessed using foreach{}. Although that's syntactic sugar on the one hand, it does introduce much needed standards. Judging by the name of this extension, there me be more coming from that direction eventually.

  7. #32
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Building object wrappers for primitive types would not be worthwhile in PHP unless it was made a part of the zend engine.

    For statically typed languages such as Java, they need these wrappers around the primitive types to accomplish certain tasks.

    For example, in Java 1.4 in order to put an integer value into a collection, you had to create an instance of an Integer object to hold your integer primitive because their collection classes could only hold objects and not primitives.

    Code:
    myList.add( new Integer( myInt ) );
    With java 1.5, they have introduced autoboxing to Java. Autoboxing is a shortcut where the compiler figures out what type is needed in context and automatically creates the correct wrapper object.

    In the previous collections example, the compiler knows that the add method requires an object. So if you try to pass it a primitive type, the compiler automatically "boxes" it up inside the correct wrapper.

    This is the java 1.5 equivelent of the above code (the 1.5 compiler now infers the "new Integer()" statement):

    Code:
    myList.add(myInt);
    Also, note that for efficiency reasons, these wrapper classes in java are not extensible. You cannot add your own methods to Integer or String.

    C# also has this type boxing capability.

    Obviously, there is no need for this usage of type wrapping in dynamically typed PHP.

    These wrapper classes in java also happen to have another role as a place to put certain functions that operate on that type:

    Code:
    String c = str.substring(2,3);
    There might be a place for this in PHP, but only if supported by the Zend engine. Otherwise, it is simply too inefficient for too little gain.

    The advantage to this in PHP would be to serve as a namespace allowing the same operations to have the same name.

    as Harry points out strstr($string, ...) and in_array($array, ...) could become $string->find(...) and $array->find(...)

    This would have an advantage of decreasing the mental footprint required for learning PHP.

    The disadvantage is that the old functions could not be eliminated due to backward compatibility and that would result in duplicate implementations of many functions on primitive types, thus increasing the maintenace cost and bug rate in PHP.

    This is a tradeoff that I doubt that the PHP maintainers will be willing to make.

    Without this zend support, primitive type wrappers would only make the language more complex.

    How can this:
    PHP Code:
    (new String("abcdef"))->substr(1,2);
    // is this even valid PHP syntax in PHP 5?  certainly not in PHP 4. 
    be any better than this?
    PHP Code:
    substr("abcdef"12); 
    Java just introduced autoboxing to get rid of code like this. Why would you want to introduce this complexity into PHP?

    Not to mention that type wrappers would be very inefficient in PHP because PHP is interpreted and not compiled. The Java and C# architectures are compiled and thus can be organized a bit differently.

    In PHP you pay the cost of interpreting all of the code that your program includes, even if you don't call it. This is done on every request and is NOT cheap.

    In Java and C#, the cost of unused code is MUCH MUCH lower.

    For example, if you had a String wrapper object that you loaded that implemented the 89 or so built in string functions as methods, then you would have to load this whole monster every time you wanted to perform just one string function.

    Chances are, you would just be using a couple of different string functions, so the time required to parse the implementations of the other 85 would be wasted.

    Java envy -- get over it.

  8. #33
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good thread!

    Quote Originally Posted by cyngon
    1. Should the theoretical library have objects for primitive types such as String, Integer, etc. that can be used like their Java equivalents? It would be nice to be able to do $myString->startsWith('Foo') and other operations currently encapsulated in the PHP string functions with objects.
    My opinion: No.

    It's a good question. This is something that I've wrestled with quite a bit. I created classes for all the primitive types at one point, but my (current) feeling is that they are not worth the trouble.

    Quote Originally Posted by cyngon
    2. Related to #1, should the library contain classes for Arrays, HashMaps, etc.? PHP's array support is top notch and I'd be interested to hear what people think about wrapping it in collection-type classes.
    My opinion: Maybe?

    Another good question. After going through all of Java's collection classes, the only ones that I determined to be useful (for my purposes) were ArrayList and HashMap. Why? Because PHP arrays are essentially a combination of the two: you can have both lists (numeric-based index) and associtive arrays (key-based index). By creating separate classes to handle the two aspects of native arrays you can separate out the behavior appropriately.

    That said, it's a bit like having classes for the primitive data types. They're useful but not terribly so -- you can easily get by without the OOP-ified versions.

    Quote Originally Posted by cyngon
    3. Should all classes in the library extend one base "Object" class like they do in Java?
    My opinion: Yes.

    If nothing else you can put debugging (toString?) and/or error-handling methods (throw?) in a base class. I don't know what the performance hit of this would be, but I doubt it's significant.


    I think the best approach to a PHP class library is to find a balance between OOP purity and PHP sensibility/practicality. The problem is that this balance will be different for everyone.

    I, like many others, have developed my own class library since it's the best way for me to address my needs. Personally, I like the idea of using the Java classes for inspiration. In fact, I try to base all of my own classes on the Java classes (without going too crazy about it). However, the bottom line is this: you can't please everybody so just make sure you please yourself (and people like you).

  9. #34
    SitePoint Evangelist cyngon's Avatar
    Join Date
    Aug 2001
    Location
    Livonia, MI, USA
    Posts
    513
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    [QUOTE='Selkirk']Building object wrappers for primitive types would not be worthwhile in PHP unless it was made a part of the zend engine.

    For statically typed languages such as Java, they need these wrappers around the primitive types to accomplish certain tasks.

    For example, in Java 1.4 in order to put an integer value into a collection, you had to create an instance of an Integer object to hold your integer primitive because their collection classes could only hold objects and not primitives.[/CODE]

    We don't need classes for primitives that don't need added functionality (like Integer and Float). But for cases where it would make sense for a class to encapsulate some functionality I think they may be helpful (like String and Array).

    Quote Originally Posted by Selkirk
    These wrapper classes in java also happen to have another role as a place to put certain functions that operate on that type:

    Code:
    String c = str.substring(2,3);
    There might be a place for this in PHP, but only if supported by the Zend engine. Otherwise, it is simply too inefficient for too little gain.
    I think this may be a case of premature optimization. I don't think there would be a noticable slowdown. If you include a dozen string manipulation methods in the string class, most would just be one line wrappers around the existing PHP function that does the same thing.

    Quote Originally Posted by Selkirk
    The disadvantage is that the old functions could not be eliminated due to backward compatibility and that would result in duplicate implementations of many functions on primitive types, thus increasing the maintenace cost and bug rate in PHP.
    There are implications like those if the library was in the PHP core, but in this thread we have been talking about writing such a library in PHP and completely seperate from the core.

    Quote Originally Posted by Selkirk
    How can this:
    PHP Code:
    (new String("abcdef"))->substr(1,2);
    // is this even valid PHP syntax in PHP 5?  certainly not in PHP 4. 
    be any better than this?
    PHP Code:
    substr("abcdef"12); 
    As with most OOP designs the benefits are seen in the complex cases. There are a lot of inconsistencies in the PHP string functions, for example, and across a large program it would be better to use String objects because of the consistency they can provide. One should not have to look at the PHP manual to remember if a function accepts the needle or haystack first.

    Quote Originally Posted by Selkirk
    Not to mention that type wrappers would be very inefficient in PHP because PHP is interpreted and not compiled. The Java and C# architectures are compiled and thus can be organized a bit differently.

    In PHP you pay the cost of interpreting all of the code that your program includes, even if you don't call it. This is done on every request and is NOT cheap.

    In Java and C#, the cost of unused code is MUCH MUCH lower.
    First off, the String class would not be interpreted if the application does not use it anywhere. This can be accomplished with autoloading. Second, I don't think the performance hit would be noticable in a real application. Third, there are a myriad of caching solutions that most performance sensistive PHP applications already use.

    Quote Originally Posted by Selkirk
    For example, if you had a String wrapper object that you loaded that implemented the 89 or so built in string functions as methods, then you would have to load this whole monster every time you wanted to perform just one string function.
    I think the number of manipulation functions could be half of that or less with a proper design. And most of those methods would be less than 5 lines long.

    Quote Originally Posted by Selkirk
    Chances are, you would just be using a couple of different string functions, so the time required to parse the implementations of the other 85 would be wasted.
    Again, I think the performance hit would be negligible in all but the simplist applications.

  10. #35
    SitePoint Evangelist cyngon's Avatar
    Join Date
    Aug 2001
    Location
    Livonia, MI, USA
    Posts
    513
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by codezilla
    My opinion: Yes.

    If nothing else you can put debugging (toString?) and/or error-handling methods (throw?) in a base class. I don't know what the performance hit of this would be, but I doubt it's significant.
    Since PHP is dynamically typed all objects that wanted to be easily loggable could implement a toString function without having to derive from a base Object class with a toString function. I recommend reading the links Selkirk posted about dynamic versus statically typed languages.

    Error handling in the library will be done with PHP5's try/catch/throw functionality.

  11. #36
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Off Topic:


    Quote Originally Posted by cyngon
    Error handling in the library will be done with PHP5's try/catch/throw functionality.
    I've noticed the PHP5 doesn't have try/catch/finally

  12. #37
    ********* wombat firepages's Avatar
    Join Date
    Jul 2000
    Location
    Perth Australia
    Posts
    1,717
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cyngon
    If you include a dozen string manipulation methods in the string class, most would just be one line wrappers around the existing PHP function that does the same thing.

    .....and across a large program it would be better to use String objects because of the consistency they can provide. One should not have to look at the PHP manual to remember if a function accepts the needle or haystack first.
    This is the point where the whole point of PHP is being missed (by a mile IMO) and where the option 5) use JAVA (or whatever) is the better option.

    in fact ... that is just strings ... you can go on to replace all of PHP's inbuilt functionality with wrappers for a more consistent interface ... but at that point Its more efficient to option 6) rewrite in C/C++


    [again , I have no doubt that advanced string manipulation classes have merit , but to abstract away the basics (and then have to load them) seems a waste of time and resources]

  13. #38
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cyngon
    Error handling in the library will be done with PHP5's try/catch/throw functionality.
    That's fine and all, but PHP5 is not out yet, nor will it be out for a while. Furthmore, it will be even longer before web hosts start installing it. As far as I'm concerned, due to the type of client I typically do work for, until PHP5 is widely supported there's no reason to use PHP5-specific features.

  14. #39
    public static void brain Gybbyl's Avatar
    Join Date
    Jun 2002
    Location
    Montana, USA
    Posts
    647
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've already done this -- It's called (not very clever)

    Japha
    http://japha.xzon.net

    It includes http, iterator, land, pdbc (jdbc but with a p ;]), swing, util, and xml packages.

    I really don't know if it's anything to write home about, but I was quite pleased with it.

    One stipulation -- It only works with PHP 5.

    I encourage anyone who is looking for something like this to try it out. I just wrote it because I felt that there were classes that I kept rewriting, so I just packaged them all in a nice format. They are based off of the 1.4.1 Java API.

    Btw, It's not exactly the most mature library out there, and there are probably quite a few bugs. But then again, it's only at 0.3 status.

    I've just realized that this probably seems like a shameless self-boosting scam -- It's not. It's 100% on topic.

    But again, on topic. Yes, I think that it would be nice to have a set of reusable classes (NOT PEAR) to be able to plug into whenever you need. That's why I made Japha. =]
    Ryan

  15. #40
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    I thik firepages is right on target here. While having all this functionality would be nice, this is PHP. If all that sort of stuff is what you're looking for, there is .NET and Java.

    Having said this, I personally can live without a class library but I love the object base that C# has, being that variables are objects, and I intend to write something like this for PHP, just like Object (base), String, Int, Bool, and Array.

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

    Exclamation

    Hi. I am going to be less than nice in what follows because I think things are going off topic a little. You may want to look away now...

    Whilst I am a fan of "pure" languages (things like Ruby, Smalltalk, CLOS) I recognise that it is the impurity of PHP that has made it one one the easiest languages to learn there has ever been. If you want to wrap some of these rough edges in oodles of string wrappers then you would have to accept that such a library will have a conceptual barrier to entry.

    No one ever reuses a library they don't understand.

    In the case of wrapping PHP strings it would mean learning two APIs (you will still need the old one) and adding...
    PHP Code:
    new String() 
    ...around everything.

    No one ever reused a library that caused them more work.

    The concept is also a little ugly. Actually it's very ugly. One deep rooted programming principle is to avoid repetition. The very first refactoring I would do on such a beast would be to strip out all of this pointless string wrapping. The rather random ordering of PHP parameters is also a non-issue. Your IDE will prompt you for the parameters and if you get it wrong it is the kind of error that your unit tests will show up immediately.

    No one ever reused a library that forced them to change all their existing code.

    You should wrap exceptional cases in classes, not the common ones. I agree that performance is not really relevant to this, but as engineers we come up with a best compromise with the equipment available. Wrapping every string is more of a philosophical objective for some vague future cleansed nirvana. Nice possibly, but we have to weigh it up against todays immediate difficulties. Is your home toolbox pragmatic or philosophical?

    No one ever reuses a library without first having an immediate use.

    Now I applaud all of you people for being influenced by other languages, a developer that codes only one is like a musician that plays within only one musical genre. No language concept is perfect though. All are good at some things and bad at others and PHP is proven (by popularity) to be good for web development.

    Back to a small cohesive refactored peer-reviewed class library...

    If anybody wants to start such a project or adapt an existing one I have piles of stuff just sitting around waiting to be thrown into the collective pot. I would be happy to help moderate also, but am a little tied up with paid work and SimpleTest to do anything too proactive.

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

  17. #42
    public static void brain Gybbyl's Avatar
    Join Date
    Jun 2002
    Location
    Montana, USA
    Posts
    647
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by anode
    This is of course why you need well-designed APIs and why PHP doesn't have a class library.
    But this would apply to any language -- The main reason that PHP doesn't have a class library is that it was never meant to be an OOPL. It's been bent and contorted to that status by overuse and incorrect use. PHP 5 is an attempt to fix the problems (not an attempt, more like a success =D).

    PHP does have a library, it's just not packaged into classes (it could still be object oriented if used the right way, though). You would be hard pressed to find another language anywhere that has as large a *built-in* API as PHP. If you do find one, though, let me know, because I would love to try it out.

    =]
    Ryan

  18. #43
    public static void brain Gybbyl's Avatar
    Join Date
    Jun 2002
    Location
    Montana, USA
    Posts
    647
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's fine and all, but PHP5 is not out yet, nor will it be out for a while.
    PHP5.0.0 beta 1 came out a couple of days ago. I've been using the alpha builds for >3 months and haven't had any real consistency or reliability issues. But then again, I haven't been doing HUGE requests on it, just testing Japha classes.

    Quote Originally Posted by codezilla
    Furthmore, it will be even longer before web hosts start installing it.
    Mass Production web hosts, that is. It doesn't take much to turn your own computer (or a relatively old computer, for that matter) into a fully functional web server running apache and php5.

    Quote Originally Posted by codezilla
    As far as I'm concerned, due to the type of client I typically do work for, until PHP5 is widely supported there's no reason to use PHP5-specific features.
    I'm sure if you told your client that you could get your work done faster, cleaner, and sexier, they would be happy to wait. =] Just make sure you use the word 'sexy.' ;]

    Where there's a will, there's a way... =D
    Ryan

  19. #44
    Sidewalking anode's Avatar
    Join Date
    Mar 2001
    Location
    Philadelphia, US
    Posts
    2,205
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Gybbyl
    But this would apply to any language -- The main reason that PHP doesn't have a class library is that it was never meant to be an OOPL. It's been bent and contorted to that status by overuse and incorrect use. PHP 5 is an attempt to fix the problems (not an attempt, more like a success =D).
    I was being too idiomatic. I meant that PHP doesn't have a class library because APIs are hard to design, and nobody has been able to sit down and do it for PHP yet.
    TuitionFree a free library for the self-taught
    Anode Says... Blogging For Your Pleasure

  20. #45
    public static void brain Gybbyl's Avatar
    Join Date
    Jun 2002
    Location
    Montana, USA
    Posts
    647
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by anode
    APIs are hard to design, and nobody has been able to sit down and do it for PHP yet.
    Ah, that makes good sense now, and I agree to some extent. But have you used Eclipse? I don't use it on a regular basis, because it's alot of overhead to add that much stuff to your project, but it does include some good classes, and not to mention functional ones.

    It also seems that v.oostind wrote that library in his own particular... erm... *idiom, sir* IDIOM.

    ;]
    Ryan

  21. #46
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Really is a fascinating discussion

    One thing on the String discussion - using PHP's object overloading it would pretty much be a case of writing a switch statement - I haven't checked out overloading in PHP5 yet but with 4 it's something like this;

    PHP Code:
    <?php
    class String {
        var 
    $string;

        function 
    String ($string) {
            
    $this->string=$string;
        }

        function 
    __call($method,$params,$return) {
            switch ( 
    $method ) {
                case 
    'strstr':
                    
    $return strstr($this->string,$params[0]);
                break;
                case 
    'substr'
                    
    $return substr($this->string,$params[0],$params[1]);
                break;
                
    // etc.
            
    }
            return 
    true;
        }
    }

    overload ('String');

    $string = new String('Hello World');
    echo ( 
    $string->strstr('lo Wor') );
    echo ( 
    $string->substr(2,5) );
    ;
    ?>
    Such classes would be reasonably minimal although I agree with the very valid points that implementing primitive types this way is most likely overkill.

    There are other areas though where I think PHP's native functions could be unified well with some well thought out classes, in particular where file related operations are concerned (and as has already been done many times with the DB related stuff) and perhaps the new XML stuff. That said there's some stuff turning up in the manual related to PHP5 such as stream_context_create() which makes me wonder is Streams isn't going to sort alot of this out.

    If anybody wants to start such a project or adapt an existing one I have piles of stuff just sitting around waiting to be thrown into the collective pot. I would be happy to help moderate also, but am a little tied up with paid work and SimpleTest to do anything too proactive.
    Likewise if there's a leader out there with time to spend on this, got ideas and code that I'd be will to throw in. Time is in short supply for me though...

  22. #47
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Well overload() isn't a valid PHP5 function

  23. #48
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well overload() isn't a valid PHP5 function
    I think they've made this automatic (I've seen very few examples of how this will work with PHP5) so you should be able to use the overload "magic methods" __call(), __get() and __set() (there may be more) without using the overload() function.

    Try this (don't have PHP5 ready to use from where I am right now so this may need tuning);

    PHP Code:
    <?php
    class Test {

        function 
    foo () {
            echo ( 
    'This is the real foo' );
        }

        function 
    __call($method,$params,$return) {
            echo ( 
    'This comes from __call()' );
        }
    }

    $test = new Test();

    $test->foo();

    $test->bar(); // This call is routed to __call()
    ?>
    There's a whole load of good stuff this could be used for, from very minimal "Decorator" classes to all sorts of stuff I haven't though of yet but looking at Python, there's plenty to get inspiration from.

  24. #49
    ********* Wizard silver trophy Cam's Avatar
    Join Date
    Aug 2002
    Location
    Burpengary, Australia
    Posts
    4,495
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Well I'm lost

    I just tried running your code to post the output but I got an error, unexpected string on line 4, line 4 is function foo() {

    But now that you mention it, I just remembered that I have used __call() before but never __get or __set.

  25. #50
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I just tried running your code to post the output but I got an error, unexpected string on line 4, line 4
    Think that's the usual grief with cut & paste code via these forums - get wierd things happening with whitespace that isn't quite what it seems to be. Try writing that example from scratch as a new file.


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
  •