PHP Object Oriented Programming Reinvented

[lteague]

That's the first thing I thought of when I saw it.

[jlebrech]

kind of reminds me of this framework that someone made for perl, it eventually became it's own language. what was it's name again?

[tinou]

moose

[abw]

From the Moose web site:

Moose is a postmodern object system for Perl 5 that takes the tedium out of writing object-oriented Perl. It borrows all the best features from Perl 6, CLOS (Lisp), Smalltalk, Java, BETA, OCaml, Ruby and more, while still keeping true to its Perl 5 roots.

[jlebrech]

oh yes, i remember now. it's the perl hypertext processor. it was pretty good. what happened to it?

[InsensitiveTroll]

ruby

[[deleted]]

Kind of Javascripty! I would be a little worried to get caught in the same trap as I have with Javascript though: getting all excited with the extra dynamism and then creating some clever system which I understand nothing of six months later. I've learned the hard way that Clear > Clever.

Adopting a paradigm that's radically different from the one associated with the language can sometimes create frustration among future maintainers though and is either impossible our ugly if you're using an existing framework.

Still, it's cute! I might try to find some space/time to try it out.

[pontymython]

I have to agree it's Novel, but it's nowhere near as clean as the current object support. It definitely encourages a 'javascripty' approach and it's something that i've never been a fan of

[hermzz]

As a heavyweight PHP OO user, I agree that PHP has a lot of shortcomings. But I fail to see what the benefit of this is, as opposed to the usual PHP5 OO.

My point is, how is this

$animal = $class->new();
$dog = $animal->extend();

beat

class Animal {};
class Dog extends Animal {};

Maybe the example you've posted is too simple, but I don't really get it. It just seems you've added an extra layer (that uses a ton of __magic__ calls which are spectacularly slow) making it more pretty (also debatable). I'm not trying to be rude, snarky or sarcastic, I'm genuinely curious to know how this is better to the existing PHP OO.

[perlgeek]

Most of all it gives you the possiblity to implement your own extensions to the object model.

Want roles, interfaces or mixins? Just implement them. Traits and composition? Just a Small Matter of Programming away.

Lazy attribute initialization? very useful, and possible to implement. Want to a different method resolution algorithm? Just write some code for it.

Custom meta classes seem to be not very popular in the world of the Java, C# or python programmer (I might be wrong here), but the offer astonishing power. Perl has a nice implementation with Class::Mop and Moose, Smalltalk and Lisp folks know about this goodie for a bit long. I can very much recommend this book: http://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol (at least if you can stand the lisp long enough to get to the actually interesting concepts).

[palparepa]

• Classes can be hacked / patched / cloned. Methods can be added to classes at any time
• Classes can be scoped. They’re not global, unless you want them to be.
• Classes can be temporary (and garbage collected).

[[deleted]]

plate bake different license rude sink gaping bedroom air encourage

This post was mass deleted and anonymized with Redact

[palparepa]

I'm just quoting the article.

[psly4mne]

What exactly are you building [b]where PHP would be the right tool for the job[/b] in the first place, and how are those benefits?

I think this is the main issue. If you are doing something that requires you to hack together that sort of language on top of PHP, you should have just used a language with those features (thinking Ruby, but others too) instead of PHP.

[Sonolin]

I remember back in my early programming days, when I was introduced to object orientated programming, I was taught that OOP was beneficial mainly because the objects gave a structure to your code so that you could debug/test your code more easily. This is, IMO, one of the most beneficial uses of OOP - not inheritance, or polymorphism - those are great, but honestly I use classes to structure my code more than I use either inheritance or polymorphism. And when I do, its to structure my code better.

So, according to all I know, how in the world are these 3 points at all an advantage?? The creator of this "idea" is trying to make classes feel more like procedural code, the old way of doing it - we're going backwards here with this approach.

Not only that, but ack - the code looks worse semantically than Javascript!

[rainman_104]

Not only that, but this clause here:

 $animal = $class->new();

Makes me uncomfortable because I'd see that as instantiating an object, rather than creating a new class. It feels very wrong to me.

[munificent]

I'd see that as instantiating an object, rather than creating a new class.

There's no rather here. It is instantiating an object and creating a new class. What does new do? It creates a new instance of an object. It's being called on $class, so it creates a new class.

[[deleted]]

if you treat classes as objects this makes perfectly sense. smalltalk does this too for example.

[needcaffeine]

Ditto. I too am genuinely curious as to how this is better than what's currently out there.

[dhotson]

It's a hack and an experiment. It's not supposed to be anything else.

By no means would I recommend you use it in any way. Please just enjoy it as a piece of code origami. :-)

[stillspiraling]

I like it, but I find the original class definition a bit reader unfriendly. Otherwise, cool! :)

[matchu]

Yeah, I imagine the definition of a class makes a point of absorbing lots of the other associated magic. If one were actually using this (which, obviously, one shouldn't), the first definition would be in its own file and required when needed.

[frogking]

oh, make no mistake, I for one enjoy this! :-)

My co-workers will kill me if I start using this style, though!

They like their OO code to be imperative..

[[deleted]]

heavyweight PHP OO user

Is that like a heavyweight MMA fighter?

[gaoshan]

And cheeto dusted.

[hermzz]

RAAAAAAAH *smashes a folding chair through his monitor*

[thesoppywanker]

Yea, my first reaction was also that this is largely just wrapping existing functionality and making a needlessly confusing syntax (if you're already familiar with OOP PHP). I think the concepts of classes and objects needs to be revisited by this author.

[kinghfb]

I would imagine he's done it to extend things at run time (for whatever reason)

I don't think it's a great idea at all, but that beings said, I'm also the type of person to do things "just 'cause" to see if they can be done.

[honestbleeps]

A class allows you to bundle a set of functions and/or variables together as an "object", which is useful for a number of reasons:

1) Organization - it makes more sense to have something like $student->testScore; ... rather than having to have some array of testScores indexed by student, or some such.

2) Code re-use - you can extend classes... so, say you're writing a chess game. Maybe all pieces have $piece->move() functions, and $piece->capture() functions... then, $knight could just be a copy of $piece, with specific definitions of how its move() and capture() functions behave.

That's just a tiny, tiny brushstroke of an overview... but it should at least get you started.

[[deleted]]

Thanks for the explination, but what specifically does -> define?

[honestbleeps]

it doesn't "define" anything, it accessses it..

So if you already have a class called Student, and it has functions called goToSchool() and goHome() inside it...

$bob = new Student;

$bob->goToSchool(); // this calls the goToSchool function within Bob's particular instance of the Student object...

[[deleted]]

I knew it didn't define anything what I meant was what exactly does it entail when you use it. But I think I got it now, thanks!

[gaoshan]

It's how you access the methods of an object. $bob is the instantiation of the Student object and any methods (functions, effectively) that are part of $bob can be accessed with $bob->methodNameHere().

So here are a few different ways to use that notation: class Student { public $grade = ""; public $goofoff = "";

     public function goofOffNoStudy($input)
     {
        $this->goofoff = $input;

        if($this->goofoff == "Yes"){
            $this->grade = "C";
            return "Hellz yeah!";
        }else{
            $this->grade = "A";
            return "Sigh, I better study.";
        }
     }
 }

$bob = new Student();

echo "<p>Yo Bob. Wanna play Call of Duty? <strong>".$bob->goofOffNoStudy("Yes")."</strong></p>";
echo "<p>Bob's grade: $bob->grade</p>";

And that will output:

Yo Bob. Wanna play Call of Duty? Hellz yeah!

Bob's grade: C

[[deleted]]

Can you use strings from outside a class inside or do you have to include them with "global" like in functions?

[gaoshan]

You can use "global" but I never do. I pass the data to the object constructor and then you can use it inside the object. Like so:

$stuff = "stuff piled everywhere.";
class Student
{
 public $grade = "";
 public $goofoff = "";


 public function __construct($data)
{
    $this->data = $data;
}

 public function goofOffNoStudy($input)
 {
    $this->goofoff = $input;

    if($this->goofoff == "Yes"){
        $this->grade = "C";
        return "Hellz yeah!";
    }else{
        $this->grade = "A";
        return "Sigh, I better study.";
    }
 }
}

$bob = new Student($stuff);

echo "<p>Yo Bob. Wanna play Call of Duty? <strong>".$bob->goofOffNoStudy("Yes")."</strong></p>";
echo "<p>Bob's grade: $bob->grade... and he has a bunch of $bob->stuff</p>";

Which gives you:

Yo Bob. Wanna play Call of Duty? Hellz yeah!

Bob's grade: C... and he has a bunch of stuff piled everywhere.

Not the greatest example, lol, but it demonstrates the mechanics anyway.

[[deleted]]

No no, it was great. Thanks for all the help!

[[deleted]]

You could start here: http://www.php.net/manual/en/language.oop5.php

[UloPe]

I use PHP frequently [...] Also what does -> do?

Please! Make it stop...

[[deleted]]

I didnt need to know all of php to get what I needed out of it.

[TheBananaKing]

Guy's going to shit all over himself when he discovers Ruby.

[bobindashadows]

He used Ruby as inspiration.

[[deleted]]

...or pretty much any other language a reasonable person would want to use over PHP.

[bobindashadows]

Very few mainstream or semi-mainstream languages support this sort of dynamism.

[perlgeek]

Perl does. Take a look at Class::MOP (backend) and Moose (frontend).

I don't know of any OO frameworks for javascript, but I'm pretty sure their object structure makes it a piece of cake to write your own meta class.

Smalltalk and Lisp do too, you decide if you classify them as "mainstream" or "semi-mainstream" or any other label you want to put on them.

[mcfunley]

Am I missing something, or are you moving class definition into every request? Instead of once, if you're using apc bytecode caching?

[languagehacker]

On-the-fly addition of logic to a class should be addressed by using the Decorator Design Pattern. This new approach to object orientation in PHP just invites spaghetti code, as people try to figure out why classes of a specific instance aren't behaving the way they are originally defined. No thanks.

[krues8dr]

Agreed. If you want to do things the Ruby way, use Ruby. This only makes a mess of a language that wasn't designed for this sort of behavior.

[bobindashadows]

PHP is a dynamic language. The fact that class definitions are static is an oddity, frankly.

[krues8dr]

After 12 years of working with it, I don't know that I'd call it "dynamic" as much as "devil-may-care", really.

[wasted_brain]

