Is PHP's OOP implementation complete?

On the return type thing I am in the very pro camp. There has been many rfcs on it alread ybut I believe Sarah Goldman and her facebook crew are doing some very cool things in the HHVM( virtual machine hip hop) world with generics, return types I think in AS3 format etc… Trying to find documentation though is quite hard but personally if the facebook version gains solidity it may be the version to bet on. Fragmentation is bad but the needs of the community is already heavily fragmented.

And how do you go about having different const values for different instances? Answer: You don’t. Think value objects?

For getters/setters, you can use the magic methods __get() and __set(). Or, define your own functions. Or, make the variables public and access them through the object.


class thing {
public $attribute=null;
} 

$newthing = new thing();
$newthing->attribute='blue';
echo $newthing->attribute;

Don’t want to. Just unnecessary clutter. Which is the point.

If you want documentation to appear, use PHPdoc syntax, which can be parsed in most IDEs that supports PHP.


/**
* function description here
* @param string $input some comments here
* @return string some comments here
*/
function testme($input){
return $input;
}

Don’t want to. Unnecessary clutter. I can almost always determine what the input values do by their names. Likewise, given the type I can usually determine the expected return value. No need to have extra annotations.

I think some of this boils down to partly unfamiliarity with PHP

At last something we can agree on!

and partly wanting it to be something it is not.

Which is sort of the point of having a wish list.

I’ve actually heard/read that a lot over the years (that PHP isn’t for big/enterprise projects, blah blah blah) & unsurprisingly almost 99% times the people who’ve ranted about it are the ones who don’t know jack about what they were talking. I guess Facebook, Yahoo, Flickr, Wikipedia etc just don’t know what they’ve been doing for years! I just ignore such (not so) well-informed & opinionated people now. :wink:

Wishing for a speedboat to be able to fly above clouds would be classified as a fantasy! :lol:

I love PHP. I really do, it pays my bills, mastering it gave me a new career. Still, I can’t help but think its fate will eventually be the same as COBOL’s, an archaic language with a lot of stuff written in it that no one wants to touch. PHP has a lot of design mistakes that can’t be removed - if they could you’d have a much cleaner, easier to use and read language. As it stands though, the community is used to the warts and continues making code in spite of them.

Looks like PHP developers have rejected the idea of metaprogramming, at least with runkit ever making it to the core of PHP. This is too bad, but hey at least I was courageous enough to actually write a feature request ticket to PHP, and someone took the time and trouble to respond. XD

https://bugs.php.net/bug.php?id=65459

Perhaps I should try namespace wildcard import next time? Although the chance of each feature request gets approved is low, there is a fair chance for at least one of all those requests being accepted if all of them reach PHP developers.

Ok, in that case:


class thing {
    private $attribute = null;

    function __construct($attr){
         $this->attribute=$attry;
    }

    function getAttribute(){
         return $this->attribute;
     }
}

$newthing = new thing('something');
echo $newthing->getAttribute();

That essentially allows you to set the variable once, and get it at any time.

You could use serialize/[URL=“http://php.net/manual/en/function.unserialize.php”]unserialize to shoehorn arrays and objects into a const.

Umm this… I thought PHP class constants must be declared and defined upon you write the class? Is it even possible to do this?


class MyClass{
    const constObject;

    public function __construct(Object $object){
        self::constObject = serialize($object);
    }
}

Otherwise, you will have to actually know the serialized string representation for the array or object, not a good idea I guess…

Yep, they have to be defined upon initialization. If you want to set a variable just once, you’ll likely have to use something similar to the example I provided.

Otherwise, you will have to actually know the serialized string representation for the array or object, not a good idea I guess…

No, it’s no ideal. I was mainly simply commenting on the fact that it was possible.

Arrays are easy to serialize. Objects…take a bit more code acrobatics: http://php.net/manual/en/language.oop5.serialization.php

I did say “shoehorn”, after all. :wink:

A possible example:


define('PERMISSION_ADMIN','Administrator');
define('PERMISSION_EDITOR','Editor');
define('PERMISSION_GUEST','Guest');
define('PERMISSIONS,serialize(array(PERMISSION_ADMIN, PERMISSION_EDITOR, PERMISSION_GUEST)));

$dataUserPermission='Editor'; //from database, $_POST, or wherever.

if(in_array($dataUserPermission, unserialize(PERMISSIONS)){
    echo 'is valid';
    if($dataUserPermission==PERMISSION_EDITOR){
          echo 'is editor';
    }
}

I’m new to OOP, can you help me understand what each of those principles are?

P.S. I looked at the Syntax Hiliter in your sig for WP, did you code that?

http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

I don’t think I would want this in PHP considering the fact that objects in PHP result in a pretty performance overhead. Primitive types like strings and arrays are used very often so this could have tangible negative consequences.

For example, PHP 5 introduced DateTime class with their methods - they are very convenient but when I used them for date and time conversions where I had to create a DateTime object and a DateTimeZone object for each conversion - when I put in a loop it resulted in a huge performance penalty on pages with hundreds of dates. I certainly wouldn’t want to deal with such problems while using strings and arrays. Maybe if PHP were a compiled language, then yes.

PHP must be practical for being used on the web so performance is very important - it’s all about compromise.

Well you have a point when it comes to certain data types such as primitive numbers and boolean values, but Id still say a good object oriented language needs at least Strings and Arrays to be objects. Every well-known object oriented programming language does it this way, in Java and C# strings and arrays are objects, while in Ruby everything is an object(and for some reason, the overhead issue does not seem to be a big concern). Not sure with Python though, but its also considered a more object oriented language. PHP needs to catch up on this aspect, I like what features they’ve brought in but its not sufficient yet. On the other hand, I doubt PHP’s DateTime class is even fully optimized at this point, which may be part of the cause of your problem?

Well, C++ is the grand daddy of Java/C# and is probably much more widely used then either. However, just like php, C++ lets you use objects for strings and arrays if you want but also supports the primitive types. PHP already has a several array like interfaces so it’s easy enough to make objects act like arrays. Defining a master String interface would be nice as well as a reference String implementation that was unicode based.

The DateTime class has a procedural way of doing things, in addition to the OOP way. I’d be interested to see if there is a performance difference between the two or not.

See example #1: http://php.net/manual/en/datetime.construct.php
Also see this date formatting example: http://www.sitepoint.com/forums/showthread.php?1163494-Formatting-Dates&p=5554889&viewfull=1#post5554889

C is the precursor to C++, Java, and C#. C++ didn’t directly lead to Java and C#, although all these languages did have a part in influencing each other.

C++ is one of the top programming languages, but not the top. Here are some stats, but take them with a grain of salt: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Or you could use __get() magic method do this:


class thing {
    private $attribute;
    private $some_var = 'pqr';

    public function __construct($attr) {
         $this->attribute = $attry;
    }

    public function __get( $var_name ) {
         if( isset( $this->$var_name ) ) {
             return $this->$var_name;
         }
     }
}

$newthing = new thing( 'something' );
echo $newthing->attribute;

I didn’t say its not possible currently, I said it would reduce the extra work of adding getter methods.

Yes but that’s unnecessary extra work. :wink: I’d also like the ability to initialize class constants with value from a function output or for the ability to use final properties.

Yup

Why? Doesn’t that defeat the purpose? or at the very least a bit ironic?

You can test it easily if you want. In my specific case I needed to do timezone conversion. What I discovered was that simply passing new DateTimeZone() to the DateTime constructor produced noticeable overhead. Sure, using it a few times doesn’t make much difference but if I need to do many more conversions in a loop and then it begins to matter. I ended up in constructing DateTimeZone once and caching it in a static variable, which helped a lot in that case.

If I have to deal with such problems then I would prefer time zone to not be an object in the first place.

String and array manipulation is a very common task so that’s why I wouldn’t like them to become slow just for the sake of OO purity. I don’t know how other languages manage this problem. If PHP were able to cope with it well then I wouldn’t mind.

From what I see the DateTimeZone class may not be well optimized, it wont surprise me though.

Yeah, Id definitely be interested in finding out how more complete object oriented languages handle string as object, as they do not turn out to be much slower, maybe not even slightly slower. Apparently there are still ways to optimize classes/objects that PHP needs to explore, after all object instantiation does have overhead but should be negligible compared to the real overheads such as database connection and execution.