OpenEuphoria

Re: Standard Euphoria Library project

• Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 15, 2005
• 582 views

I'm sorry for the delay in replying. I was a little distracted.

Jason Gade wrote:

> Christian Cuvier wrote:
>>
>> From: "Juergen Luethje"

<snip>

>>> Then maybe we should write down some internal standards, i.e. an
>>> internal naming convention, and a standdard for the way we create the
>>> modules of our library. We could use the text that Derek posted here
>>> recently as guideline.
>>>
>>> Just some more thoughts:
>>> - Build one module after the other.
>>> - When one module is finished, release a new version.
>>> - For a new module, first someone writes the specs.
>>> - The specs are discussed in the project group.
>>> - Then one (ore more) person(s) write(s) the code for the module.
>>> - Then at least 2 persons -- and only persons who didn't write the
>>>   code -- check whether the code meets the specification independently
>>>   of each other. One of these "peer reviewers" should be an IT
>>>   professional.
>>>   ( Well, how much of them participate in the project?    )
>>> - The documentation should be written (or at least be "polished") by
>>>   native English speakers.
>>>
>>
>> On the principle, I agree again with all points. However, we can make
>> things much simpler as follows:
>>
>> C++ provides a Standard Temlate Library which is remarkably
>> well-thought, and whose design was polished by hundreds of qualified
>> persons. Why reinvent the wheel?

I agree. I just didn't see the wood for the trees. 

>> Let's start from the public specifications for this "library", and the
>> only job left, apart from coding, will be to define which areas won't be
>> implemented (mostly because of the limitations Eu has). Docs already
>> exist, they'll have to be translated into the framework of Euphoria (for
>> instance, Eu has no pointers...). Again, the idea is not to start from
>> scratch.
>
> Isn't the STL mostly or all container classes?  Many of those wouldn't
> apply to Euphoria because of the existence of sequences.  The ones that
> do could easily be done in libraries.

I know almost nothing about C++. I have a little book about C and C++,
but after reading the 3 pages about templates, I'm none the wise.
Many pages in the book are dealing with the C runtime library. Maby we
should take that as model? C is a procedural language like Euphoria,
while C++ is object-oriented. So I think C is closer to Euphoria, isn't it?

>> Another thought: specs are good, but the end user generally can't use
>> them. There will be a need for an User Guide to supplement the specs.
>> That User Guide should be written by people not involved n writing the
>> specs. It will be organised around the users' needs (tasks to perform),
>> showing how the tools in the library can be used for completing these
>> tasks. The fine technical points will be covered either in the specs or
>> in specific release notes, according to their being more or less structural.
>
> Use the Makedoc from win32lib and document the library properly...

I'll have a look at it. I'll also again have look at Tommy's Kanarie, to
see how good it might be suited for this task.

So what do we need to start:

o Some pages on the web.
  - Christian's site, my site, SourceForge?

o There we'll write down
  - A mission statement
  - Coding guidelines
  - A list of say 3 to 5 .e files that should be contained in the first
    release.
  - A list of contributers (Who will do what?)

...

I don't have any experience with organizing such a project.

Regards,
   Juergen