Re: Standardized Euphoria
Michael J. Sabal wrote:
>
> Chris Bensler wrote:
>
> > 1. Besides additional functionality, I would prefer to redesign/reorganize
> > the
> > existing libs. Would this be acceptable to people?
>
> What is it about the existing libraries (both RDS and community) that you find
> inadequate structure-wise? If you're thinking about the OOP way of including
> libraries (include System.IO.Net), I would say limit your innovation to OOP
> variants of Euphoria. Personally, I don't see the system as broken. If I
> want
> to use RDS's get.e, I just include it. If I want to use my own personal
> modded version, it's no more work than copying or renaming a file or two.
No, I'm not talking about OOP. It's unfortunate that so many people
automatically associate 'modularity' with OOP, they aren't related.
Every programmer should practice modular programming, regardless of what
language or paradigm you use.
get.e is an excellent example of why the libs should be reorganized. Have you
studied the code it contains? It's extremely useful!, but it's localized. A
proper library for dealing with streaming text would be much more beneficial to
everyone.
database.e is another good example. It contains localized code to deal with
serializing eu data objects.
Misc.e and machine.e should both be split up into about 5 or 6 files in my
opinion.
Yes it works now, but it could be much better.
The key concept of modularity is that you don't want to duplicate code.
Duplicating code means duplicating problems.
> Don't get me wrong - I'm not against anybody trying to improve the tools. I
> just don't see any benefit for the general applications I write. Perhaps a
> more detailed explanation of the gap would help me understand your point of
> view a bit better.
>
> Mike Sabal
The main issue is organization.
When new functionality is added, it would be prudent to split up misc.e and
machine.e to correspond with more meaningful categorizations. EG a math library,
or a sequence library, or a string library, or a mem i/o library to compliment
machine.e
If machine.e contains poke_float() etc, and I would like to add all the missing
peek/poke routines, plus a bunch of other closely related functions for bit and
byte manipulations, should I just stuff them all into machine.e as well? Would it
make sense to have some functions in one library, and the rest in another file,
in an API that is supposed to be a standard?
Another issue is convenience and pollution.
I would like to move all the RDS libs into a subfolder of the include path.
This would make it so a person could just copy the whole subfolder into their
project and that's it, they dont' even have to think about what files are
included. It's an API, it should be treated as an API, not just a collection of
unrelated library files. Granted, you normally wouldn't be distributing the
standard includes, but they should set an example for how other API's should be
structured.
If it's agreed that API's should be stored in subfolders instead of directly in
the include path, then it would be desirable to have the RDS libs behave the
same. If we move the RDS libs, compatability will be broken anyways, so taking
advantage of that fact to reorganize the libs make sense.
By pollution, I mean having to place a bunch of library files directly into your
project folder, the alternative is to manually move them to a subfolder and
change any include references to the files. It would also be good practice to
keep the main include folders free from files whenever possible, to avoid clutter
and confusion.
Yes, I can just build upon the RDS libs as I said, but backwards compatibility
should only be a concern, not a mandate. Backwards compatability can be supported
with abstraction and deprecation, we don't have to stop moving forward at it's
expense.
I'm thinking of the future, trying to plan things for much larger scales.
Weighing the fact that a relative handful of people are already accustomed to
the existing libs is really a moot point considering the size of the community
and the archives. I could rewrite all the code in the archives myself to make it
compatible if nessecary (not that I want to, or think it's a good idea). It's not
like there is a very large selection of Euphoria resource sites available that
would make a mass port impossible.
I wish it were a problem and it should be.
Think about why not many people are using Euphoria. To think that it isn't
popular simply because it's not well known is lying to ourselves.
Why are other languages, which are seemingly inferior much more popular?
This is where my thoughts and efforts towards Euphoria lay.
I'm not saying that I think that it's because the RDS libs are bad, but
improving them would be a step in the right direction.
In a nutshell, I beleive Euphoria fundamentally has a problem with scalability.
It's slowly being addressed in the language itself, but besides that we also need
a much more expansive set of standard libraries for Eu. They don't have to all be
part of the distribution, but they should be geared to compliment eachother.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
|
Not Categorized, Please Help
|
|
