| Newsgroups |
gmane.comp.lang.e.general |
| Message-ID |
<[email protected]> |
On Sun, Oct 11, 2009 at 7:50 PM, Kevin Reid <[email protected]> wrote:
> On Oct 11, 2009, at 21:40, [email protected] wrote:
>
>> a. Remove the dependency on E-on-Java and E-on-JS, resulting in a pure
>> Cajita project. ...
>
> It is a design goal of Caja-CapTP to eventually interoperate with
> other CapTP implementations, of course including the 'normal' E-based
> implementations.
Cool.
> I wish that the test suite in Caja-CapTP continue to parallel as
> closely as possible the test suite for CapTP-in-E (which currently
> exists as a component of E-on-CL), from which it was derived, so that
> improvements to tests (which are greatly needed on both sides) may be
> shared.
+1, with some questions below.
> I will not support any changes which will remove opportunities to
> avoid duplicated effort in the future. We are in general desperately
> short of available time from interested programmers.
That's a good point.
> 1. Why do you wish to remove these dependencies?
The main reason behind all these is to make Caja-CapTP easy to
integrate into Cajita projects. This was intended as a contribution to
further developing Caja-CapTP rather than a change of direction.
First of all, I'm really glad that you undertook this GSOC project and
I for one believe it will enable a huge amount of coolness. Thank you.
Speaking for myself, I am not ready to hack the core implementation or
the semantics of the tests. That said, my first step when trying to
learn a library is to look at the tests and use them as a set of
"worked examples" for how to use the library. In this case, the
"worked examples" were not in the language and runtime environment
that I was going to use for my finished product. So I took it upon
myself to rewrite the tests in terms of that environment, and so
hopefully to learn the library some more in the process.
I understand the need to have non-duplication of the tests. Perhaps
what we need may be comprehensive tests in E, and some "spot tests" /
"worked examples" in Cajita. I honestly don't know what the right
answer is at this point.
> 1a. If because E-on-Java is awkward to install, would the existence
> of a simple installer for Unix-style operating systems, and
> perhaps other changes to make things more pleasant, resolve
> this?
Perhaps.
> 2. Would removing E-on-JavaScript's dependency on E-on-Java, such that
> it was a pure-JS or possibly even pure-Cajita (maybe with some Java)
> system, suffice? (The necessary work here would be providing a
> parser for E written in JavaScript, perhaps by way of OMeta.)
Perhaps, though I am loath to impose extra work on you or anyone. :)
> 3. Would revising the test suite such that, while still using the Updoc
> syntax for tests, the test code itself is Cajita, suffice?
Perhaps. That would require an Updoc-Cajita, which is why I suggested
Mike Samuel's JSDoc as a possible tool.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA