Page 5 of 7

Re: oop question

Posted: Wed May 20, 2009 5:34 pm
by Jenk
Type Hinting - Evil, yes. If the parameter quacks, it's a duck. I don't need a label ensuring it's a duck first. I don't need to know it'll be a duck before hand, and I don't need an error telling me it won't quack, but when it doesn't, I'll still get the error.

Interfaces are just pure superfluous and a work around for type-safe language authors that just don't understand that it is the very fact they are using type-safety in the first place which is causing their problems. Generics? Another type-safe workaround (hack) that is not addressing the true problem.

Flame away, I'm sure you will bring up globals and constants again.

Re: oop question

Posted: Wed May 20, 2009 5:39 pm
by Christopher
:) I am in general agreement with you about both Type Hinting and Interfaces. But then I am a duck typer too. But that does not mean I think that those features should not be in the language. I find them handy sometimes, just like public/private. ;)

Re: oop question

Posted: Wed May 20, 2009 5:57 pm
by Jenk
Glad we agree on something then :P

The only plausible choice for Interfaces is when using a 3rd party library, it gives a clear place to read what my code should implement, but then a decent comment/doc will do that, too.

Re: oop question

Posted: Wed May 20, 2009 6:13 pm
by alex.barylski
I am a Smalltalk programmer, but I'm not quite sure what you mean by functional? If you mean procedural - then no, anything but
Huh my bad...I was sure it was you that I had disscussions about funcitonal programming with...
Whilst in Smalltalk there is no means to access a member variable directly, it is impossible to restrict them. The methods #instanceVariableAt:, #instanceVariableNamed: (and partnering putters) means no variable is safe :p If they were 'private' you would never be able to debug, and you'd be in some serious head scratching territory when something goes wrong
I'm not sure I follow...for starters any syntax that is different from C/C++ usually turns me away. :P

Anyways, Smalltalk has not access control for member data? Interesting.
Interfaces are just pure superfluous and a work around for type-safe language authors that just don't understand that it is the very fact they are using type-safety in the first place which is causing their problems. Generics? Another type-safe workaround (hack) that is not addressing the true problem.
Interfaces, IMHO are more about setting a contract for others to follow, without providing any abstract implementation. They are really only handy when you know others will extend your code base, like a component architecture such as Joomla, it would be nice if they provided an interface which all custom components could implement, that way when I tested and nothing happens at least with an interface I would be told by PHP that some methods were not implemented.

Also I fail to realize why type-checking is so bad? I think the more restrictions set forth by your language, framework, etc (assuming they are time tested and qualify as best practices) force a developer to solve problems a certain way.

What happens when you pass a registry object to a request parameter? Without type checking everything passes and because of the dynamic property nature of both objects, calling on a property named "locator" or something similar would result in potentially hours of frustration, trying to figure out why the object isn't initialzed correctly at the point of use, despite it being set properly just before the injection site. It's only after you print_r() the $request object that you realize the type of object is actually 'registry' and you go back to your code and see you accidentally got the 2 parameters backwards (registry instead of request, visa versa).
The only plausible choice for Interfaces is when using a 3rd party library, it gives a clear place to read what my code should implement, but then a decent comment/doc will do that, too.
Lets be realistic...documentation almost always comes last...if at all. Self documenting, self describing code works best. It's easy to read, nothing is duplicated or extraneous and everyone wins.

Re: oop question

Posted: Wed May 20, 2009 6:52 pm
by Jenk
Agreed, self documenting is best, but every capable IDE will display a PHPDoc comment as you hover or autocomplete a method/property.

Smalltalk is completely Dynamically typed. I really had no idea how much of a blessing it is to be rid of types until I tried Smalltalk. Even PHP (even before type-hinting in php5) really pales in comparison to the 'freedom' offered in ST.

My day-to-day job involves multiple langauges. This month alone I have developed Smalltalk, *spit* Java, C#, and *spit* VB6. I, honestly, with absolute first hand experience, categorically and emphatically state as fact that more time is spent faffing with types and interfaces than actually dealing with problems and design when using Java, C# and VB6. Even the hardcore C# and Java developers in my office, who turn their nose up at ST and other dynamic languages, agree that a lot of time is spent on deciphering which types/interfaces/namespaces should be used, etc.

One key example, is a problem I was facing earlier this year in C#. I was tasked with creating a wrapper for a new WSDL service offered by a client, to interface with a VB6 COM application of ours. Whoopee.. water carrying.

Two of the services, which have different namespaces, are identical - except for the addition of one property. So, simply extend one service with the other, right? Wrong. In C#, you cannot override the type of a datafield, without overriding everything that needs to interact with that datafield as well, or your write converter delegates as a property, else you face the off chance that you just might get a runtime error. What was utterly annoying about this? The datafield I was overriding was *identical* to the super, in every given way, except for the namespace.

