|
|
 |
|
 |
|
| Re: Standardized Euphoria
|
|
============ The Euphoria Mailing List ============
posted by: Chris Bensler [bensler at nt.net]
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 percent 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
--^----------------------------------------------------------------
This email was sent to: [email removed]
Or send an email to: [email removed]
For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------
[December 24, 2006]
|
|
