Page 5 of 10

Re: Namespaces and abstract class names

Posted: Mon Feb 07, 2011 1:09 pm
by Christopher
Jenk wrote:I knew that would happen, I'm not talking of "Inversion of Control" (i.e. "Dependency Injection") I'm stating the the control of what is implemented is inverted (i.e. the literal meaning of the control has been inverted :P) in that the "parent" becomes the "child"/dependent.
My complaint was not that you use IoC incorrectly ... it is that it is not directly related to black-box or the differences between inheritance and composition.
josh wrote:Subclasses do know their superclass' implementation. Try to have both classes use variables & methods with the same name, you don't have to worry about that crap if you don't use inheritance :-D
I will argue with the idea that having to know a method or variable name is having to know its implementation -- those things are the definition of an interface. If you want to use the methods or public properties of a composited object you need to know the same information.

And ... calling the sharing of properties between methods (inherited or not) "that crap" seems ridiculous to me. That is a capability to use or not use. It is finely controllable with private/protected/public. Shared properties is an essential features of classes. I am bewildered...

Re: Namespaces and abstract class names

Posted: Mon Feb 07, 2011 4:04 pm
by josh
Christopher wrote:I will argue with the idea that having to know a method or variable name is having to know its implementation
In PHP, a variable's name is it's implementation.
If you want to use the methods or public properties of a composited object you need to know the same information.
Nope, to use a collaborating object from within "my object", I don't need to know the names of all of "my" own methods & variables.
That is clearly different than the info needed to safely inherit a class, wherein I do need to know the names of all "my" methods & variables.

Inheritance = need to know all details of both classes. If superclass uses an unrelated public variable, I need to know it's implementation (name)
Composition = only care about interface (methods only!!) of other object.

Interfaces do not define variables, that I know of. The fact I need to worry about variables is a clear red flag that I'm about to couple to an implementation, rather than an interface.
Shared properties is an essential features of classes. I am bewildered...
Could you show me example code that couldn't possibly be written without abstraction? (rules are you can't go grab some PHP extension or framework that requires it though. For those I'd say you should use abstraction, but only to create a wrapper that you compose [so you don't couple to that framework's abstract class])

As for bewilderment, most best practices in programming are counter-intuitive. I'll admit I never thought of not using 0% abstraction until this thread, its not intuitive to stop using abstraction, what Jenk says makes sense tho which is why I agree with & argue his points. I already admitted abstraction has the benefit of less need for delegating methods, but that's the only benefit I see to it. It doesn't outweigh it's flaws to me.

Re: Namespaces and abstract class names

Posted: Mon Feb 07, 2011 4:25 pm
by VladSun
josh wrote:That is clearly different than the info needed to safely inherit a class, wherein I do need to know the names of all "my" methods & variables.
In C# there are keywords like virtual/overrides etc. Do you want these to be included in PHP in order to feel "safe" ? How about using variables/properties that don't even exist?
I.e.

Code: Select all

$this->varaable = 5;
vs

Code: Select all

$this->variable = 5;
Yes, it's error prone. It's PHP. It's non verbose, "scripting" language.

You guys, complain about using the private/protected modifiers, and then out of the blue you complain about property/method names collisions. At the same time, even namespaces aren't collision-bullet proof. Then you say "It's PHP". I really can't understand what you mean - "abstract", "private", "protected", "final" - not needed?

Why?!? If it's not needed for TDD, OK, but there *are* people that do not need TDD to develop software. They probably need these keywords. There are people that had learned to develop software on a sheet of papper and a pencil. No PC ... They do not do TDD. It's already done. There are people that do not write software in the "trial-error" way ...

Agile development is just another style of development. Nothing else. It has it pros, and it (will) has its cons.

Re: Namespaces and abstract class names

Posted: Mon Feb 07, 2011 4:57 pm
by Christopher
josh wrote:In PHP, a variable's name is it's implementation.
So an object, array and scalar all have the same implementation in PHP? That just sounds weird. A variable's name is its interface (and I don't mean PHP's interface keyword) -- it is how you access the implementation. It is a strange way to think about it, but you brought it up.
josh wrote:Nope, to use a collaborating object from within "my object", I don't need to know the names of all of "my" own methods & variables.
That is clearly different than the info needed to safely inherit a class, wherein I do need to know the names of all "my" methods & variables.
You say "safely" but you are talking about a feature. You can override or not override methods using inheritance. You can also call the inherited method from the overriding method. Those are similar things to what you can do when calling or proxying a method in a composited object.
josh wrote:Interfaces do not define variables, that I know of. The fact I need to worry about variables is a clear red flag that I'm about to couple to an implementation, rather than an interface.
Are you saying here that the PHP implements keyword is the only use for interface. A Value Object has not interface? A class that does not implement a PHP interface has not interface?
josh wrote:Could you show me example code that couldn't possibly be written without abstraction? (rules are you can't go grab some PHP extension or framework that requires it though. For those I'd say you should use abstraction, but only to create a wrapper that you compose [so you don't couple to that framework's abstract class])

As for bewilderment, most best practices in programming are counter-intuitive. I'll admit I never thought of not using 0% abstraction until this thread, its not intuitive to stop using abstraction, what Jenk says makes sense tho which is why I agree with & argue his points. I already admitted abstraction has the benefit of less need for delegating methods, but that's the only benefit I see to it. It doesn't outweigh it's flaws to me.
I am really not clear how your are using "abstraction" now. You suddenly started using that word in some specific context.

Re: Namespaces and abstract class names

Posted: Mon Feb 07, 2011 6:04 pm
by josh
VladSun wrote:You guys, complain about using the private/protected modifiers, and then out of the blue you complain about property/method names collisions.
You need to worry about property collisions with or without member visibility. 2 variables marked public still collide. If you don't do automated testing, this is all the more reason NOT to use abstract class, as you have no way to verify your individual changes aren't breaking something (other than to test every possible path in your program).
Why?!? If it's not needed for TDD, OK, but there *are* people that do not need TDD to develop software. They probably need these keywords. There are people that had learned to develop software on a sheet of papper and a pencil. No PC ... They do not do TDD. It's already done. There are people that do not write software in the "trial-error" way ...
This has nothing to do with TDD.
Christopher wrote:So an object, array and scalar all have the same implementation in PHP? That just sounds weird.
A variable is a implementation detail. Objects are accessed by variables. Variables are implementation details.

Code: Select all

class Foo
{
function foo()
{ 
 $this->bar = new Bar;
}
}
$this->bar is part of Foo's implementation.

When I type "class Foo" that it's implementation. Likewise when I type "$foo" that should/could be considered implementation. I'd define implementation as the user land code (PHP code) for something. In programming, if you are typing you are implementing something. Even an interface technically has an implementation. (dont't confuse the interface's implementation, with the implements keyword. When you use the implements keyword you're telling the compiler "make me implement the methods declared on this interface")
You can override or not override methods using inheritance.
Correct, thus the extra step of physically navigating to the super class, and consciously deciding the method name based on the method names in the super class. With 100% composition, you need never worry about that, its an extra 1 minute of my life saved every time I create or rename a method.
josh wrote:Could you show me example code that couldn't possibly be written without abstraction? .
I am really not clear how your are using "abstraction" now. You suddenly started using that word in some specific context.
Abstraction - an abstract class, or use of an abstract class


What I'm asking, is what honestly is the appeal of using an abstract class, you trade the convenience of not having collisions, in exchange you get the diamond problem. lol. Prototypical inheritance is the only way to get the best of both worlds. (as the only benefit of abstract class is less delegating methods, which isn't the case in prototypical inheritance)

Re: Namespaces and abstract class names

Posted: Mon Feb 07, 2011 6:52 pm
by Christopher
josh wrote:A variable is a implementation detail. Objects are accessed by variables. Variables are implementation details.
I think you are just making things up at this point!. Do you mean properties? So if object $foo has a property $bar then both $foo and $foo->bar are variables. Certainly $foo is not an implementation detail, yet it is a variable. And if property $bar is public then it is both part of the implementation and part of the interface.
josh wrote:When I type "class Foo" that it's implementation. Likewise when I type "$foo" that should/could be considered implementation. I'd define implementation as the user land code (PHP code) for something. In programming, if you are typing you are implementing something. Even an interface technically has an implementation. (dont't confuse the interface's implementation, with the implements keyword. When you use the implements keyword you're telling the compiler "make me implement the methods declared on this interface")
So you have now turned everything into implementation making the words meaningless. I think when you type "class Foo" you have not yet got to the implementation -- which is the stuff in the class block.
josh wrote:Correct, thus the extra step of physically navigating to the super class, and consciously deciding the method name based on the method names in the super class. With 100% composition, you need never worry about that, its an extra 1 minute of my life saved every time I create or rename a method.
To me it is the same number of steps to "navagate" to a inherited method doing

Code: Select all

parent::bar()
as there are to access a composed method

Code: Select all

$this->foo->bar();
This is part of my point (and many people's confusion). Inheritance and composition have much of the same functionality. I agree that composition can lead to better practices. But I also understand that inheritance is as simpler way to do common things where there is no advantage.
josh wrote:Abstraction - an abstract class, or use of an abstract class

What I'm asking, is what honestly is the appeal of using an abstract class, you trade the convenience of not having collisions, in exchange you get the diamond problem. lol. Prototypical inheritance is the only way to get the best of both worlds. (as the only benefit of abstract class is less delegating methods, which isn't the case in prototypical inheritance)
I am not a big fan of abstract classes either. But I don't understand how the the diamond problem of multiple inheritance relates to this discussion because PHP only has single inheritance. It effect neither inheritance or composition.

And yes, prototypical inheritance has the advantages you mention. However in relation to this discussion the practical disadvantage of prototypes is the increased verbosity over conventional classes and inheritance. Again, that is my point. It is not that traditional inheritance is better. It is that it is simpler for many common cases. And that simplicity and parse-time checks may support correctness.

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 8:00 am
by josh
Christopher wrote:
josh wrote:A variable is a implementation detail. Objects are accessed by variables. Variables are implementation details.
I think you are just making things up at this point!. Do you mean properties? So if object $foo has a property $bar then both $foo and $foo->bar are variables. Certainly $foo is not an implementation detail.
Yes $foo is an implementation detail in the calling code. Obviously when you do:

$foo = new Foo;

That is not part of Foo's implementation. However you are now implementing code in the global space.

http://stackoverflow.com/questions/1777 ... ion-detail

Basically what stack overflow says, if i can summarize. "implementation details are anything not in your client's spec (like the name of a class, method, or variable), so if you rely on something like a variable name your code is not guaranteed to work with other code written to the same specifications"
Christopher wrote:So you have now turned everything into implementation making the words meaningless. I think when you type "class Foo" you have not yet got to the implementation -- which is the stuff in the class block.
Really? Why do programmers like Martin Fowler and you use terms like "implementation language"??
Christopher wrote:I am not a big fan of abstract classes either. But I don't understand how the the diamond problem of multiple inheritance relates to this discussion because PHP only has single inheritance
When I say diamond problem refer back to my example about robot, cat & dog, all walk but robot should not inherit from the same super class as animals. Single or multiple inheritance, it doesn't matter because neither can solve that problem.
And yes, prototypical inheritance has the advantages you mention. However in relation to this discussion the practical disadvantage of prototypes is the increased verbosity over conventional classes and inheritance.
What increased verbosity??
Again, that is my point. It is not that traditional inheritance is better. It is that it is simpler for many common cases.
Well this part I've agreed with. It can be easier to read & write in a simpler program. But you know what else is simpler for many common cases? Singletons, global variables, etc. :-) To me this discussion seems just like the discussions about global variables. Everyone who uses them seems to think their simplicity outweighs the propensity to shoot yourself in the foot. I simply disagree out of experience.
And that simplicity and parse-time checks may support correctness

Code: Select all

class Foo {}
class Bar extends Foo {}
$foo = new Bar;
$foo->bar();
Here the compiler does nothing to warn you that you're calling a method on Bar instead of Foo, so I'm not sure what your repeated rebuttal about calling "parent::" is about. If a method is overridden, you definitely need to be conscious of that.

Interesting discussion though, keep it going. Its getting very philosophical. These are the threads I like.

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 10:54 am
by Jonah Bron
I'm just reading here, I don't think I'm in a position to jump in, :roll: but...
josh wrote:Here the compiler does nothing to warn you that you're calling a method on Bar instead of Foo, so I'm not sure what your repeated rebuttal about calling "parent::" is about. If a method is overridden, you definitely need to be conscious of that.
If it does something different, wouldn't you just not override it? Or create a new Foo instead?

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 12:02 pm
by VladSun
OK, so I suppose in PHP 6 there won't be any of the "parent, self, static, abstract, final, public, private, protected, extends, implements" keywords. They are not needed. :evil:

Or maybe ... there would be another set of keywords introduced - "overrides, virtual" together with the keywords set mentioned above. :twisted:

Your vote? :dubious:

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 1:27 pm
by VladSun
josh wrote:

Code: Select all

class Foo {}
class Bar extends Foo {}
$foo = new Bar;
$foo->bar();
Here the compiler does nothing to warn you that you're calling a method on Bar instead of Foo, so I'm not sure what your repeated rebuttal about calling "parent::" is about. If a method is overridden, you definitely need to be conscious of that.
VladSun wrote:In C# there are keywords like virtual/overrides etc. Do you want these to be included in PHP in order to feel "safe" ?
josh, did you intentionally miss that?

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 2:39 pm
by Christopher
josh wrote:Yes $foo is an implementation detail in the calling code. Obviously when you do:

$foo = new Foo;

That is not part of Foo's implementation. However you are now implementing code in the global space.

http://stackoverflow.com/questions/1777 ... ion-detail

Basically what stack overflow says, if i can summarize. "implementation details are anything not in your client's spec (like the name of a class, method, or variable), so if you rely on something like a variable name your code is not guaranteed to work with other code written to the same specifications"
You have moved from interface to implementation to implementation detail. Who knows what the Stackoverflow comment is about? How are they using "client's spec"? Does that include the picture on a napkin I sometimes get? If the specification is an interface (in general, not the PHP specific term) then you can change any code in your implementation and still work with the "client's spec" -- that's how it's supposed to be.
josh wrote:Really? Why do programmers like Martin Fowler and you use terms like "implementation language"??
Well ... because they mean something! That they mean something unrelated to this conversation is the important point. Perhaps governmental "public policy implementation" might support your point as well?
josh wrote:When I say diamond problem refer back to my example about robot, cat & dog, all walk but robot should not inherit from the same super class as animals. Single or multiple inheritance, it doesn't matter because neither can solve that problem.
Again ... irrelevant. I agree that composition can provide some additional functionality that inheritance cannot. Not sure why robots cannot inherit the same walk super class as animals anyway -- this is code!
josh wrote:What increased verbosity??
I was thinking of Javascript with its 3-4 ways to define classes -- some terse, some clunky.
josh wrote:Well this part I've agreed with. It can be easier to read & write in a simpler program. But you know what else is simpler for many common cases? Singletons, global variables, etc. :-) To me this discussion seems just like the discussions about global variables. Everyone who uses them seems to think their simplicity outweighs the propensity to shoot yourself in the foot. I simply disagree out of experience.
It is only the same in that the discussion is about advantages and disadvantages. I did not say "easier to read & write in a simpler program" ... I said that in many common use cases they do the same thing but with simpler syntax.
josh wrote:Here the compiler does nothing to warn you that you're calling a method on Bar instead of Foo, so I'm not sure what your repeated rebuttal about calling "parent::" is about. If a method is overridden, you definitely need to be conscious of that.
I don't see the difference in warnings or possibility for errors between this:

Code: Select all

class Bar extends Foo {
  public function bar() {
    parent::bar();          // you could forget to do this
  }
}
And this:

Code: Select all

class Bar {
  public function __construct($foo) {
    $this->foo = $foo;
  }
  public function bar() {
    $this->foo->bar();     // you could forget to do this
  }
}
You argument is that programmers need to be conscious of the code and if they are not there may be problems -- with that I agree.

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 3:25 pm
by John Cartwright
Christopher wrote:

Code: Select all

class Bar extends Foo {
  public function bar() {
    parent::bar();          // you could forget to do this
  }
}
And this:

Code: Select all

class Bar {
  public function __construct($foo) {
    $this->foo = $foo;
  }
  public function bar() {
    $this->foo->bar();     // you could forget to do this
  }
}
Sorry to re-rail this slightly, but one thing I think is extremely stupid in PHP's abstraction implementation, is if the overriding child method has a different method signature, in STRICT standards, PHP will puke out a notice. This on several occasions alone has made me prefer composition :D

//back to reading this thread from the shadows.. good read.

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 3:35 pm
by VladSun
John Cartwright wrote:I think is extremely stupid in PHP's abstraction implementation, is if the overriding child method has a different method signature, in STRICT standards, PHP will puke out a notice. This on several occasions alone has made me prefer composition :D
So, John... You want a stricter (and more verbose of course) PHP language or not? I'm really confused now...

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 3:46 pm
by John Cartwright
VladSun wrote:
John Cartwright wrote:I think is extremely stupid in PHP's abstraction implementation, is if the overriding child method has a different method signature, in STRICT standards, PHP will puke out a notice. This on several occasions alone has made me prefer composition :D
So, John... You want a stricter (and more verbose of course) PHP language or not? I'm really confised now...
I prefer a language to be as strict as possible, or at least be consistent. But there is absolutely no reason to be strict about a method signature that you are overriding in a dynamic language. If the abstract class implemented an interface, sure.. complain. This all stems from the fact that PHP does not recognize method signatures in regard to defining duplicate methods with different signatures. I.e.,

function doFoo() {}
function doFoo(Some_Class $bar) {}
function doFoo(Some_Other_Class $bar) {}

Re: Namespaces and abstract class names

Posted: Tue Feb 08, 2011 3:51 pm
by VladSun
So, you complain about having no function overloading in PHP, but you complain about having a strict interface (including method signature)?
John Cartwright wrote:
VladSun wrote:
John Cartwright wrote:I'm a supporter of multiple signatures depending on the context. If instances where a wide variety of people will use my code, I will opt for a mixture between #1 and #3, similiar to how Zend supports the injection of a config object.
Every time I see it, I start to think why PHP doesn't support function overloading, while it supports type hinting :)
Believe me.. I think about this everyday.
That's why I said I were confused in my prev. post.