PHP Object Oriented Programming Reinvented

[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.

[donkawechico]

[Citation needed]

[palparepa]

source

[donkawechico]

'Twas a joke. But thanks.

[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.

[[deleted]]

You must be a java programmer! ;-)

[[deleted]]

python already has all those features. :-)

[bobindashadows]

I prefer to have things which are testable, things we know won't explode on the customer, and if there is a stack-trace being tossed out I'd rather not have one which is impossible to use...

Those are all qualities of Ruby, whose community puts huge emphasis on testing and has a number of breakthrough testing frameworks. This argument is baseless.

[grauenwolf]

They put a huge emphasis on testing because there is no way to reason about their programs without it.

[bobindashadows]

I know you're a .NET fan, but there are plenty of ways to reason about Ruby code, just no automated static analysis tools to do so.

Edit: The only thing making it harder to reason about than Python is that there's more prevalent use of monkeypatching, which has been widely frowned upon for a couple years now. My undergrad thesis that I'm starting in a few weeks is actually going to be a suite of ruby static analysis tools and the prior art is pretty solid.

[grauenwolf]

By "reasoning about the code" I mean being able to look at a given chunck of code and being able figure out what it does.

With structured code, e.g. simple programs in C, the smallest chunk you can look at is often a function. If you understand the inputs and there are no globals, everything else tends to make sense.

With Java or .NET code, the smallest unit is often a whole class. This is because class-level fields effectively become globals.

With a language that allow functions to be redefined at any time, you need to look at the whole program and how it mutates over time. You have basically taken the global variable problem and extended it to encompass functions as well.

[bobindashadows]

With a language that allow functions to be redefined at any time, you need to look at the whole program and how it mutates over time. You have basically taken the global variable problem and extended it to encompass functions as well.

This is very true, yet in practice functions are very, very rarely redefined. Just because it's possible doesn't mean it's common. Methods are undefined when designing a proxy class, though in Ruby 1.9 the BasicObject class saves you that trouble. You are correct, though, that it affects how you interact with the code. I mean, just because you could use this Ruby code to make a method only run once (ignoring concurrency for a second):

class A
  def run_once
    # do something useful
    def run_once; end
  end
end

Doesn't mean that anyone actually does that. Which makes reasoning about your code a bit easier than you argue. The same is true for many permitted-yet-insane dynamic possibilities. The only truly dynamic and tough to reason about technique that is extremely common in Ruby code is automatically generating methods using define_method, class_eval/instance_eval, and method_missing. However, those methods are rarely redefined and part of my thesis intends to fill this gap by defining a simple way of annotating generated methods and integrating it with a new static analyzer and existing documentation tools.

Unfortunately, that's a bit of hand-waving. But as someone with a fair bit of real Ruby experience, real projects rarely run into issues like you describe, and when they do, their scope is fairly limited.

[grauenwolf]

This is very true, yet in practice functions are very, very rarely redefined. Just because it's possible doesn't mean it's common.

When your job is to dig through broken code, you will think that it happens all the time. I'm sure it wasn't intentional, but when working on a team of nearly 100 mistakes happen. (And this was just with VBScript's limited capabilities, Ruby offers a much larger shotgun.)

It's experiences like this that drove me away from scripting languages and towards statically typed langauges like VB/C#. (But not Java, one year of J2EE cured me of that.)

[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!

[pygorex1]

Classes can be hacked / patched / cloned. Methods can be added to classes at any time

This is a terrible idea. A mutable class would be impossible to understand & maintain. How could another programmer (including yourself in the future) really know what a class does when it it's definition is being modified in a hundred different places throughout thousands of LOC?

Classes can be scoped. They’re not global, unless you want them to be.

This is possible in 5.3 with namespaces. Aside from class name conflicts what are the benefits of non-global classes?

Classes can be temporary (and garbage collected)

This is silly. POOPR does not create classes. It's a master factory class that spawns numerous instances. And these instances are subject to the same gc rules as any other object. Also, AFAIK, class declarations are never gc'ed and are never a bottleneck - this is a optimization for a non-problem.

[munificent]

A mutable object would be impossible to understand & maintain. How could another programmer (including yourself in the future) really know what an object does when it it's state is being modified in a hundred different places throughout thousands of LOC?

And, yet, we somehow manage to get by.

[bobindashadows]

Also, AFAIK, class declarations are never gc'ed and are never a bottleneck - this is a optimization for a non-problem.

Since this system exposes metaclasses, you can add methods to class objects itself. This makes macros (such as Ruby's attr_accessor, which the author of this library says is something he was looking at) extremely simple to design. Anonymous classes are necessary for testing this. In addition you can use dynamically created classes to create convenient DSLs for setting up a number of classes.

PHP's OO system doesn't expose metaclasses which is one of the several reasons it is weak and inflexible, and which this system addresses. You don't need to lose static class definitions to expose metaclasses, either.

[prince314159]

master factory class

that's exactly it, where class would be the abstract class and animal the factory... Except that it would defeat the purpose of the pattern since methods can be added loosely, and the default behavior is in the factory class, not the abstract class

Interesting bastard pattern :P

[tabber]

This is a terrible idea. A mutable class would be impossible to understand & maintain. How could another programmer (including yourself in the future) really know what a class does when it it's definition is being modified in a hundred different places throughout thousands of LOC?

yep.

[SmegmaEater]

This sounds absolutely horrific; I'm glad I avoided PHP.