1. ISO extensible Eu - Holy Wars need not apply
Greetings, Eu people:
As I was thinking about my "Why Euphoria" answer yesterday, I tried to come
up with some solutions that might act as workarounds for the extensibility
problem. Unfortunately, I'm so blamed ignorant of software design and
engineering, I'm useless. I can come up with an administrative solution,
which may or may not be useful, but technologically, I'm at a loss.
Administratively, for important projects we could define spec sheets. I
know that's asking for a Holy War on indentation styles, onEvent styles,
comment styles, etc., but I don't have another answer.
Some professor out at Stanford actually developed an application that would
take you through the design process of your application, but it was
designed for another language. What I have in mind is something similar,
where some group of Euphorians get together and flowchart a program, say a
VIDE, and determine which procedure/functions do what, what
variables/parameters get passed into those procedure functions, what return
values are needed, what global variables/constants are needed, etc.
I know this could work in Windows because of the event model it follows.
Could this work in DOS/Linux also? Would it even be useful? My idea is to
include the flowchart and specs with the source download. Any mods should
be sent back to the group with the proposed mod charted and spec'ed with
changes highlighted. Additions would be a bit easier.
The goal would be to allow anyone to work on the project in big or small
pieces. I don't have the talent to do large pieces, but I can surely handle
some of the smaller stuff in Windows, and I imagine there are a few more
like me out there. Better programmers could then bite off bigger and more
challenging chunks.
I think some other groups of Euphorians (EuOS, maybe?) have tried this in a
less formal manner, but I don't have a clue how their efforts went. If any
of you were involved in projects like this did it work? Why or why not?
Would it be worthwhile to do this for a few select projects, or is it too 1)
boring 2)constraining 3)stupid 4)controversial 5)useless 6)all of the above?
2. Re: ISO extensible Eu - Holy Wars need not apply
How will your ideas make the Euphoria langauge's core extendable ?
The problem is the limited extendability of Euphoria in core of the
langauge and that can only be changed by RDS.
3. Re: ISO extensible Eu - Holy Wars need not apply
Although what I actually meant was a way to make the actual apps in Eu
extensible, it's possible that a spec sheet could help extend the language
also.
You can look at it this way: Win32lib is in reality an extension to Eu,
written in Eu. If Win32lib were broken down into easily-digestible modules
(like Llama was going to be) and completely and totally spec'ed out (don't
panic David, I don't mean by you! LOL!), when someone wants to add to the
library, it becomes much easier. Windows only has about 17,000 API calls to
wrap. In dos, I think you're working more from a blank sheet because you're
not wrapping .dlls, but the principle is the same for the libraries.
I think the compiler should be a big help. Eu programmers will (or SHOULD)
be able to add .dlls written in Eu to extend the language. I have no
problem with using .dlls to extend the language, provided they're small and
fast.
However, coming up with an easy way to extend apps is also a priority I
think. That's a major draw for OOP. If you can do it without OOP, it's a
major coup because you avoid the baggage of OOP - the slowness and bloat.
It also makes the language attractive in yet another way to both newbies
and pros, because it's not only easier to extend and build on small
modules, it's less time consuming and less frustrating, and it makes code
reuse a possibility (though I've heard most pros don't like the idea of
code reuse even under OOP. I don't have that problem - I'm neither a pro
nor ambitious and energetic). It's pretty simple (but not easy) to set up
an administrative way to make applications extensible, which is why I ask
the question: would it be useful to add structure to these important
projects?
As an example of how the spec sheets would help newbies write better code,
let me use EuDesigner. If you use EuDesigner under Windows, you get a
standard output every time. If a newbie uses EuDesigner 25 times for 255
different programs, when she opens up an example program from JoeBob, who
is also using EuDesigner, she can immediately understand the event code,
and window creation calls. That's one less thing she has to worry about. If
the .eup file is included, she can open that right up in Eu, and add
buttons, or lists, or whatever to the app. If there was a spec sheet and
program flow chart with it, would it help newbies? I dunno. I SUSPECT it
would, but I don't know enough to tell you. Sure wouldn't hurt.
Question is: is it worth the hassle?
4. Re: ISO extensible Eu - Holy Wars need not apply
SR Williamson wrote:
>
>You can look at it this way: Win32lib is in reality an extension to Eu,
>written in Eu. If Win32lib were broken down into easily-digestible modules
>(like Llama was going to be) and completely and totally spec'ed out (don't
>panic David, I don't mean by you! LOL!), when someone wants to add to the
>library, it becomes much easier. Windows only has about 17,000 API calls to
>wrap. In dos, I think you're working more from a blank sheet because you're
>not wrapping .dlls, but the principle is the same for the libraries.
>
In this particular case, I have always wished David had designed the
library to allow others to easily contribute code. But like they
say... "Hindsite is 20/20"! I know he realized this shortcoming, which is
why he started Llama, but... that didn't get very far. A project as
important as a Windows GUI library deserves a lot of attention and
planning, so I suspect your proposal might find some merit with this
project.
Comments, David?
Lee.
5. Re: ISO extensible Eu - Holy Wars need not apply
Lee West wrote:
> In this particular case, I have always wished David
> had designed the library to allow others to easily
> contribute code.
In my mind, this is a namespace issue, plain and simple. I made an attempt
to get around the problem in Llama by designing an OOP system, but the core
of the extensibility issue is namespaces.
I think it's well agreed that we need namespaces for Euphoria. The only
question is, will Robert give us something that will allow single or
multiple inheritance? Your guess is as good as mine. Something as simple as
a variation of "include" that makes the local declarations visible, such as:
inherit win32lib.ew
-- code here can now see local declarations in win32lib
would do nicely. If we go to multiple inheritance, then you need to use
prefixes to tell the compiler which library's routines to use:
inherit win32lib.ew as win32
inherit ftp.e as ftp
-- call the create() routine in ftp, not win32lib
ftp.create( ... )
I'd be plenty happy with single inheritance myself.
-- David Cuny
