SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 31 of 31
  1. #26
    SitePoint Zealot Rotwang's Avatar
    Join Date
    Jun 2005
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    Just don't get me started on the issue of visibility in OOP.
    I disagree with you about everything being extensible, but that part about instances having different exposure than the class definitions is brilliant. And I like the idea of having only methods be able to be public.

    While I'm typing, I've always thought that "protected" was a terrible choice of word to describe what it does. (Hell, isn't "protected" practically a synonym for "private".) My word for that would have been "family".

  2. #27
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rotwang View Post
    I disagree with you about everything being extensible, but that part about instances having different exposure than the class definitions is brilliant.
    Uhh...
    Thanks, I guess.

    Anyway, the reasoning behind everything being extensible is this: In OOP, each object represents, well, an object -- often an abstract one, but sometimes a real one (let's say, a duck). The problem is that too many times we get sidetracked by the classes, and forget that it's the actual objects that matter; and further, we get sidetracked by the implementation details and forget that they're not important.

    The only situation where there should be any inheritance is when the subclass actually represent a sub-type of its parent. I know that this is a too rigid and exclusive standpoint, and in real situations I dismiss it as well, but ideally, this is all that makes sense. Imagine that we have "limp ducks", which are a subspecies of "normal" ducks, differing from them only by, say, not being able to fly. They share all their other properties, and in programming terms we say that the subclass inherits them and changes those that differ. The current "private" keyword was developed as being as rigid as it is in most modern language as a (bad) way to prevent bad programmers from doing harm, not to promote OOP principles.

    Quote Originally Posted by Rotwang View Post
    And I like the idea of having only methods be able to be public.

    While I'm typing, I've always thought that "protected" was a terrible choice of word to describe what it does. (Hell, isn't "protected" practically a synonym for "private".) My word for that would have been "family".
    Actually, I was thinking more along the lines of "default" (i.e. having no special keyword) and "public". Unlike most modern OOP languages, I would set "private" to be the default, with only those properties that we want exposed as "public" -- i.e. the API. This way we care only about an object's behavior, and we don't really care about its internals.

    And I was partially wrong in the previous post, as there is one language that comes close to what I described, and that is Javascript.

  3. #28
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    The only situation where there should be any inheritance is when the subclass actually represent a sub-type of its parent.
    Concrete class inheritance (Eg. class Foo extends Bar) really does two things at once. 1) Foo inherits the type of Bar (type inheritance) and 2) Foo inherits the implementation of Bar (implementation inheritance). It's unfortunate that the language semantics mix the two things together, since they are really two completely separate issues.

    Theoretically, type inheritance is very useful, since it allows polymorphism, whereas implementation inheritance is an ugly hack. Like many ugly hacks, it's sometimes useful in the real world, even if it's impure from a scientific point of view. It can always be replaced with composition, but it may take a little more effort. The more experienced people become with OOP, the more they tend to avoid implementation inheritance, and use composition instead.

    Pure type inheritance can be achieved in statically typed languages through interfaces, and in the case of dynamically typed languages such as PHP, by magic. The conclusion on this would be that inheritance is completely unneeded in PHP, unless for nasty shortcuts. Then again; Some would argue that PHP is the incarnation of ugly shortcuts in the first place.

  4. #29
    SitePoint Zealot Rotwang's Avatar
    Join Date
    Jun 2005
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Pure type inheritance can be achieved in statically typed languages through interfaces, and in the case of dynamically typed languages such as PHP, by magic. The conclusion on this would be that inheritance is completely unneeded in PHP, unless for nasty shortcuts. Then again; Some would argue that PHP is the incarnation of ugly shortcuts in the first place.

    Good post. But in a way, if you're against implementation inheritance, then you're really against inheritance in general, and rather, in favor of using interfaces instead, right? One could say that an interface is like inheritance without the implementation, no?

    My view is implementation inheritance is ok if the class being inherited from explicitly expects (and allows) it, and was created with the intention of being extended.

    Also you're venturing onto the strong typing debate . (I think the worst thing about php/python is the weak typing. Oh, excuse me, "dynamic typing", the politically correct term. (Well, actually the worst thing about python is the whitespace thing, but now I'm in double perens.)) Much like the original post, one could say, as you kind of did, "why bother creating interfaces in php? it will work anyway if you don't." The original poster asked "why bother declaring public...". I want all those declarations to be required, as in java or AS 2/3...

  5. #30
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Rotwang View Post
    One could say that an interface is like inheritance without the implementation, no?
    Yes, that's exactly the case. And when BerislavLopac says that inheritance should always follow the is-a principle, he's really suggesting that inheritance should only be used if you intend to both inherit the type and the implementation. If you only need one of those feats, you should either use interfaces (type inheritance) or composition (implementation inheritance). As I already mentioned, interfaces are redundant in PHP, so in the first case, you should simply do nothing.

    Quote Originally Posted by Rotwang View Post
    But in a way, if you're against implementation inheritance, then you're really against inheritance in general, and rather, in favor of using interfaces instead, right?

    My view is implementation inheritance is ok if the class being inherited from explicitly expects (and allows) it, and was created with the intention of being extended.
    I may have been unclear about it, but I agree that implementation inheritance has it uses. It's for pragmatic reasons more than theoretical though. Some languages have other means for reuse of implementation than inheritance. I believe constructs such as mixins are an attempt to solve this issue in a more elegant way. However, we must work with the tools which the language supports, and that means inheritance.

    Quote Originally Posted by Rotwang View Post
    Also you're venturing onto the strong typing debate . (I think the worst thing about php/python is the weak typing. Oh, excuse me, "dynamic typing", the politically correct term. (Well, actually the worst thing about python is the whitespace thing, but now I'm in double perens.))
    Dynamic and weak typing are not the same thing. PHP has both weak and dynamic typing. See: http://www.artima.com/weblogs/viewpost.jsp?thread=7590 and http://en.wikipedia.org/wiki/Type_system

    Quote Originally Posted by Rotwang View Post
    Much like the original post, one could say, as you kind of did, "why bother creating interfaces in php? it will work anyway if you don't." The original poster asked "why bother declaring public...". I want all those declarations to be required, as in java or AS 2/3...
    The whole static vs. dynamic type debate is an old one. PHP is an interesting case, since it's initially on the dynamic side of the fence, but the class system, which was inherited from Java, has pulled it in the opposite direction -- Most notably with typehints. This is a natural consequence of mixing oil and water, but exactly therefore, I don't think these constructs will ever become mandatory in PHP. The lesson, I think, is that PHP supports multiple paradigms; You can mix procedural with object oriented and statical typing with dynamic typing. This is a great strength of the language, but it means that you have to relax a bit on theories, since you have contradictory forces working within the same context.

  6. #31
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post

    And I was partially wrong in the previous post, as there is one language that comes close to what I described, and that is Javascript.
    That also applies to ruby, consider:

    Code:
    class Klass
       def initialize
          @priv = 'secret'
        end
        def foo
            puts @priv
        end
    end
    
    obj = new Klass
    
    obj.priv # no-no
    obj.foo # ok
    There's no (direct) way to read priv from outside of 'obj' (not 'Klass'), however Klass' and its descendants' methods have no problem accessing it.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •