Difference between revisions of "Talk:EiffelBase2"

m (Added a note to extend functionality of iterators.)
m (Improved wording of iteration-related question.)
Line 3: Line 3:
  
 
'''[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 14:01, 5 April 2012 (UTC):'''
 
'''[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 14:01, 5 April 2012 (UTC):'''
An iterator is usually seen as a passive handle that can be operated by some other code to access elements in turn. On the other hand it's natural to provide <e>do_all</e> and similar iteration features when the code to process elements is wrapped in agents. Yet it might be reasonable to have an abstraction that has an iterative behaviour by itself. It would define a feature <e>forth</e> to do some work and the loop that performs the iteration would be provided by the higher-level iterator-like class. Are there any provisions for such applications?
+
An iterator is usually seen as a passive handle that can be operated by some other code to access elements in turn. On the other hand it can naturally provide <e>do_all</e> and similar iteration features. Such features are quite similar to the previous case, but the loop structure is reused and the code to process elements is wrapped in agents. The third variation covers the case when no external handling is required. Everything is performed by the redefined feature <e>forth</e>. In this case the iterator becomes an active rather than a passive object, because it exhibits some meaningful behaviour itself, without any additional code. In both the second and the third cases the associated loop can be abstrated by some higher-level iterator-like class. Are there any provisions for such abstractions in the proposed structure?

Revision as of 11:01, 5 April 2012

Alexander Kogtenkov 17:51, 23 April 2010 (UTC): Changing indexable structures to use 1 everywhere for lower index looks like a good idea. The summary mentions the corresponding modification to the class ARRAY. There is one more class that does not fit "start at 1" rule: SPECIAL. Is it planned to change it to start at 1 as well?

Alexander Kogtenkov 14:01, 5 April 2012 (UTC): An iterator is usually seen as a passive handle that can be operated by some other code to access elements in turn. On the other hand it can naturally provide do_all and similar iteration features. Such features are quite similar to the previous case, but the loop structure is reused and the code to process elements is wrapped in agents. The third variation covers the case when no external handling is required. Everything is performed by the redefined feature forth. In this case the iterator becomes an active rather than a passive object, because it exhibits some meaningful behaviour itself, without any additional code. In both the second and the third cases the associated loop can be abstrated by some higher-level iterator-like class. Are there any provisions for such abstractions in the proposed structure?