Talk:Void-safe migration guide - Revision history

Ericb at 07:38, 4 August 2009

2009-08-04T07:38:37Z

← Older revision		Revision as of 07:38, 4 August 2009
Line 1:		Line 1:
	''--[[User:Ericb\|Ericb]] 14:34, 2 August 2009 (UTC)''': The problem about not having `default_create' as creation procedure in CELL anymore, even when the actual generic parameter is detachable, is not just an expandedness issue. What do we do with code like that:		'''--[[User:Ericb\|Ericb]] 14:34, 2 August 2009 (UTC)''': The problem about not having `default_create' as creation procedure in CELL anymore, even when the actual generic parameter is detachable, is not just an expandedness issue. What do we do with code like that:
	<eiffel>		<eiffel>
	class A [G -> ANY create default_create end]		class A [G -> ANY create default_create end]
Line 10:		Line 10:
	:'''--[[User:Manus\|manus]] 18:27, 3 August 2009 (UTC)''': Of course here you have not much choice and you either have to rewrite `A' and/or define a new CELL class that has ''default_create'' as a creation procedure. The real question is how much of this code actually exists and the impact of rewriting the code that depended on that. Another solution is to modify `default_create' in ANY to have a precondition re-definable by descendants so to leave your code unchanged, in this case `CELL' would say it is ok to use ''default_create'' but only when the actual generic parameter is detachable.		:'''--[[User:Manus\|manus]] 18:27, 3 August 2009 (UTC)''': Of course here you have not much choice and you either have to rewrite `A' and/or define a new CELL class that has ''default_create'' as a creation procedure. The real question is how much of this code actually exists and the impact of rewriting the code that depended on that. Another solution is to modify `default_create' in ANY to have a precondition re-definable by descendants so to leave your code unchanged, in this case `CELL' would say it is ok to use ''default_create'' but only when the actual generic parameter is detachable.

	::--[[User:Ericb\|Ericb]] 07:37, 4 August 2009 (UTC): You have to keep in mind that ECMA says that the precondition of creation procedures should not have unqualified calls. Also, for the issue with CELL, I think that I was the one who used this example (which occurs in existing code) to try to bring the attention that void-safety goes against reusability. From there, void-safety proponents tried to show that there was actually no problem, but most of them didn't address the reusability issue. That's why I put this note here, to remind people what the real problem is with the CELL example.		::'''--[[User:Ericb\|Ericb]] 07:37, 4 August 2009 (UTC)''': You have to keep in mind that ECMA says that the precondition of creation procedures should not have unqualified calls. Also, for the issue with CELL, I think that I was the one who used this example (which occurs in existing code) to try to bring the attention that void-safety goes against reusability. From there, void-safety proponents tried to show that there was actually no problem, but most of them didn't address the reusability issue. That's why I put this note here, to remind people what the real problem is with the CELL example.

Ericb at 07:37, 4 August 2009

2009-08-04T07:37:49Z

← Older revision		Revision as of 07:37, 4 August 2009
Line 9:		Line 9:

	:'''--[[User:Manus\|manus]] 18:27, 3 August 2009 (UTC)''': Of course here you have not much choice and you either have to rewrite `A' and/or define a new CELL class that has ''default_create'' as a creation procedure. The real question is how much of this code actually exists and the impact of rewriting the code that depended on that. Another solution is to modify `default_create' in ANY to have a precondition re-definable by descendants so to leave your code unchanged, in this case `CELL' would say it is ok to use ''default_create'' but only when the actual generic parameter is detachable.		:'''--[[User:Manus\|manus]] 18:27, 3 August 2009 (UTC)''': Of course here you have not much choice and you either have to rewrite `A' and/or define a new CELL class that has ''default_create'' as a creation procedure. The real question is how much of this code actually exists and the impact of rewriting the code that depended on that. Another solution is to modify `default_create' in ANY to have a precondition re-definable by descendants so to leave your code unchanged, in this case `CELL' would say it is ok to use ''default_create'' but only when the actual generic parameter is detachable.

			::--[[User:Ericb\|Ericb]] 07:37, 4 August 2009 (UTC): You have to keep in mind that ECMA says that the precondition of creation procedures should not have unqualified calls. Also, for the issue with CELL, I think that I was the one who used this example (which occurs in existing code) to try to bring the attention that void-safety goes against reusability. From there, void-safety proponents tried to show that there was actually no problem, but most of them didn't address the reusability issue. That's why I put this note here, to remind people what the real problem is with the CELL example.

Manus at 18:27, 3 August 2009

2009-08-03T18:27:36Z

← Older revision		Revision as of 18:27, 3 August 2009
Line 1:		Line 1:
	--[[User:Ericb\|Ericb]] 14:34, 2 August 2009 (UTC): The problem about not having `default_create' as creation procedure in CELL anymore, even when the actual generic parameter is detachable, is not just an expandedness issue. What do we do with code like that:		''--[[User:Ericb\|Ericb]] 14:34, 2 August 2009 (UTC)''': The problem about not having `default_create' as creation procedure in CELL anymore, even when the actual generic parameter is detachable, is not just an expandedness issue. What do we do with code like that:
	<eiffel>		<eiffel>
	class A [G -> ANY create default_create end]		class A [G -> ANY create default_create end]
Line 7:		Line 7:
	a: A [CELL [detachable FOO]]		a: A [CELL [detachable FOO]]
	</eiffel>		</eiffel>

			:'''--[[User:Manus\|manus]] 18:27, 3 August 2009 (UTC)''': Of course here you have not much choice and you either have to rewrite `A' and/or define a new CELL class that has ''default_create'' as a creation procedure. The real question is how much of this code actually exists and the impact of rewriting the code that depended on that. Another solution is to modify `default_create' in ANY to have a precondition re-definable by descendants so to leave your code unchanged, in this case `CELL' would say it is ok to use ''default_create'' but only when the actual generic parameter is detachable.

Ericb: New page: --~~~~: The problem about not having `default_create' as creation procedure in CELL anymore, even when the actual generic parameter is detachable, is not just an expandedness issue. What d...

2009-08-02T14:34:42Z

New page: --~~~~: The problem about not having `default_create' as creation procedure in CELL anymore, even when the actual generic parameter is detachable, is not just an expandedness issue. What d...

New page

--[[User:Ericb|Ericb]] 14:34, 2 August 2009 (UTC): The problem about not having `default_create' as creation procedure in CELL anymore, even when the actual generic parameter is detachable, is not just an expandedness issue. What do we do with code like that:
<eiffel>
class A [G -> ANY create default_create end]
...
end

a: A [CELL [detachable FOO]]
</eiffel>