OpenEuphoria

Re: Euphoria 3.2 compatibility

• Posted by Jeremy Cowgar <jeremy at ?owgar.?om> Apr 24, 2008
• 667 views

OtterDad wrote:
> 
> at the risk of being flamed to death, please see my previous reply which
> relates
> to upgrades and code breaking:

OtterDad,

I completely understand and with those applications, I too would stick with
Euphoria 2.5. However, that's not to say that new programs you write cannot make
use of all the new features of 3.x and 4.x.

I also use Euphoria for production code at my work. I have not deployed to
hundreds of thousands of people, but the code we have put together at work using
Euphoria is in critical situations. The result if it fails too many times? I
suppose I would be looking for a new job.

Now, that being said, do I think Euphoria should stay as it was in 2.5? No.
Euphoria needs a more standard library. What I, and others, are working on right
now is to make a complete standard library. This is a huge jump for Euphoria. The
whole intent is to make it complete and therefore, change as little as possible
in the future.

As it stands now, each new release of Euphoria changes a little bit and could
possibly break code a little bit each release. I hate to keep going back to the
peek2s example, but it's valid. If you made (or included) your own peek2s and
upgrade to 3.2, then you will have a problem. Now, it's easily solved, yes, but a
problem.

Languages change and get better. That is what Euphoria is doing. Java, C, Forth,
Ruby, etc... they all change. Some take change better than others. Euphoria is
not one that takes change very well. For instance, in Java if you add a new
method to the string class, your not going to break a thing. In Euphoria if you
add a new method for strings called, say, pad_left(), that could potentially
break a whole lot of code if you too have a function called pad_left().

That is the only reason that we see code breakages when upgrading Euphoria while
we do not when we upgrade, say, Java. It's not because Java was designed
perfectly from the start and never changes. Like wise, Euphoria was not designed
perfectly from the start, as no language ever has.

I am doing my best to break as little as possible, but with the addition of just
1 function, things will break. I hate that, but it's true and there is nothing
that I can do about that. I am choosing function names carefully and when 4.0 is
released I hope that it will contain a very robust set of functions that will
make everyones coding much easier.

We have not changed existing functions and have no plans of doing so.

Does this make sense?

--
Jeremy Cowgar
http://jeremy.cowgar.com