[e-lang] Embed E in Java

[Kevin Reid]

On Jan 12, 2010, at 17:08, Mark Miller wrote:
> On Tue, Jan 12, 2010 at 1:42 PM, Kevin Reid <kpreid at mac.com> wrote:
>> On Oct 21, 2009, at 13:25, Mark Miller wrote:
>>> On Tue, Oct 20, 2009 at 9:17 AM, Kevin Reid <kpreid at mac.com> wrote:
>>>> MarkM: Is there a non-historical reason NestedException/
>>>> NestedThrowable/etc exist instead of using the Java 1.4
>>>> Throwable.getCause() mechanism?
>>>
>>> Mostly history. The NestedException,.. mechanism predates Java 1.4.
>>> Since it worked, I have never examined the new getCause() API. I do
>>> not know whether or not it would be safe to use instead.
>>
>> I believe I understand it sufficiently well to say that it is safe  
>> and
>> appropriate to use instead. I propose to change E-on-Java to replace
>> the Nested* mechanisms (backwards compatibly, i.e. the .leaf() sugar
>> and so on will still exist) with causes.
>>
>> * What is the minimum Java version E-on-Java is intended to require?
>>
>>
> 1.4. Yes, I realize that contradicts my paragraph quoted above. I  
> have no
> objections to moving E-on-Java's dependencies forward to 1.5. Does  
> anyone
> else see any reasons to stay with 1.4 for now?

Hold on. Where did 1.5 come in, and what do you mean by "moving E-on- 
Java's dependencies"? I'm only proposing to use 1.4 features, not 1.5.

I don't see any contradiction in what you have said so far.

> Btw, one big potential benefit of moving towards 1.5 is that we  
> could start
> making parts of E-on-Java be Joe-E safe. Ultimately, except for a  
> small
> powerbox, it might be good for E-on-Java to become E-on-Joe-E.
> Unfortunately, for this to happen, we'd need to start to use Java's  
> generics
> (parameterized typed) within the E implementation, at an enormous  
> cost in
> readability and reviewability. I do not yet understand how practical  
> it is
> to use Joe-E while avoiding generics.

Why do you consider the generics an enormous cost? Additional  
verbosity, or erasure-related issues, or what?

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>