On Tuesday 27 April 2004 20:19, Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote: > -----Mensagem original----- > De: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > > In fact, my type of systems, should actually not even use the "method > > call" > > > principle that we are so used to. "There is no return, so why fill up a > > stack", and stacktraces in these types of systems becomes 'awful', to say > > the > > > least. > > So you use what? Messages? Interesting.
What I use is different from "should use" :o) I have been using (since ~97/98) JavaBeans Event pattern for generating the "Signal" path, with my framework wiring the 'receiver' directly to the 'sender'. I want to change that whole thing, and started out a whole year ago to port it all to Avalon, first Phoenix and now Merlin, going very slowly :'( The exchange of the Events for 'direct calls' came to me recently, while looking into the details of a possible "wire subsystem". The similarity wasn't apparent to me. Finally, I have been 'fantasizing' of a whole new Programming Paradigm, as big shift as Object-Oriented or Aspect-Oriented was when it came. I asked myself, What is a ReturnType? (except for the obvious answer and the legacy from function calls and subroutines). My 'vivid abstraction' concluded that the ReturnType is a single argument input to a predefined destination (where the call was made from). So, what if "Methods" didn't exist, and that the "Continuum" or destination could either be passed in or request from the 'container', instead of requiring that it had to return to the same spot with a single argument. I decided that this is WAY OUT of what is feasible to persue.... :o) but it would solve my types of systems very well, and perhaps others too. Cheers Niclas -- +---------//-------------------+ | http://www.bali.ac | | http://niclas.hedhman.org | +------//----------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
