Re^5: Law of Demeter and Class::DBI

I've wondered about this - when a behaviour you want hasn't been given to the object yet do you give that object the method that implements the behaviour or wrap it somehow? If you wrap it, how do you avoid having a zillion custom namespaces and having to have mental models of all those layers? I've recently taken to just directly giving these methods directly to the object but I wonder how you'd handle this.

Comment on Re^5: Law of Demeter and Class::DBI

Replies are listed 'Best First'.
Re^6: Law of Demeter and Class::DBI by fergal (Chaplain) on Nov 20, 2004 at 00:52 UTC
Have a look at, for example, nice it's a dialect of java with multimethods. This effectively allows you to add new methods to old classes form the outside (even ones you didn't write). Making more methods available works a lot better when you have multiple dispatch as that helps to avoid some (but not all) of the name clash issues. I think the reason this is not much more common is because it's just not possible to do in the "main" OO languages. For example, in (standard) Java, C++, Object Pascal a new method would have to be added to the virtual method table (vtable) for the class but this is a fixed structure created at compile time and you can't change it at runtime so you're stuck with whatever methods the original author thought of. It's purely an implementation issue. I think it's ironic that these "real" OO languages can't do this because their dispatch mechanism is tightly coupled to the representation they chose for vtables long ago. It's almost as if their designers hadn't heard of OO!	[reply]

Replies are listed 'Best First'.

Re^6: Law of Demeter and Class::DBI
by fergal (Chaplain) on Nov 20, 2004 at 00:52 UTC

Have a look at, for example, nice it's a dialect of java with multimethods. This effectively allows you to add new methods to old classes form the outside (even ones you didn't write). Making more methods available works a lot better when you have multiple dispatch as that helps to avoid some (but not all) of the name clash issues.

I think the reason this is not much more common is because it's just not possible to do in the "main" OO languages. For example, in (standard) Java, C++, Object Pascal a new method would have to be added to the virtual method table (vtable) for the class but this is a fixed structure created at compile time and you can't change it at runtime so you're stuck with whatever methods the original author thought of. It's purely an implementation issue.

I think it's ironic that these "real" OO languages can't do this because their dispatch mechanism is tightly coupled to the representation they chose for vtables long ago. It's almost as if their designers hadn't heard of OO!

[reply]