[e-lang] [ANN] AsyncObjects 0.1.0 (alpha)

[Mark S. Miller]

Constantine Plotnikov wrote:
> I have release an updated version of the AsyncObjects framework.
> 
> Information about the framework is available at
> http://asyncobjects.sourceforge.net/ . The page has links to javadoc
> and developer's guide.
> 
> The biggest change is that the framework now features the minimal
> documentation. There is more detailed javadoc and there is a new
> developer's guide document.
> 
> This release can be interesting for Joe-E as it tries to solve almost
> the same task in almost the same environment. 

Hi Constantine,

This is exciting. I've just read the first 10 pages of your user's guide and 
skimmed the rest. Are the following first impressions sensible?

The biggest differences between AsyncObjects and ref_send are:

* ref_send builds on Joe-E, not Java, and so starts with a sequential 
object-capability language. ref_send itself conforms to and supports 
capability discipline including support for writing defensively consistent 
abstractions.

* AsyncObjects builds on and potentially assumes the full Java SE language, 
though it started within a particular "foundation profile". AsyncObjects is 
not intended to support mutual suspicion among objects in the same address 
space. AsyncObjects assumes the programmer has some familiarity with Java 
threading concepts, and provides much flexibility in how they may be mixed. It 
is up to the programmer to avoid mixing threads and event loops in unsafe ways.

* ref_send, though neither distributed nor persistent, is designed to support 
distribution and persistence (as demonstrated by the Waterken server) with 
only minimal additional restrictions imposed on the ref_send programmer. I 
couldn't tell whether this was also one of the hidden goals of AsyncObjects.

* With AsyncObjects, you've done the hard work of understanding and wrapping 
the Java NIO library, in order to provide efficient asynchronous IO to your 
event-loop programming library.


In many other ways, as you say, these systems are similar. For ref_send, the 
safety issues cannot be compromised. If our safety requirements are not 
incompatible with your goals, perhaps we can find a way to merge efforts?


 > From what I have seen ,
> AsyncObjects are somewhat close to E syntax than ref_send.

The only thing I was able to spot was the when syntax. Did you have something 
else in mind?



> Due to
> historic reasons the framework is compatible with JDK 1.4.x except for
> some samples, so generics were not used. A next version will likely
> support generics.

E-on-Java is also in 1.4. Joe-E/ref_send/Horton is my first experience with 
Java 1.5 and generics. I must say I have mixed feelings about Java generics. 
Even after months of occasional hacking, I find I still cannot predict whether 
a code fragment I'm about to write will pass the Java 1.5 static type checker. 
When it doesn't, I often don't really understand why not. Instead, I find I 
fiddle with it until it does. This is partly a failure of discipline on my 
part, but...

In any case, this is a source of complexity that everyone in the Java world 
will get used to, so I agree that we should to.


> This framework can be also interesting to E as it implements All, Seq,
> Any, and Using syntax extensions that I have proposed earlier as
> utility classes. See developer's guide and samples for it.

Could these all be expressed similarly in ref_send as well? (I suspect so.)


> The framework has a functional NIO wrapper. See the samples directory
> where there are some trivial internet services implemented using it.
> The directory scripts contain windows cmd scripts that launches them.

Yes, wrapping NIO is interesting. It would be quite cool if we could find a 
way to use your NIO wrapping safely from within a Joe-E/ref_send program.


-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM