Difference between revisions of "Talk:EiffelBase2"
m (Improved wording of iteration-related question.) |
(→{PREDICATE}.precondition) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
'''[[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 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 class hierarchy? | 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 class hierarchy? | ||
| + | |||
| + | == Style guidelines for creation procedure names == | ||
| + | |||
| + | --[[User:Colin-adams|Colin-adams]] 11:09, 12 April 2012 (UTC) with_object_equality doesn't sound like the name of a command, as recommended in the OOSC2 style guidelines. Make_with_object_equality is what I would expect to see. | ||
| + | |||
| + | == {PREDICATE}.precondition == | ||
| + | |||
| + | --[[User:Colin-adams|Colin-adams]] 11:13, 20 October 2012 (UTC) Features such as {V_CONTAINER}.for_all have preconditions which make use of {PREDICATE}.precondition. In ES 7.1 this is still implemented as always True. Are there plans for a more accurate implementation? | ||
| + | |||
| + | --[[User:Manus|manus]] 22:04, 21 October 2012 (UTC) As of today there is no immediate plan to add this but this is certainly something we wish to eventually do. The main issue is achieving this without making the executable bigger or slowing it down. | ||
Latest revision as of 14:05, 21 October 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 class hierarchy?
Style guidelines for creation procedure names
--Colin-adams 11:09, 12 April 2012 (UTC) with_object_equality doesn't sound like the name of a command, as recommended in the OOSC2 style guidelines. Make_with_object_equality is what I would expect to see.
{PREDICATE}.precondition
--Colin-adams 11:13, 20 October 2012 (UTC) Features such as {V_CONTAINER}.for_all have preconditions which make use of {PREDICATE}.precondition. In ES 7.1 this is still implemented as always True. Are there plans for a more accurate implementation?
--manus 22:04, 21 October 2012 (UTC) As of today there is no immediate plan to add this but this is certainly something we wish to eventually do. The main issue is achieving this without making the executable bigger or slowing it down.
