[saga-rg] Task model...

[Andre Merzky]

Hi Pascal, 

there have been more models in discussion in Boston, true
enough.  However, I can't really figure out what model you
refer to.  Some example code would be helpful :-)

Cheers, Andre.


Quoting [pascal.kleijer at knd.biglobe.ne.jp] (Nov 03 2005):
> 
> Hello all,
> 
> Lets enter the arena if it is not too late, sorry for that.
> I do agree with many things that have been discussed here.
> Being myself a POP (pattern oriented programming) and OOP
> (Object Oriented programming) guy I tend to favor nicely
> encapsulated models.
> 
> As mentioned by Tom, the template is possible in Java as
> well. But that forces the usage of Java 5.0 (aka 1.5) at
> least. This isn't recommended since many programs
> still run with 1.4. Using them would probably create a very
> different binding in Java, C++ or Python, which would end up
> in 2 different SAGA implementations/usage, one for OO
> languages and one for old fashioned procedurals. 
> 
> As to exposing the different implementation to the user I
> think this could be avoided in OO languages, or at least it
> should not be as obvious as in 4a2. During the GGF meeting
> their was a last minute discussion about a `g' solution
> which is pretty much pure OO design with a simple method
> call whatever model is used.  This is I think a good choice
> for an OO point of view. You can derivate an abstract class
> to specialized classes with synchronous or asynchronous
> implementation. This would even open the room for sub
> classing it to add custom code for debugging for example or
> other treatment without affecting the initial code.
> Depending on how the programming is tackled factories aren't
> necessary. The problem might come when implementation is
> made in procedural languages, it might be necessary to add
> additional parameters to the constructor or the calls.
> 
> I don't have the time this morning to make a sample
> code. But I hope you got the idea.
> 
> Best Regards,
> Pascal Kleijer
> 
> > 
> > My vote is for 4a1. (Which was option D in our original discussion I 
> > believe.)
> > 
> > Cheers,
> > 
> > Tom
> > 
> > On Thu, 3 Nov 2005, Andre Merzky wrote:
> > 
> > >
> > > Hi John, Thilo, Group,
> > >
> > > Hartmut and I would like to argue about the C++ bindings.
> > > We would like to come to an agreement soon, as our
> > > implementation is dealing with the async part right now.
> > >
> > > As reminder:
> > >
> > > ---------------------------------------------------------------------
> > > Example 4a: more versions in C++
> > >
> > > 4a1:               d.mkdir         ("test/");
> > >                   d.mkdir_sync    ("test/"); // same
> > >  saga::task t_1 = d.mkdir_async   ("test/");
> > >  saga::task t_2 = d.mkdir_task    ("test/");
> > >
> > > 4a2:               d.mkdir         ("test/");
> > >                   d.sync .mkdir   ("test/"); // same
> > >  saga::task t_1 = d.async.mkdir   ("test/");
> > >  saga::task t_2 = d.task .mkdir   ("test/");
> > >
> > > 4a3:               d.mkdir         ("test/");
> > >                   d.mkdir <sync>  ("test/"); // same
> > >  saga::task t_1 = d.mkdir <async> ("test/");
> > >  saga::task t_2 = d.mkdir <task>  ("test/");
> > >  ---------------------------------------------------------------------
> > >
> > >
> > > Quoting [John Shalf] (Nov 02 2005):
> > >>
> > >>>   Q5) Any comments to 4a1, 4a2 or 4a3? (not part of the Strawman!)
> > >>
> > >> I prefer 4a1 because it is more readable and the implementation would
> > >> be quite straightforward.
> > >
> > > You favour 4a1.  We think that implementation is very straight
> > > forward for all three versions.  Readability seems not much
> > > different to me, and might largely be a matter of taste.
> > >
> > >
> > >> It is also a familiar paradigm for any MPI
> > >> programmers and anyone who has played with various proprietary Async
> > >> I/O implementations. (its a very familiar and conventional approach)
> > >
> > > Well, these are C-API's.  Is there a C++ binding for MPI,
> > > and does it look the same?
> > >
> > >
> > >> I kind of like 4a2 as well from the standpoint of a C++ programmer
> > >> (even with Andre's syntax corrections).  However, the resulting
> > >> bindings will not be very consistent with the approach we would take
> > >> for Fortran or C bindings (eg. those would likely look more like
> > >> 4a1).
> > >
> > > But, well, that is the idea of the language binding!  I agree
> > > that C and Fortran would look more like 4a1, of course.  But that
> > > is no reason that C++ should look like that as well, or Java,
> > > Perl etc.
> > >
> > >
> > >> It is not really much more readable than 4a1.  Therefore, I'm
> > >> uncertain if it is worth fragmenting our approach to bindings in
> > >> different languages when there is not a clear benefit in terms of
> > >> readability or implementation complexity.
> > >
> > > I think that 4a2/4a3 actually allow nicer implementations, as it
> > > allows to have the different async parts somewhat separate from
> > > the sync parts.  We think its nicer :-)
> > >
> > >
> > >> I do a lot of C++ programming, but I find the 4a3 option a bit
> > >> obscure both in terms of readability and any advantages it might
> > >> confer in terms of implementation.
> > >
> > > Hehe - I thought the same :-)  Hartmut likes that version very
> > > much.  To me it appealed after pondering over it for a couple of
> > > days.  Now I think it is cute, and quite expressive.
> > >
> > >
> > >> It would certainly be easier to
> > >> create multi-language bindings for a single code base if we stick
> > >> with something more conventional like 4a1.
> > >
> > > I think that C and Fortran bindings for this part are straight
> > > forward anyway, there is no need to reflect that in C++...
> > >
> > >
> > >> Each approach is equally readable to me (less so for 4a3).  I'm
> > >> certainly open to any additional information on how the 4a2 and 4a3
> > >> approaches could simplify implementation.
> > >
> > > The main point really is that the object itself has only the sync
> > > method calls, and the async calls can be put into separate
> > > header/sources easily, and build (by default) on top of the sync
> > > calls.  Of course, you can do that with all three versions, but
> > > its not as obvious in 4a1.
> > >
> > >
> > >> If the other approaches
> > >> can offer some implementation benefits, then maybe I'd give them
> > >> extra consideration, but otherwise, I would prefer a more
> > >> conventional approach like 4a1.
> > >
> > > I would  vote for 4a2 or 4a3 (in that order), but 4a1 would be ok
> > > if the majority likes that most, of course.  Basically its
> > > a matter of taste I think.  I am happy that the general point
> > > seems accaptable to all so far: having sync, async, and task
> > > versions of the calls, w/o explicit task factory.
> > >
> > >> The only implementation I'm outright
> > >> against is the 4b example.
> > >
> > > Good! :-)
> > >
> > > Thanks, Andre.
> > >
> > >
> > >> -john
> > >
> > >
> > >
> > >
> > 
> > 



-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+