OpenEuphoria

Re: question on func equal_from

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.?om> Jul 29, 2007
• 701 views

ChrisBurch2 wrote:
> 
> If OOP is implememented in the core of Euphoria, will it degrade its current
> efficiency / speed levels? If it doesn't, then I have no 'object'ion 
> whatsoever
> to having it added. You are right, I do not wish to impose my opinions on 
> anyone else, and you can do whatever you wish the language, as long as
> 
> 1. It doesn't degrade it (speed / efficiency / code maintanability etc)
> 2. Doesn't break backward compatability
> 

I believe that ooeu satisfies these conditions.  I wouldn't, however, claim
that it is a 'full' OO system.  It lacks real polymorphism, although I've
thought about it, and I think it could be done quite reasonably.

There's probably a slight slowdown in the front end, but I doubt that it's
significant, especially for code that doesn't use any of the OO features.
The il code is actually 100% vanilla eu code.  Basically, the front end just
converts an OO-call to normal euphoria calls (kinda like C++ does).  For 
example:

euclass Foo( sequence f )
-- Declaring variables inside of a euclass define the members of a euclass.
-- Automatic constants are created:  Foo.baz can be used, and would equal
-- 1.  Or dot notation is available for variables of type Foo: foo.baz
integer baz

	function Foo() : Foo 	-- the ": Foo" just lets the front end know
				-- the return type of the function
		return {0}
	end function

	procedure bar()
		? this
	end procedure
end euclass

Foo foo
foo = Foo()  -- calls the Foo constructor to initialize foo

-- calls the Foo.bar() method, which internally, really looks
-- like bar( Foo this ), and the procedure call is equivalent
-- to bar( foo )
foo.bar()

? foo.baz  -- equivalent to foo[Foo.baz], or foo[1]

Again, this code would emit normal euphoria il code, no back-end magic
required.  I think it does need (as CChris alluded) some run-time type
checking enhancement, as well as virtual routines, which would require
some back-end magic, but, again, shouldn't affect non-OO code at all.

For some tasks, OO languages drive me nuts, but there are other times when
they really do make some things a lot easier.

Matt