In the grand scheme of things the advantages of polymorphism are outweighed by its disadvantages. That's because giving the same name to different things inevitably leads to confusion, and that's exactly what polymorphism is all about: The same names, and confusion.

Take the Clipboard() function for example. It comes in two flavors, the global "system level" function we're all familiar with, and a version specific to the DataWindow and DataStore controls. Both versions have the same name and both take a string argument but that's where the similarity ends.

Here's an example:

   clipboard ( "Hello, World!" )

How does PowerBuilder choose which one to call? Well, a CommandButton doesn't have an object-level Clipboard() function defined for it so PowerBuilder must use the global definition. On the other hand, the DataWindow control does have an object function called Clipboard() so even if you don't say "this.clipboard()" it will assume it. And call the wrong function. Yay. Isn't polymorphism wonderful?

There doesn't appear to be any way to force a DataWindow script to call the right function. One workaround is to define a global function of your own, with a different name like f_clipboard so PowerBuilder won't drag you into this polymorphic trap.

Define f_clipboard with a string return value and a single string argument, and a script that looks like this:

   return clipboard ( as_string )

This is only one example of the confusion caused by polymorphism, and it's accidental. Most polymorphism is done on purpose, and it's just as confusing.