Talk:EiffelBase2 - Revision history

Manus: /* {PREDICATE}.precondition */

2012-10-21T22:05:03Z

{PREDICATE}.precondition

← Older revision		Revision as of 22:05, 21 October 2012
Line 13:		Line 13:
	--[[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: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.		--[[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.

Manus: /* {PREDICATE}.precondition */

2012-10-21T22:04:56Z

{PREDICATE}.precondition

← Older revision		Revision as of 22:04, 21 October 2012
Line 12:		Line 12:

	--[[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: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.

Colin-adams: /* {PREDICATE}.precondition */ new section

2012-10-20T11:13:14Z

{PREDICATE}.precondition: new section

← Older revision		Revision as of 11:13, 20 October 2012
Line 8:		Line 8:

	--[[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.		--[[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?

Colin-adams: /* Style guidelines for creation procedure names */ new section

2012-04-12T11:09:22Z

Style guidelines for creation procedure names: new section

← Older revision		Revision as of 11:09, 12 April 2012
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.

Alexander Kogtenkov: Improved wording of iteration-related question.

2012-04-05T19:02:34Z

Improved wording of iteration-related question.

← Older revision		Revision as of 19:02, 5 April 2012
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 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~~?		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?

Alexander Kogtenkov: Improved wording of iteration-related question.

2012-04-05T19:01:57Z

Improved wording of iteration-related question.

← Older revision		Revision as of 19:01, 5 April 2012
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?

Alexander Kogtenkov: Added a note to extend functionality of iterators.

2012-04-05T14:01:26Z

Added a note to extend functionality of iterators.

← Older revision		Revision as of 14:01, 5 April 2012
Line 1:		Line 1:
	'''[[User:Alexander Kogtenkov\|Alexander Kogtenkov]] 17:51, 23 April 2010 (UTC):'''		'''[[User:Alexander Kogtenkov\|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 <e>ARRAY</e>. There is one more class that does not fit "start at 1" rule: <e>SPECIAL</e>. Is it planned to change it to start at 1 as well?		Changing indexable structures to use 1 everywhere for lower index looks like a good idea. The summary mentions the corresponding modification to the class <e>ARRAY</e>. There is one more class that does not fit "start at 1" rule: <e>SPECIAL</e>. Is it planned to change it to start at 1 as well?

			'''[[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?

Alexander Kogtenkov: Added a question about index of the first item in SPECIAL

2010-04-23T17:51:58Z

Added a question about index of the first item in SPECIAL

New page

'''[[User:Alexander Kogtenkov|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 <e>ARRAY</e>. There is one more class that does not fit "start at 1" rule: <e>SPECIAL</e>. Is it planned to change it to start at 1 as well?