Decoration

Decoration
Table of Contents

How does OOEU manage naming conflicts?

All routines in a class get decorated so that proper polymorphism can take place. An '@' will be appended to the routine name, followed by the datatypes of the parameters (o: object, a: atom, i: integer, s: sequence, @ClassName@: instance of some class, !UserDefinedType!: a user defined type). Also each method will have a 'this' parameter of the class' type automatically added. It won't show in the source, but can be used (like in C++). It will show up in any debug reports.

The routine signatures will be used to allow for a type of polymorphism based on the arguments supplied. The best match for the routine will be called. Since Euphoria isn't very strict with types, there may be ambiguity as to the actual data types being used. For instance, you might use an object parameter, where methods exist for either an atom or a sequence. Also, since a function can return anything, any parameter that is created as a temp from a function return will be treated as an object. If there are multiple methods that match up equally well, one will be arbitrarily picked, and a warning will be generated. You may receive run time type check errors because of this.

To get around this limitation, you can specify the return type of a function. This is used solely for purposes of polymorphism. There is no additional type checking of the actual value returned by your function. A colon (':') following the function declaration, followed by a variable type or a euclass name id used to define the return type:

ex:
  function foo() : sequence
      return "foo"
  end function

  euclass bar( sequence b )
      function bar() : bar
          return {}
      end function
  end euclass

You can use routine_id() on methods, but will need to pass the fully decorated routine name (obviously, this won't work after preprocessing--you'll need to replace all '@'s and '!'s with '_'s):

    id = routine_id( "method@class@a!my_type!si" )

However, routines in a local class will only be visible from within the file itself, unless the routine itself is declared global, even if other global classes inherit from the class.

Data members are decorated with the @ClassName as well. You can see the subscript value of a data member in trace mode by displaying ClassName@MemberName as a variable.

Decoration Table of Contents

How does OOEU manage naming conflicts?

Decoration
Table of Contents