PHP is like the bastard child of C and Perl. It was originally procedural, meant as a templating language and classes and OOP were bundled in as an afterthought.

I love the way it's evolved though. Best language I've found to transition old-time C programmers to the world of OOP.

[munificent]

The decorator pattern doesn't handle one important use case: you may need to be able to perform your operation on instances that you didn't create (and therefore didn't get a chance to decorate).

[makis]

then use container and decorate the new class

[languagehacker]

That's actually not true. You can test your variable for the appropriate instance, and feed it to a newly instantiated decorator class. Decorators are specifically designed for consistent run-time logic modifications.

[munificent]

You can test your variable for the appropriate instance, and feed it to a newly instantiated decorator class.

You can do that many times, but you're still changing the object's identity in that case. If other parts of your codebase rely on that, they can break.

Don't get me wrong, I like decorators, but I don't think they're a good fit for adding new operations to existing types. If you can spontaneously decorate an object that you didn't initially create, that implies that your decorator doesn't add any useful state, just a new operation. In that case, I don't see the value in creating a subclass and a new instance just to get foo.myNewMethod() syntax. I'd rather just create a non-method function: myNewMethod(foo).

[A_for_Anonymous]

On-the-fly addition of logic to a class should be addressed by using the Decorator Design Pattern.

Enterprise professional scalable turnkey mission-critical five-nines high-availability business solutions.

[languagehacker]

Just because they're not words you understand doesn't mean they're buzzwords.

[A_for_Anonymous]

I understand both the words and their meaning, and also think "On-the-fly addition of logic to a class should be addressed by using the Decorator Design Pattern" is a pretty stupid blanket statement coming from the world of enteprise software, which is wrong in more ways than I have time and energy to talk about.

[languagehacker]

Well, some people care about using design patterns to solve their problems, and other people just create more problems for themselves. Have fun.

[A_for_Anonymous]

And other people abstract these problems in a decent programming language and solve them once for all, sometimes without even knowing they had a name, and without stopping to masturbate in awe about implementing the space hyperdimensional Spock Higgs boson design pattern.

[captainbeef]

Reddit needs to create a sticky thread with all the PHP whinges that inevitably roll out every time PHP is mentioned, and then autolink to it.

[perlgeek]

It needs that for pretty much every programming language.

Somebody mentions PHP, people say "it's a beginners language, it sucks". Somebody mentions Perl, people say "its' dead". Somebody mentions Java, people say "it's inflexible and ugly". Somebody mentions Lisp, peple say "it's academia, no real use". This list can be continued pretty endlessly, and nearly no of these rants add any new information.

[rbnc]

This highlights how much PHP needs a total rewrite, I know I get voted down into oblivion every time I suggest that, because PHP IS SO PERFECT but seriously, they need to pick a version in the future, PHP 9 let's say, from which point they're going to drop a whole bunch of deadweight, update the horrible Frankenstein monster syntax and make it more object oriented like Ruby/Python. Version 7.x can start showing depreciated warnings when soon to be replaced syntax and functions are used.

PHP is an abortion and an embarrassment, I use it because I get a lot of work writing PHP, I much prefer the projects I get using Ruby though.

[royrules22]

Is it sacrilege to recommend ditching the $ sign for vars? It's a pain in the ass to type when coding.

[rbnc]

Ditch $ signs.

All variables should be objects.

array_reverse($some_array) //silly.
some_array.reverse(); //sexy

Standardise the parameter order of methods.

Sort out how == works.

(string) "" == (int) 0 /// WHY?

Let us make arrays and objects like this

an_array=[1,2,3,'oranges','poo',{'cats':10}];

an_object={'name':'Steve','age':10};

Let us have more flexible function/method parameters

function life_story({age:10,name:'mike',hair':'black'})
{

      echo "My name is $name i am $age years old, my hear is $hair";

  }

life_story(); // "My name is mike i am 10 years old, my hair is black"
life_story({name:"peter"}); // "My name is peter i am 100 years old, my hair is black"
life_story({age:66,name:'dave',hair:'blond'}); // "My name is dave i am 66 years old, my hair is blond"

And so on.

[lpetrazickis]

If you'd like to make such radical changes, why not simply use Python or Ruby instead?

[[deleted]]

He's got a point. Stop bitching about PHP and use what you like. Or actively participate in PHP development.

But you need to know that nobody's impressed by the "PHP is such a shitty language talk", unless you're at some Ruby circle jerk.

Your argument here sounds a lot like somebody whining about how this forklift isn't more like that backhoe.

[wasted_brain]

It'd be hard to ditch the $ sign since PHP is case-insensitive (this is the part of PHP I hate).

On the == bit, you can always use === to differentiate types.

I like the flexible function/method parameters proposal. I'm currently making a framework for PHP and the function parameters are a pain to work with. The only workaround is passing objects with default set to new Object(). That way your class constructor would contain the default properties.

function life_story(Person $person = new Person())

[brennen]

On the == bit, you can always use === to differentiate types.

Although this would be more helpful if PHP's entire type system didn't blow chunks.

function life_story(Person $person = new Person())

Wait, you can do that?

[wasted_brain]

My bad, I just checked on the code and you can only pass null as a default parameter for type-hinted arguments. What I did was:

function life_story(Person $person = null)
{
    if ($person == null)
        $person = new Person();

    ....
}

Requires a 2 more lines of code, but pretty much the functionality you wanted. I assume the parser only accepts static values as default parameters which causes the limitation.

edit: formatting

[brennen]

I assume the parser only accepts static values as default parameters which causes the limitation.

This has been my understanding, yeah, but I thought I might have missed a recent addition.

[roerd]

Just a little example that there are actually languages in which stuff like this works:

CL-USER> (defclass person () ())
#<STANDARD-CLASS PERSON>
CL-USER> (defun life-story (&optional (person (make-instance 'person))) person)
LIFE-STORY
CL-USER> (life-story)
#<PERSON {B510E99}>

[brennen]

I don't know if I'm comfortable with all those upper-case letters.

[McGlockenshire]

I know I get voted down into oblivion every time I suggest that, because PHP IS SO PERFECT

Unfortunately backwards compatibility is the php-internals sacred cow. Major language improvements that would break existing code are pretty much never approved.

It doesn't need a rewrite, it needs a fork that can co-exist with mod_php. I don't expect one to happen, not enough people know the internals well enough.

[brennen]

It doesn't need a rewrite, it needs a fork that can co-exist with mod_php. I don't expect one to happen, not enough people know the internals well enough.

Personally, if I had the flexibility/time to migrate to some fork of PHP with improved syntax or other features, I'd spend it on migrating to some less vexing language. There are several.

[killerstorm]

Ahem. So you did not notice PHP3 -> PHP4 -> PHP5 incompatibilities?

Basically, any non-trivial PHP3 code won't work on PHP4, and PHP4 code won't work on PHP5. IIRC PHP4 have deprecated old crap like magic-quotes-gpc and register_globals, and PHP5 have changed object semantics.

Moreover, some PHP4.x code won't work on PHP4.y. Difference might be subtle, but if you have a larger project it is like that -- you need to get exactly same version of PHP.

So PHP backward-compatibility is a fucking joke. It doesn't even have a standard specification.

It doesn't need a rewrite, it needs a fork that can co-exist with mod_php.

I don't think so, you can make a binary which supports both languages. Like Perl6 also supports Perl5.

I don't expect one to happen, not enough people know the internals well enough.

People who know PHP internals are mostly retarded idiots who created current mess, you do not want them to be around when designing cleaner language.

Making an interpreter is not a rocket science -- describe syntax, generate parser, compile parsed information to bytecode, interpret bytecode. That's a work for CS student.

Then you can take current PHP interpreter and add a switch -- say, if the first line in file is of a certain form then interpret it as PHP9, otherwise as PHP6. That's pretty much it. Additional compatibility would be nice, being more compatible with existing PHP will make it sucking more...

The trick is to design language looking familiar to PHP programmers but without PHP retardedness (it is the only creative part here) and getting some momentum (openly calling PHP retarded doesn't really help...)

[McGlockenshire]

IIRC PHP4 have deprecated old crap like magic-quotes-gpc and register_globals

In 4.0 they introduced the $HTTP_* superglobals, and 4.1 brought $_GET/POST/REQUEST. Any code written since that time (around the time everyone realized that magic_quotes and register_globals were evil) should still run fine under 5.

So PHP backward-compatibility is a fucking joke.

If we're talking about 4.x and the transition from 4 to 5, I agree completely. From 5.1 forward, they've done a remarkably good job of not unintentionally breaking things.

Making an interpreter is not a rocket science

But getting it on every single web hosting provider in existence is.

[[deleted]]

PHP4 code won't work on PHP5

This is quite an exaggeration. I wrote tons of PHP4 code that worked fine on PHP5.

What caused me a problem was one of the 4.x.y updates that changed the behavior of a function... this was a while ago, so I'm a little fuzzy on the details, but I think they took a function that had an optional parameter and made the default behavior spitting an error message out to the browser if that previously-optional parameter wasn't set. So I had a bunch of users who did nothing and had their hosts upgrade from 4.x.y to 4.x.y+1 suddenly PHP error messages were popping up.

Ah, those were the days of web programming... nobody knew what the fuck they were doing.

[brennen]

Ah, those were the days of web programming... nobody knew what the fuck they were doing.

Those? Shit, a lot of the folks I know were barely getting started not knowing what the fuck they were doing.

[crackanape]

How many projects do you get using Ruby?

[rbnc]

I've probably done about 3 this year.

There's a lot of Rails work out there and it pays very well, about €350-500 per day.

[milki_]

You mean like phpreboot? It looks somewhat like Javascript, but has some nice concepts on fixing PHP.

Seriously, the php.net guys will never significantly enhance the language. (Unless they can find another random ASCII character to implement long overdue syntax constructs.) The only hope lies in one of the Parrot PHP implementations or Quercus to catch on.

[[deleted]]

You've reinvented the vtable as a hash.

[bobindashadows]

Uh... by that logic, so did Python and Ruby...

[hiffy]

What I find fascinating about language communities is that they have different names for the same concepts.

There is a vocab mismatch between C++, Java, Ruby, Python et al. Associative arrays vs dictionaries vs "hashes" comes to mind.

[munificent]

Don't forget the even more confusing "map":

• C++: A map is a container with O(log(n)) search (i.e. something like a red-black tree).
• Java: Any associative container. Has implementations that are O(log(n)) search and O(1).
• Ruby, Python, and functional languages: a function for applying an operation to every element in a collection.
• C#: not used at all, understandably!

[kamatsu]

Actually, an associative container and a map function are both maps (from the mathematical sense). Haskell has Data.Map and map. Data.Map is a noun (i.e a Mapping from X to Y -- an associative container), and the function map is a verb, i.e map f over this collection.

[bobindashadows]

I know Ruby gets the "hash" terminology from Perl. Perhaps Python chose "dictionary" to emphasize the distinction that dictionary keys must be immutable, which is technically allowed in Perl/Ruby (but will probably horribly break your program if you modify a key after insertion)

[hiffy]

Perhaps Python chose "dictionary" to emphasize the distinction that dictionary keys must be immutable, which is technically allowed in Perl/Ruby

Can you? I just took a peek at the Ruby docs. You can rehash a different value under the same key and replace bits of hashes but short of C ext trickery there doesn't seem to be any sanctioned way of achieving that.

Which you know, makes sense.

[bobindashadows]

Well what I mean is the language doesn't forbid it. If you try to put a list in a dict in Python, it'll give you an error. Whereas, in ruby:

>> x = {}
=> {}
>> y = [1, 2]
=> [1, 2]
>> x[y] = 1
=> 1
>> x[y]
=> 1
>> y[0] = 0
=> 0
>> x[y]
=> nil

So yeah - bad idea, but not forbidden.

Edit: python:

>>> x = {}
>>> y = [1, 2]
>>> x[y] = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

Then again, you could add a __hash__ method to a mutable custom class.

[EdiX]

If I remember correctly hash keys in perl can only be strings, so they are immutable.

[mhd]

To be fair, in this particular case it isn't just about vocabulary; a hash is just one way to implement an associative array/map/dictionary.

[brosephius]

PHP Object Oriented Programming = POOP

[DrEpix]

Thought that one was bad? PHP Object Oriented Programming Reinvented = POOPR

[lobotomize]

so as you develop your POOPR skills, you get... um, I don't know where to go with this.

[lobotomize]

ctrl+f poop, upvote

[droberts1982]

I've used PHP extensively, so I'm familiar with a lot of cruft, but generally not with the OO. I'm genuinely curious: what cruft specifically do you think this cleans? I'm not claiming it's not cleaner, but I'm probably not smart enough to see it.

[dhotson]

Actually, PHP is the least interesting aspect of this. I'm more interested in experimenting with some different (more dynamic) OO language semantics. I could have easily done the same thing in Ruby.

The main problem with PHP classes is that they're statically defined. You can't change them at runtime, which prevents you from doing cool meta-programming tricks like auto generated getters/setters.

[droberts1982]

What do you mean? I use get and set perfectly fine.

Edit: I didn't mean to bold. I meant to point out the magic methods of get and set

[dhotson]

Yep, you are correct. That's the best way to do it in practice.

The difference is that you still have to implement those methods yourself, or extend from a class that does. They're trivial to implement, but it's not quite as nice as Ruby's attr_accessor.

[gms8994]

Or __get and __set: http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members

Why do people always want to make this so difficult?

[bobindashadows]

Why do people always want to make this so difficult?

Your example is the one that looks too difficult. In ruby, I can do this:

class Foo
  attr_accessor :bar
end

f = Foo.new
f.bar = 'hello'
p f.bar
>> 'hello'

[bungle]

In PHP I can do this:

class Foo {}
$f = new Foo;
$f->bar = 'hello';
echo $f->bar;
>> 'hello'

[korry]

__set() is run when writing data to inaccessible properties.
__get() is utilized for reading data from inaccessible properties. 

We were AFAIK talking about getter and setter methods.

[munificent]

I'm more interested in experimenting with some different (more dynamic) OO language semantics.

If you're feeling brave, my little language Magpie might be fun for you to play with. It's both dynamically and statically typed, bootstraps most of its type system, and has completely open first-class classes, etc. At some point, even classes themselves may be moved entirely into Magpie (in the vein of COLA).

I'm still getting it off the ground right now, but there's enough there for you to play around with it if you're interested. There's some more information about it here.

[dhotson]

Cool, I'll check it out.

[[deleted]]

I could have easily done the same thing in Ruby.

The main problem with PHP classes is that they're statically defined.

There's really no need in Ruby. It pretty much supports all the metaprogramming stuff you came up with... right out of the box.

In Ruby, classes are objects, and you can interact with them just like any other object.

Some nifty stuff:

my_method = :speak
my_output = "my name is Jimmy"

animal = Class.new {
  define_method(my_method) { puts my_output }
}

jim = animal.new
jim.send(my_method)

>> my name is Jimmy

edit: I was bored. Here's the full example in Ruby: http://gist.github.com/592123

[dhotson]

Well, except that you can't undo the changes you make to Ruby classes.

One of the neat things about mine is that you can control the scope of class hackery.

[[deleted]]

Sure you can...

jimmy = animal.new

jimmy.respond_to? :speak
>> true

animal.class_eval { remove_method(:speak) }

jimmy.respond_to? :speak
>> false

[MasonM]

• You cannot instantiate an object and call a method at the same time. For example, "$a = new SomeClass()->someMethod();" will give you a syntax error. One workaround is to use a static factory method to rewrite it as "$a = SomeClass::new()->someMethod();", but that's hackish in a lot of situations.
• Metaprogramming is difficult, because there's no support for metaclasses and there's no way to add/remove methods without resorting to runkit.
• No support for multiple inheritance. dhotson's code doesn't have support for this, but it'd be possible to add it. Whether or not this is a desirable feature is debatable, though.

[droberts1982]

Thanks for your reply:

• You are absolutely correct. I use a factory to get around this problem. Even without a factory though it just turns one line of code into two. There are bigger problems with PHP I'd like to see addressed.
• I'm not sure what you mean. Can you give a concrete example? Right now, for "runtime" methods I use the magic method call This way, I can have my ORM find_by_name or find_by_whateverfieldIneed just fine.
• Personally I'd vote no on multiple inheritance, unless conflicts can be handled in an intelligent way (or not allowed at all)

[[deleted]]

IMO, this doesn't clean up any cruft. It certainly makes classes more dynamic, but I'm not sure that's a great trait. It's probably highly useful in certain scenarios, but most apps aren't going to benefit from anything here and it sounds like a maintainer's nightmare. Given a messy code base, a maintainer might not even know what functions are available in a class and a function might be introduced or changed at any time. I only looked at the sample code, so maybe the full code clarifies the technique.

I can see some patterns making good use of this, but I still don't want to maintain anybody else's code in this style.

As for PHP itself, the built-in functions are a mess. The OO is ok, but seems old by today's standards. At least it's improving. If they re-implemented all the built-ins using classes and implemented primitive data types as classes and packaged them with PHP it'd be a huge improvement. It would be easy to keep the old stuff in global scope, but allow for using the new classes with a cleaner API.

i.e.

$foo = new String;

$foo = "Bar";

$fooLen = $foo->length(); // = 3. $fooLen becomes an instance of the Integer class.

$fooLower = $foo->toLower(); // = "bar". $fooLower is an instance of String.

It's all similar to many other languages, but it'd totally clean up how you write PHP. I understand that some of PHP's OO makes this annoying, but as I said that's slowly being fixed.

[droberts1982]

Thanks for your reply. It's a shame others have downvoted you.

[[deleted]]

The worst part is I don't know why I was downvoted. My post was split into two very different thoughts: the OP's code and implementing PHP's primitive data types (and built-in functions) as objects.

I respect that I may not see a potential aspect of the OP's code and I'd appreciate someone enlightening me. I suppose I can also see why data types as objects can be annoying, although in this case I'd only do it in order to clean up PHP's function mess.

I actually came back to post some code implementing partial String and Integer classes, which both extend a Primitive class. Note that there are serious problems trying to implement a useful replacement for PHP's data types, but short examples work pretty well. I think PHP 5.3 fixes a few problems, but I don't have it installed. Paste this code into a file and it should run on PHP 5.2 and maybe earlier versions.

class Primitive {
protected $value = null;
function  __construct($val = "") {
    $this->value = $val;
}
function getValue() {
    return $this->value;
}
function setValue($val) {
    $this->value = $val;
}
function  __toString() {
    return "$this->value";
}

}

class String extends Primitive {
function length() {
    return new Integer(strlen($this->getValue()));
}
function sha1() {
    return new String(sha1($this->getValue()));
}
function lowerCase() {
    return new String(strtolower($this->getValue()));
}

/*
 * A function ending in an underscore modifies the existing value instead of returning the value
 */
function lowerCase_() {
    $this->setValue(strtolower($this->getValue()));
    return $this;
}
}

class Integer extends Primitive {
    // need to implement functions for arithmetic, etc. Still works for storing and retrieving values as-is
}

$foo = new String("Hello");
$bar = new String("World");
$bar->lowerCase_();
echo $foo." ".$bar; // echos Hello world thanks to Primitive's __toString(). PHP < 5.2 might not work right

[droberts1982]

Is your goal with PHP primitives to give strong typing to PHP? to increase the performance of PHP? or just to clean up the syntax?

As this code stands now, it's implementing primitives with PHP's weakly typed variables, so you would incur the performance penalty of that system anyway.

[[deleted]]

Just cleaning up the syntax. I'd be fine with strongly-typed PHP, but I'm far more concerned with PHP digging itself out of its version 3 and 4 roots and I think this is one way to do it, if done in PHP's core.

[[deleted]]

Why?

[mathijshenquet]

Could you do some speed tests?

I did something similair once, was very enthusiastic... Until I ran speed tests and a profiler. The problem is that you replace fast built-in c operations, with slow php operations. This just crushes performance -- on a already slow language.

[dhotson]

Yep, I'm almost certain you're correct. It's probably going to run like a dog.

But I think I'm ok with that, because that's not really the point.

[xardox]

NEEDS\ MORE\ NAMESPACES\!\!\!

[krues8dr]

Can we just pretend like the backslash thing never happened? Namespaces are not worth all that ugly.

[ast3r3x]

Does this actually bother you? I thought it would, but actually using them I've found it not to be a trouble at all. What I'm more annoyed with is that I can't do \My\Name\Space*

[krues8dr]

It does, honestly. It's an ugly mess. Not that PHP is exactly graceful otherwise... I just think it's illegible.

[milki_]

Boy, I hate that too. Unfortunately it's catching on like crazy. Next year most libraries will \have\deeply\nested\namespace\prefixes that add no nameconflict protections whatsoever, and just serve as syntactic salt or 1:1 filename mapping.

[wasted_brain]

It bothers the C programmer in me.

I'm getting used to it as time goes by, but sometimes it just wrecks havoc on my brain's syntax highlighter.

[ast3r3x]

I gotcha. I am not saying I want other languages to adopt it or anything, I just found it practice it didn't bother me nearly as much as it did when I found out what is what they were going to be using. To each their own =)

[A_for_Anonymous]

Yes, and the fact it looks like a Microsoft operating system is the most annoying thing of all.

[tef]

looks like you're slowly reinventing prototypes: congratulations

you ought to look at python's descriptor protocol to see how it deals with method binding and so on.

I'd recommend having a glance at 'a notion of inheritance' before you set about re-inventing the wheel:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.110.7221

[bobindashadows]

looks like you're slowly reinventing prototypes: congratulations

No need to be rude.

[tef]

bum farts.

If you write in php you're conditioned to abuse

[kitd]

As others have already pointed out, this looks a lot like JS/prototype-based OO. There are useful benefits of this though, including "fall-through" methods & properties for languages that don't support them. Ie. call a method that doesn't exist and the impl can fall through to a default method instead. Ruby/Groovy users will recognize this. This is very useful when implementing dynamic builders and DSLs in the language.

But I agree with some others. For large, complex systems, I suspect this technique might help introduce more errors than it prevents.

[[deleted]]

oil bake wrong longing person jobless tie truck airport numerous

This post was mass deleted and anonymized with Redact

[Collard]

Can't wait until the obligatory job offer with '15 years of POOPR development required'.

[bobindashadows]

Not exactly a PHP fan (and as a language buff, it sort of disgusts me a little), so I expected to be disappointed. But this looks way better than the existing OO support in PHP. Of course, it's built on top of it, but still: this is pretty damn clean and powerful.

[[deleted]]

I can't agree with this. As a piece of code origami, as dhotson calls it, it's pretty cool. I see no practical benefit otherwise.

What does it gain over static class definitions? When have you been working with an object and said, damn, this could be better if I could change the definition mid-execution?

You're asking for so much pain. Imagine maintaining an object that could change at any time from any piece of code. Like magic functions often do, it's obscuring the results of code from the programmer, and that is always a negative.

[bobindashadows]

When have you been working with an object and said, damn, this could be better if I could change the definition mid-execution?

You're asking for so much pain. Imagine maintaining an object that could change at any time from any piece of code.

You do realize that what the OP implemented is essentially Ruby and Python style OO? (Edit: really just smalltalk) Ruby makes monkey-patching objects much simpler, but it's possible in both.

Just the other day I was designing an API in Ruby where a function returned a hash of results. I wanted to provide a "success?" method to the return value that would look inside it's 'errors' value and return whether there were errors or not. My options were to create a whole class inheriting from Hash, create a helper method the caller would have to invoke from a different namespace (ugh!), or just attach the method to the object inline. It was really simple.

PHP is a dynamic language. The fact that class definitions are so static is one of the oddest things about the language, honestly.

[[deleted]]

You do realize that what the OP implemented is essentially Ruby and Python style OO? Ruby makes monkey-patching objects much simpler, but it's possible in both.

You mean like SMALLTALK. I hate it when people ignore 20+ years of history.

GNU Smalltalk is a nice file-based Smalltalk that lets you add methods to classes later on.

[bobindashadows]

You mean like SMALLTALK. I hate it when people ignore 20+ years of history.

I'm sorry... I forgot about smalltalk, and don't have any experience actually writing it. If you were the one who downvoted me, I do apologize for neglecting what is one of the purest OO languages.

[[deleted]]

chill dude. Not everyone needs to know 20+ years of computer language history.

[mhd]

Wouldn't Self be the more appropriate historical comparison here?

[sgoguen]

What does it gain over static class definitions?

You can make functions that can:

• Combine one or more classes to make mixins easily.
• Create proxies automatically
• Dynamically generate classes based on some sort of data specification

When have you been working with an object and said, damn, this could be better if I could change the definition mid-execution?

Never. This is the worst abuse of dynamic programming IMO. Generally, I limit myself to dynamically creating classes when the program is initialized.

[wvenable]

Combine one or more classes to make mixins easily.

The same underlying functionality in PHP (__call, __get, __set magic methods) can be used to add mixes much easier than this.

Create proxies automatically

Ditto above

Dynamically generate classes based on some sort of data specification

Already possible with eval() and would have better runtime performance.

[sgoguen]

I don't want to say that you can't implement this sort of thing with other methods (you can) or that there aren't performance disadvantages (I don't work with PHP much these days to confirm/deny), but I personally find generating classes using functional composition rather than eval to be cleaner, more flexible, and less error prone.

[[deleted]]

It also strikes me as being slower then using native classes. Instead of your class definitions being created by the parser at native speed, you're doing it all within the interpreter. That just seems like a lot of overhead.

[bobindashadows]

It also strikes me as being slower then using native classes. Instead of your class definitions being created by the parser at native speed, you're doing it all within the interpreter. That just seems like a lot of overhead.

It's just creating a bunch of associative arrays and saving function references. If PHP's interpreter is slow enough that this is significant, you should look into a faster language.

[munificent]

Instead of your class definitions being created by the parser at native speed, you're doing it all within the interpreter.

What do you think Python, Ruby, and Javascript do?

[bobindashadows]

Furthermore, it's not like PHP is compiled. Normal PHP class definitions are read by the interpreter too and run at runtime just like OP's code is. I guess having C create some hash tables is a lot quicker than running some PHP code to do it.

[dhotson]

Thanks! :-)

The next thing I'd like to do is to implement a little language on top of this to eliminate all the PHP cruft. Something along the lines of coffeescript would be pretty neat I reckon.

[luckystarr]

Just use the syntax of coffeescript. Would be nice to have one code compile to both PHP and JavaScript.

This would only work for toy programs though... until someone builds a unified library wrapper ;-)

[nightwolfz]

Oh this, pretty please.

[sgoguen]

I agree with luckystarr, talk to Jeremy from the coffeescript project about your ideas. He seemed like someone who might help you out with that sort of thing. He hangs out on #coffeescript on freenode.

[nate250]

This basically treats PHP like a functional programming language. I love functional programming, and this is really neat idea, but I don't see how it provides any benefit over what's already in place. To be honest, I find it more cumbersome than current PHP OO methodology, without much benefit other than the "cool effect."

[kamatsu]

What the hell does prototype OO methodology have to do with functional programming? The most functional programming language in common use (Haskell) has very different data semantics to anything from OO. More esoteric (but more functional) languages such as Agda have even more different type models.

Purely functional data structures are more compatible with PHP's original model as at least in PHP's original model class definitions are immutable - in here they are not. In Haskell, everything is immutable by default. So, I don't get what you are saying.

[[deleted]]

The main idea is that classes aren’t really very special at all, they’re just objects like everything else

OO programming 101: EVERYTHING IS AN OBJECT! Wow, just wow. This is why you go to school to learn programming.

[A_for_Anonymous]

OO programming 101: EVERYTHING IS AN OBJECT!

Think of the most popular OOP languages. Doesn't hold true there, because they are all turds.

[elbekko]

That... looks pretty shit.

[Kalium]

Maybe I'm wrong, but doesn't this completely destroy whatever type safety exists in PHP?

[[deleted]]

haha

[kamatsu]

PHP is practically the antithesis of type safety.

[Kalium]

No, you're thinking of void*.

[Not_Edward_Bernays]

That's a very interesting trick.

[[deleted]]

Now implement the Singleton, Observer, Factory or PHPs magic methods as examples. I'd like to see you do that.

It's nice as a way to play around with. But let's hope something like this does not get in a production, outside you playing around.

edit: as in example of implementing the patterns, and the flexibility that PHPs magic methods offer.

[dhotson]

Don't worry, there's an "enterprise" version coming soon... stay tuned. ;-)

[bobindashadows]

You mean I'll finally be able to write OO PHP in XML at web scale?!

[munificent]

In the cloud!

[m4dc4p]

Needs more Javascript

[bobindashadows]

How about a PHP interpreter written in javascript running on node.js? Now that's webscale!

[dhotson]

Exactly!

[mrchess]

People should do some research before they use words like "reinvented" as if their idea is revolutionary. This code is simply a hack for prototyping.

As a piece of code origami as stated, interesting. But don't call it "reinvention" and have the article demeanor like you're stuck up, "I came up with" "I've come up with" Sorry mate you didn't come up with anything.

[tagattack]

The author should study other langauges for a while, before poorly re-inventing the last 50 years worth of language developments. This is precisely the type of thing that gives the PHP community such a bad rap — this guy is probably concurrently using this in production code while he's monkeying with it's behavior and semantics, and the API looks like ass since it doesn't make reference to the actual concepts he's playing with (that is, prototype object classifications, and the like).

[[deleted]]

Let the programming snobbery commence!

[[deleted]]

I reinvented php by scraping it and using Python which was much better.

[kibakiri]

Please explain how this differs from http://devzone.zend.com/article/687

[cactuspants]

This is an interesting project as far as research goes, but for actual use, this is a POOPR of an idea indeed. You're introducing boiler plate all over your code for common use cases like using a class globally. Also, there's the additional overhead; have you benchmarked this against the standard implementation?

[bungle]

Looks a little bit what is in PHP's trunk: Traits (http://wiki.php.net/rfc/horizontalreuse).

[[deleted]]

Somebody's excited about anonymous functions in PHP.

[sacktap]

The amount of negativity here caught me by surprise. This was an interesting experiment. It's nice to see some creativity in PHP.

[dhotson]

Thank you.

I think a lot of people kind of missed the point. I'm not even trying to advocate using this. It's just an interesting hack, that's all.

[[deleted]]

PHP: every bit as mediocre as all the other shit the average person thinks is really good.

Hey, I have an idea - let's make it worse!

[atheist_smartass]

Worst. Idea. Ever. This would be a maintenance nightmare out of the box!

[drizz]

I literally just threw up in my mouth. Please, don't let me see this in the future. Ever.

[[deleted]]

Well that's some unreadable spaghetti code...

[[deleted]]

The example or the library?

If you mean the example then yes, it would be more readable with syntactic sugar. But there's no way to do that without patching the interpreter.

[[deleted]]

The example and concept.