http://www.perlmonks.org?node_id=237892


in reply to Re^5: Teach him a lesson with facts
in thread Teach him a lesson with facts

I don't know where this meme started . . .

Possibly on page 321 of the blue Camel, just under the "Class Inheritance" subheading:

As with the rest of Perl's object system, inheritance of one class by another requires no special syntax to be added to the language.

The -> operator denotes a referance, which has plenty of use outside OO. In this case, were referancing a subroutine from a bless'd variable. I'm not sure about SUPER::.

----
Reinvent a rounder wheel.

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re^7: Teach him a lesson with facts
by adrianh (Chancellor) on Feb 23, 2003 at 18:34 UTC
    As with the rest of Perl's object system, inheritance of one class by another requires no special syntax to be added to the language.

    Inheritance didn't need extra syntax (it's just assigning to @ISA). Method invocation did.

    The -> operator denotes a referance, which has plenty of use outside OO. In this case, were referancing a subroutine from a bless'd variable. I'm not sure about SUPER::.

    Well, since references and OO came along in the same release you could argue that the syntax needed to be added for OO ;-)

    While the lexical item "->" is the same, the syntax for $object->method is different from $arrayref->[...], $hashref->{...}, etc. It needed to be added for OO (just as we got $coderef->(...) syntax added in 5.003_98 - as the result of a bet I seem to recall)

    While something like indirect object syntax was around in perl4 (witness print FILEHANDLE) I think it disingenuous to call it the same syntax as method $object and method Package - hacking of the parser was necessary.

[reply]
[d/l]
[select]
      ;-) Pure tech discussion.

      One problem with Perl OO is that it does not deliver everything OO requires in theory. That we all see it, and I saw you agreed.

      Another big problem I see with Perl OO is that, becasue of Perl OO is usually implemented as hash, and Perl hash takes lots of memory, this "bad" combination actually make things worse.

      I think something need to be done about this, before Perl's OO can be 100% accepted by me, actually not just me ...
[reply]
        One problem with Perl OO is that it does not deliver everything OO requires in theory. That we all see it, and I saw you agreed.

        Actually, what I said was "It lacks useful things like direct support for private methods/attributes. However, these can be implemented using other language features. It's rarely an issue in real world code in my experience." (my emphasis).

        Perl's OO model has good and bad points. Personally I prefer Perl's OO and dynamic typing to Java's lack of multiple-implementation inheritance and lack of generic classes.

        I'm not anti-strong typing. When done well (e.g. Eiffel) it can be a god send. With Java's lack of generics it can be a complete pain.

        Another big problem I see with Perl OO is that, becasue of Perl OO is usually implemented as hash, and Perl hash takes lots of memory, this "bad" combination actually make things worse.

        If memory is an issue. Like speed it often isn't. When it is, there are alternate mechanisms for representing objects. I have never had memory problems due to using hashes as objects.

        I think something need to be done about this, before Perl's OO can be 100% accepted by me, actually not just me ...

        Perl 6 will be providing most of what is "hard" to do directly in Perl 5.

        If you're unhappy with Perl 5's "default" OO model you have the flexibility to write your own. Witness such neat modules as Class::Contract.

[reply]

In Section Meditations