"Type-safety" is the compiler author's answer to "I can't be bothered doing forward lookups" .. in Smalltalk, when you call a method (aka: send a message) the object is first asked if it responds to it; if it doesn't, it will say (literally) Message Not Understood: <detail of message> in an exception. At runtime. Not "this might be a problem so I won't compile" not "I've looked for you, I refuse to build because this might not understand this, based on the contract it hasn't signed over there."

In Java, C#, etc. type-safety is enforced so that you never get to this lack of functionality, and there are problems that happen because of it; and often incorrectly shrugged off as a design problem. In fact sometimes code smells enter the foray just to get around these problems, such as mine above, it ended up being a copy-paste of code.

If Java, C#, et al. just simply wrote a decent compiler/runtime the world would be a better place. If everyone stopped using private/protected, birds would sing, the sun would shine and Jenk would not feel patronised, insulted, and like ripping his hair out so much. :D

Re: oop question

Posted: Wed May 20, 2009 7:00 pm
by John Cartwright
Very interesting discussion indeed, however, I'm sorry you feel insulted Jenk. I hope that doesn't discourage anybody. :)

Re: oop question

Posted: Wed May 20, 2009 7:31 pm
by Jenk
Like I say, I speak frankly. I'm no more insulted than being sworn at by a drifter. Well, maybe a bit more as it causes me agro sometimes :P

Re: oop question

Posted: Wed May 20, 2009 7:46 pm
by alex.barylski
Agreed, self documenting is best, but every capable IDE will display a PHPDoc comment as you hover or autocomplete a method/property.
Meh...honestly I hate those little popups that get in way so I disable them if on anyways. UltraEdit is nice as it lets you hilite words and click a button for "google", "dicitonary.com", "yahoo answers", etc. I prefer that. :)
Smalltalk is completely Dynamically typed. I really had no idea how much of a blessing it is to be rid of types until I tried Smalltalk. Even PHP (even before type-hinting in php5) really pales in comparison to the 'freedom' offered in ST.
One mans treasure is another mans trash I suppose. I didn't realize how much I missed strictly typed languages until I switched from C/C++ to PHP. Sure annoying compile time errors are a b*tch but all that checking sure does help.
This month alone I have developed Smalltalk, *spit* Java, C#, and *spit* VB6. I, honestly, with absolute first hand experience, categorically and emphatically state as fact that more time is spent faffing with types and interfaces than actually dealing with problems and design when using Java, C# and VB6. Even the hardcore C# and Java developers in my office, who turn their nose up at ST and other dynamic languages, agree that a lot of time is spent on deciphering which types/interfaces/namespaces should be used, etc
I'm not sure I understand. There are some instances where types get annoying, especially in C++. But it's usually when passing a string of CString to a method that requires an ATL string, in those cases casting becomes a bit of a PITA. For general development though, especially when not mixing different libraries/frameworks, etc...having a strong type check is a life saver.

To often I have made the mistake of passing one object type instead of another, but both were almost compatible in interface so nothing was said or done and I wasted hours tracking down the bug when a simple type check would have solved the issue in seconds.
Wrong. In C#, you cannot override the type of a datafield, without overriding everything that needs to interact with that datafield as well, or your write converter delegates as a property, else you face the off chance that you just might get a runtime error. What was utterly annoying about this? The datafield I was overriding was *identical* to the super, in every given way, except for the namespace.
You lost me there I haven't done any development (outsideof experimentation) in C#...
"Type-safety" is the compiler author's answer to "I can't be bothered doing forward lookups" .. in Smalltalk, when you call a method (aka: send a message) the object is first asked if it responds to it; if it doesn't, it will say (literally) Message Not Understood: <detail of message> in an exception. At runtime. Not "this might be a problem so I won't compile" not "I've looked for you, I refuse to build because this might not understand this, based on the contract it hasn't signed over there."

In Java, C#, etc. type-safety is enforced so that you never get to this lack of functionality, and there are problems that happen because of it; and often incorrectly shrugged off as a design problem. In fact sometimes code smells enter the foray just to get around these problems, such as mine above, it ended up being a copy-paste of code.

If Java, C#, et al. just simply wrote a decent compiler/runtime the world would be a better place. If everyone stopped using private/protected, birds would sing, the sun would shine and Jenk would not feel patronised, insulted, and like ripping his hair out so much
So if type casting is the root of evil...what the is your alternative to my situation -- when passing two almost identical objects (interface anyways) and experiencing an issue because the wrong object is being queried -- not instance but type. Such a trivial little error but can cause so much confusion and frustration. Likewise, when running a program like 'lint' to catch assignment instead of equality tests inside conditionals, etc. I find language tools like this extreely helpful in writing solid code. Second only to keeping things as simple and following SRP as possible that is. :P

The alternative is (as far as I can tell) to explicitly check for the type inside the method being passed said object and throw an exception. In this case, I would rather have it implied in the interface via a type hint/cast. :)

Cheers,
Alex

Re: oop question

Posted: Wed May 20, 2009 7:50 pm
by Christopher
Jenk wrote:If everyone stopped using private/protected, birds would sing, the sun would shine and Jenk would not feel patronised, insulted, and like ripping his hair out so much. :D
I was thinking about why I really use private/protected and I realized that the main reason was to make Jenk feel patronised, insulted, and like ripping his hair out...

Sun sure is bright over here ... hey! ... can someone make those birds shut up!

Re: oop question

Posted: Wed May 20, 2009 7:55 pm
by Jenk
PCSpectra wrote:So if type casting is the root of evil...what the is your alternative to my situation -- when passing two almost identical objects (interface anyways) and experiencing an issue because the wrong object is being queried -- not instance but type. Such a trivial little error but can cause so much confusion and frustration. Likewise, when running a program like 'lint' to catch assignment instead of equality tests inside conditionals, etc. I find language tools like this extreely helpful in writing solid code. Second only to keeping things as simple and following SRP as possible that is. :P

The alternative is (as far as I can tell) to explicitly check for the type inside the method being passed said object and throw an exception. In this case, I would rather have it implied in the interface via a type hint/cast. :)

Cheers,
Alex
It wouldn't be an issue because there is no such thing as "type" in ST.. so if your problem is ObjectA was updated instead of ObjectB.. well, your tests will highlight this for you (or just general usage). :)

Re: oop question

Posted: Wed May 20, 2009 7:56 pm
by Jenk
arborint wrote:
Jenk wrote:If everyone stopped using private/protected, birds would sing, the sun would shine and Jenk would not feel patronised, insulted, and like ripping his hair out so much. :D
I was thinking about why I really use private/protected and I realized that the main reason was to make Jenk feel patronised, insulted, and like ripping his hair out...

Sun sure is bright over here ... hey! ... can someone make those birds shut up!
That's a more plausible reason than any other you've posted.

Re: oop question

Posted: Wed Jun 24, 2009 11:37 am
by kaisellgren
Sorry if this topic is too "old", but...
Jenk wrote:Also, a simple PHPDoc syntax comment, which is parsed by any decent IDE such as Eclipse, Zend Studio, etc. will show what the comment is and my comment would be along the lines of:

Code: Select all

class Player
{
 /**
  * The number of points a player has, should be greater than -1.
  * @var points
  **/
  public $points = 0;
// etc
}
One problem with that approach is that you do not always have that simple situations (must be a positive value). Today my friend (who codes like you, which I personally don't like) encountered a problem, because a variable had to be in a certain complex value range that was so difficult to explain and many ludicrous droll terms had to be used so that no other developers in his team understood him (they weren't fluent in English). He had two choices: either put the large block of code into the comments to "describe" the possible data values, or provide an accessor. I probably don't have to tell which one he chose...

Just something interesting and funny I experienced.

Re: oop question

Posted: Wed Jun 24, 2009 12:53 pm
by Jenk
kaisellgren wrote:Sorry if this topic is too "old", but...
Jenk wrote:Also, a simple PHPDoc syntax comment, which is parsed by any decent IDE such as Eclipse, Zend Studio, etc. will show what the comment is and my comment would be along the lines of:

Code: Select all

class Player
{
 /**
  * The number of points a player has, should be greater than -1.
  * @var points
  **/
  public $points = 0;
// etc
}
One problem with that approach is that you do not always have that simple situations (must be a positive value). Today my friend (who codes like you, which I personally don't like) encountered a problem, because a variable had to be in a certain complex value range that was so difficult to explain and many ludicrous droll terms had to be used so that no other developers in his team understood him (they weren't fluent in English). He had two choices: either put the large block of code into the comments to "describe" the possible data values, or provide an accessor. I probably don't have to tell which one he chose...

Just something interesting and funny I experienced.
So why not just use:

Code: Select all

class Player
{
 /**
  * The number of points a player has, use accessor.
  * @var points
  **/
  public $points = 0;
 
  public function setPoints($points) {
    // validation code here
    $this->points = $points;
  }
}
}
?

If there's an accessor for a property, I'll use it unless it is in conflict of my needs.

Re: oop question

Posted: Wed Jun 24, 2009 2:08 pm
by alex.barylski
So why not just use:
For the opposite reason one might keep it private in the first place and just offer an accessor/mutator pair. :P

Re: oop question

Posted: Wed Jun 24, 2009 7:41 pm
by Jenk
So if, for the sake of an example, your accessors prevent me from injecting a mock/stub object as the value of that property, then what?