OpenEuphoria

Re: Standardized Euphoria

• Posted by Chris Bensler <bensler at nt.net> Dec 24, 2006
• 682 views

cchris005 wrote:
> 
> > 
> > Subject: Re: Standardized Euphoria
> > 
> > 
> > posted by: Ray Smith <ray at RaymondSmith.com>
> > 
> > Chris Bensler wrote:
> > > "1. Besides additional functionality, I would prefer to
> > > redesign/reorganize
> > > the
> > > existing libs. Would this be acceptable to people?
> > 
> > Do you mean change the current include files so they aren't compatible
> > with 
> > the current version?
> > 
> > I'd say no to this.
> > 
> > Make your new libs based on the old ones (make copies and rename to
> > something
> > else) go crazy, go nuts break all compatibility if you want.  If they
> > turn out
> > to be superior they will eventually replace the current versions.  BUT
> > don't
> > change the current libs without the alternative released, tested and 
> > documented well before it becomes "official".
> > 
> > Regards,
> > 
> > Ray Smith
> > <a href="http://RaymondSmith.com">http://RaymondSmith.com</a>
> > 
> 
> Let's not get nuts about this compatibility breaking.
> 
> Does it make sense to have more useful features in a language, yet
> abstain to change the form (arguments, return values...) of standard
> library routines written 10 years before?
> 
> I'd say no to this.
> 
> Does it make sense to keep the organisation of routines or symbols
> inside files the same when the scope covered by the libraries grows, the
> technical environment changed so much (who still draws ellipses under
> DOS, or in text mode for that matter?)?
> 
> I'd say no to this.
> 
> I'd say you are both right. 
> 
> We are at a turning point in the history of Euphoria, and it is probably
> the right time to make substantial changes and reorganisations, some of
> which may break some backward compatibility. Otherwise, Eu will remain
> compatible with 386 machines and will end in the dump as well.
> 
> However, this must done with great care:
> * testing and documentation must be impeccable;
> * mechanisms must be there to allow say 95% of legacy code to keep
> running, perhaps less efficiently;
> * As a community, we should collectively help in porting or rewriting
> the tricky pieces of code which are in use and would be left on the
> roadside even with the abovementioned mechanisms on.
> 
> As for examples of stuff which could help enhancing and reorganising the
> current basic functionalities, you may glance at various files in
> oedoc.free.fr/Fichiers/ESL/  Since the project seems to go nowhere, let
> it be a part of the hopefully upcoming lift-up.
> 
> CChris

Thank you CChris, those are my sentiments exactly.
As I said in a previous post: "Backward compatability should be a concern, not a
mandate."
If we allow it to be a mandate, progress stagnates or at least must be
compromised.

There seems to be a major misconception that just because I said the libs would
break compatability that there won't be any way for them to be compatible. If I
thought I could get away with that, I would just write docs for Empire and save
myself a huge pile of extra work.


Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria