![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
Everyone knows I am not too fond of OOP. And yet, I had some role in crafting DBTNG. I now admit: DBTNG in its current implementation is a mistake. Making the stream wrappers a class -- although PHP mandates that -- is a mistake.
Daniel Kudwien's complaints on the CDN post dawned this on me. While I was always complaining of PHP's inability of adding a method run-time, the problem we face is that you can't replace one either. So if you do what I did in the previous post, namely use the hook-alter patten (already an addition to PHP, I must say) to override the classname, that works. However, if two modules try to do this for two different methods, you fail.
Fail is the name of the game and this game is PHP. Here is Python:
class test:
x = 'test'
def foo(self):
print self.x + 'foo'
def bar(self):
print self.x + 'bar'
// We need the test.foo method to do something else.
test.foo = bar
test().foo()this happily prints testbar, accessing an instance property without a problem (JavaScript can do this via classname.prototype, and while I am not good with Java, instrumentation seems one way to do this). There is absolutely no way in PHP to do anything like this. Once the closing bracket of the class has fallen, the class is done and there is no way to add code (or modify code) that will access protected/private properties of that class. This is an iron wall that can not be breached by either the __call hack or closures (at least in PHP 5.3).
Drupal 8 should admit we made a mistake with Drupal 7, get rid of all this closed crap that in PHP is called OOP and work hard on making our fixes to the language (the hook system and more) even better to replace it. It was a very interesting attempt, let's abandon it, it does not work too well. Let's implement a working OOP system in PHP, using procedural notation if we must -- because there is no other way. Drupal rocks because it's flexible, because it's already addressing some of the PHP shortcomings and because it's fundamentally AOP instead of OOP. Let's continue going down that road we partially abandoned in Drupal 7 dazzled by the awfully limited OOP features of PHP5. OOP has it's place, yes. But the parts of OOP that made it into PHP are not enough for Drupal.
To be more concrete here, while addition was always possible via the hook system -- even if node module did not implement hook_foo_bar, foo module could just use function node_foo_bar -- the modification was not (nicely) solved. Alters are some sort of a solution... but they are not exactly the same as replacement, as they are an addition step that allows changing stuff, it's not replacing a method/function/behaviour/whatever.
Ps.: Yes, Drupal 7 will be awesome nonetheless. Just we will hit walls which we could have avoided. We will make life harder than necessary. Let's face this and fix in Drupal 8.
Commenting on this Story is closed.
Making the
streapstream wrappers a classfixed
Have you seen the Faces module? It looks like it implements what you are looking for in PHP in Drupal. Checkout http://drupal.org/project/faces and http://drupal.org/node/666888.
and it's going to be somewhat slow.
when D8 is coming the php guys have implemented some more sophisticated OOP handling too and everything is good again?
You can always declare members as public, private and protected access are features for code maintainability. There is also the possibility to create getters when it makes sense. I think you are being stubborn not realizing there are ways to accomplish the same results in OOP as in procedural code. Can you change a hardcoded function call in PHP at runtime? Neither in OOP or procedural code. Can you create a workaround? Sure, and the coding style doesn't matter.
with hooks. You can call me stubborn but you can't deny this hard fact.
I developed web apps with drupal for 2+ years. Moving to MVC and python with Django I haven't looked back.
My suggestion is to stop the spaghetti code and find a better tool for building customized web applications. Drupal really inhibits itself being a CMS and also trying to do a half ass framework job.
Well I'll take you up on that. Keep your Python or the highway mode of thinking. Good you think it's awesome. Sadly is just the current popular version (even more popular than Ruby) of a "grown-up" programming language. The sad part is that Lisp, which just celebrated 50 years in 2009, has more advanced concepts and ideas than Python. Don't even get me started on the syntax.
Yes PHP is hardly a perfect language, and yes not everything in Drupal is great. But hey, coming from a Lisp background I find the hook system of Drupal a great plus.
Keep chasing the rainbow, there's bound to be a pot of gold somewhere.
I am going to +1 (as you would in d land) the comment about moving away from Drupal for web applications. It is still the goto app for a CMS (read blog/info site), but all applications that don't fit Drupal's model will save immense capital using an MVC architecture. The patterns are simply a much better way to solve the problem than Drupal can offer.
With Drupal you can get ~ 65% really quickly, but the business logic will be hell. To many dumb ass assumptions from module developers. Let's not even talk about the final 10% that will be extremely difficult to pull off. THE FRAMEWORK of Drupal will require more code/hours to back out all the assumptions (features**) Drupal comes with.
I feel sorry for any Drupal developers working on projects with a large scope.
Good day and good bye Drupal.
Yes, what you write here is unfortunately mostly true, I fear. PHP being slow for advanced OOP code really .. sucks.
That PHP doesn't allow classes to be dynamically modified is not even the point - if the existing constructs actually were fast enough, then there would be quite a few ways around the actual language limitations.
I just recently re-read some code I wrote some three years ago [1]. I still hink it's a quite beautiful peace of code, it is complete OOP and has "native" hooks. And chaining through child objects plus arrayaccess for properties makes up a very simple and highly usefuly syntax. However, PHP's OOP slowness remains a drawback. If too much of a drawback, I don't know.
[1] http://drupalcode.org/viewvc/drupal/contributions/sandbox/frando/structuredarrays/
PHP will have traits, which is somewhat similar to what you are looking for. Although, no idea when a usable version comes out of it (I heard traits are already in the trunk for 6.0).
http://wiki.php.net/rfc/traits
I think you have missed a major principle of OOP. The iron wall that you talk about is there to protect the code that should not be changed. When you (as the architect of a class) decide that this class is going to be able to be modified, then you define methods/properties as public/protected.
Your example above can very easily be realised in PHP as:-
class test {protected $x = 'test';
protected function foo(){
print $this.x . 'foo';
}
}
class myTest extends test {
protected function foo() {
print $this.x . 'bar';
}
}
$something = new test();echo $something.foo(); // Prints 'testfoo'
$something = new myTest();$something.foo(); // Prints 'testbar'
Your very own comment... "We need the test.foo method to do something else." should be screaming inheritance!
A very flexible and robust plugin system can very easily be implemented in OOP using the standard principles! By using interfaces you can allow virtually any class to implement a function, and still have the main plugin controller know that it is going to conform to the defined parameters, ie arguments it gets passed and values it returns!
I am failing to see the relevance of this argument, except that a bad architecture decision has possibly been made when trying to convert a procedural system to an OOP system.
Please, enlighten me if I am wrong!
When I started reading i was exactly thinking the same thing as Gargoyle. I couldn't agree more with him, just use some inheritance/polymorphism and you'll get what u want done. Design software as simply as possible, don't try to convert bad software design to language problems.
As the two guys before me already said, you can easily do this be either inheritance or, maybe even better, the decorator pattern.
There sure are possibilities to change the behavior during runtime, but adding/removing/replacing methods of a class, which is supposed to be static, is a bad path to go.
Google for "decorator pattern" or start out with inheritance.
Good luck!
PHP != OOP.
I like it very much. Can you share me more about it? Thank you!
Hi,
You are wrong. PHP natively does not have the ability to "add" methods to classes.. however that is not the point of OOP. To properly do this you would typically use implement a subclass to add or override the method that you want.
Symfony also introduces the concept of mixins which provide a way to do what you described above.
well,great idea,thanks.
wedding gowns
lace wedding gowns
wedding gown
wedding dresses
Recently I bought a brand new apple PC and for some reason your web site just isn't loading properly within safari. You should investigate this.
www.wart-off.net
Plumdresses is a professional instock dresses and gowns provider, you can get your dream dresses from our online shop quickly without waiting for a long time.
You can always declare members as public, private and protected access are features for code maintainability. There is also the possibility to create getters when it makes sense. I think you are being stubborn not realizing there are ways to accomplish the same results in OOP as in procedural code. Can you change a hardcoded function call in PHP at runtime? Neither in OOP or procedural code. Can you create a workaround? Sure, and the coding style doesn't matter
__________
__________
roth ira | ira limits