OpenEuphoria

Re: Win32LIb/Llama Status

• Posted by David Cuny <dcuny at LANSET.COM> Jun 25, 1999
• 476 views

Carl L White wrote:

> Looks like I may have started another
> "we want _this_ feature" thread.

I don't think I'm asking for anything new. Assuming I've diagnosed the bug
correctly (always an iffy proposition), I can't eveny start to suggest how
Robert solve the problem, because I don't know the internal workings of
Euphoria.


Roderick Jackson wrote:

> But then, were Llama ever to construct the name of the
> routine, rather than relying on a literal, we'd still run into
> the same problem... yuck.

Because of the way that routine_id is scoped (one of my running complaints
with Robert), I couldn't do this anyway. But I maintain an internal list of
method names, so the name of the function does *not* have to match the name
of the method. So I can construct names internally if I wanted - something
that I've toyed with.



Gary Dumer wrote:

> I've seen other attempts to make an otherwise
> procedural interpreted language into an OOP
> language with the result being degraded performance
> (eg. [incr] TCL). I believe trying to shoehorn OOP into
> Euphoria via Llama with never result in the same level
> of performance now enjoyed by Win32Lib.

This is, of course, true. Since all methods are akin to C virtual functions,
they are resolved at run time. Add a wrapper to these, and you have a
performance hit. The question is, it the performance still acceptable?

In prior versions of Llama, there was a lot of work involved in finding a
method - the program first check if the method was virtual or not, and then
walk up the inheritance tree to find the class which implemented the method.
It would then set the object to "spoof" that class, and then call the
method.

In the current version, all methods are "virtual" - that is, the method most
recently defined is the one executed. Looking up methods is trivial - all
method names are placed into a single (flat) table. The biggest performance
his *seems* to be the debugging stuff, which will be dropped from the final
run time anyway.

> I, from a personal... and selfish standpoint, would prefer
> that you extend Win32Lib into the BEST Windows GUI
> library for Euphoria that "money" can "buy"!

The reasoning behind OOP is, surprisingly enough, not cross-platform, but a
namespace kind of thing. It insulates the library, and allows easy extention
of new Win32 (or portable) objects.

> I know your ultimate goal is Cross-Platform GUI, but
> can't that be achieved by redesigning Win32Lib
> instead? Other developers can learn to extend it
> if you set the rules and provide examples.

Win32Lib was not designed to be extensible. Llama, on the other hand, is.

There are two general ways to make Win32Lib extendable. The first is to
extend the methods internally, such as:

   global procedure setText( integer self, sequence text )
      if myClass[ self ] = WINDOW then
         -- window handling code
      elsif myClass[ self ] = MENU then
         -- menu handling code
       else
         -- normal control
      end if
   end procedure

This gets messy very quickly. And if developer #1 adds a class to the
library, and developer #2 adds a class, then someone is going to have to
resolve those different code bases together. A better approach is:

   global procedure setText( integer self, sequence text )

      integer routine

      -- look up the routine
      routine = setTextRoutine[ myClass[ self ] ]

      -- run the proc
      call_proc( routine, {text} )

   end procedure

This way, all you need to do is include the new object in - no code to
resolve! Much, much cleaner. Same thing with hooking events.

There is so much sharing of functions between Win32 classes as it is that is
makes sense to use OOP to set up the structure. For example, all graphic
methods are defined in the Llama class are implemented in the class
Drawable. There is only a small difference between how a Window implements
these versus how a Bitmap does it - mainly in the getDC/releaseDC portion.

Extensibility is what differentiates Llama from Win32Lib, not cross-platform
compatiblity - it just turns out that the same methods that insulate classes
from each other are the same methods that insulate them from the underlying
operating system.

Class re-use is what drives the OOP model. At this point, it looks like the
correct decision.

The exception I'm worried about it fast graphic games, but at this point,
the Llama demo would seem to indicated that the performance is acceptable.
And keep in mund that the code is still under development - I haven't really
done much performance tuning.

-- David Cuny