APISeam - Revision history

JaroslavTulach: CodeInjection moved to APISeam: Code injection term is already used for hacking - like sending misformated strings to execute special SQL queries. Let's try to use term APISeam.

2011-10-30T07:50:13Z

CodeInjection moved to APISeam: Code injection term is already used for hacking - like sending misformated strings to execute special SQL queries. Let's try to use term APISeam.

←Older revision

Revision as of 07:50, 30 October 2011

85.132.189.103 at 22:00, 22 June 2009

2009-06-22T22:00:55Z

←Older revision		Revision as of 22:00, 22 June 2009
Line 1:		Line 1:
	Do you maintain some [[API]]? Have you ever received a patch from an external contributor which you considered inappropriate? I did, many times. Also I was many times in a position when I wanted to twist some other [[API]] in ways that were not really comfortable for the original [[API]] maintainer.		Do you maintain some [[API]]? Have you ever received a patch from an external contributor which you considered inappropriate? I did, many times. Also I was many times in a position when I wanted to twist some other [[API]] in ways that were not really comfortable for the original [[API]] maintainer.

-	What can be result of such conflict of interests? Rejection of the patch? ~~Possible~~, but that probably upsets the submitter and good [[API]] maintainer does not want to upset those who are willing to contribute patches. Accepting silly patch? Well, that creates a maintenance nightmare. No [[API]] maintainer is wishing to spend time bugfixing, expanding and baby sitting an unwanted code. Looks like ~~loose~~/~~loose~~ situation! Is there a better solution?	+	What can be result of such conflict of interests? Rejection of the patch? Possibly, but that probably upsets the submitter and a good [[API]] maintainer does not want to upset those who are willing to contribute patches. Accepting a silly patch? Well, that creates a maintenance nightmare. No [[API]] maintainer is wishing to spend time bugfixing, expanding and baby sitting an unwanted code. Looks like lose/lose situation! Is there a better solution?

	== Code Injection ==		== Code Injection ==

JaroslavTulach: /* Code Injection */

2009-01-17T20:23:39Z

Code Injection

←Older revision		Revision as of 20:23, 17 January 2009
Line 31:		Line 31:
	''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour.		''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour.

-	For example I want to change [[Felix]] to ~~cooperating~~ with [[NetBeans]] runtime container. Of course I do not want to ~~polute~~ the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in.	+	For example I want to change [[Felix]] to better cooperate with [[NetBeans]] runtime container. Of course I do not want to pollute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in.

	Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. It is still desirable to evaluate the patch with techniques discussed in [[Teamwork\|chapter 16]]. Yet, use of ''code slots'' seems to provide the best balance by turning an unacceptable patch into acceptable slot.		Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. It is still desirable to evaluate the patch with techniques discussed in [[Teamwork\|chapter 16]]. Yet, use of ''code slots'' seems to provide the best balance by turning an unacceptable patch into acceptable slot.

JaroslavTulach: /* Code Injection */

2009-01-17T20:20:27Z

Code Injection

←Older revision		Revision as of 20:20, 17 January 2009
Line 5:		Line 5:
	== Code Injection ==		== Code Injection ==

-	The solution is to create a ''code slot''. Instead of accepting a an unwanted patch, the [[API]] can be extended to execute arbitrary code at given ''patch set'' point. Imagine simple [[API]] for ''counting down'' to zero:	+	The solution is to create a ''code slot''. Instead of accepting an unwanted patch, the [[API]] can be extended to execute arbitrary code at given ''patch set'' point. Imagine simple [[API]] for ''counting down'' to zero:

	<source lang="java" snippet="codeinjection.CountDown"/>		<source lang="java" snippet="codeinjection.CountDown"/>

JaroslavTulach at 06:41, 11 January 2009

2009-01-11T06:41:56Z

←Older revision		Revision as of 06:41, 11 January 2009
Line 25:		Line 25:
	<source lang="java" snippet="codeinjection.v2"/>		<source lang="java" snippet="codeinjection.v2"/>

-	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[Component Injection]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0. If no implementation of the ''slot'' is around, things remain the same as in the first test case. Once some implementation of extender is registered, behaviour changes:	+	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[Component Injection]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0. If no implementation of the ''slot'' is around, things remain the same as in the first test case. Once some implementation of extender (like the '''DecrementByTwo''' class) is registered, behaviour changes:

	<source lang="java" snippet="codeinjection.twice"/>		<source lang="java" snippet="codeinjection.twice"/>

JaroslavTulach at 06:38, 11 January 2009

2009-01-11T06:38:07Z

←Older revision		Revision as of 06:38, 11 January 2009
Line 1:		Line 1:
-	Do you maintain an [[API]] ~~and have~~ you ever received a patch from an external contributor which you considered inappropriate? I did, many times. Also I was many times in a position when I wanted to twist some [[API]] in ways that were not really comfortable for the original [[API]] maintainer.	+	Do you maintain some [[API]]? Have you ever received a patch from an external contributor which you considered inappropriate? I did, many times. Also I was many times in a position when I wanted to twist some other [[API]] in ways that were not really comfortable for the original [[API]] maintainer.

-	What can be result of such ~~clash~~? Rejection of the patch? Possible, but that probably upsets the submitter and good [[API]] maintainer does not want to upset those who are willing to contribute patches. Accepting silly patch? Well, that creates a maintenance nightmare. No [[API]] maintainer is wishing to spend time bugfixing, expanding and baby sitting an unwanted code. Looks like loose/loose situation! Is there a better solution?	+	What can be result of such conflict of interests? Rejection of the patch? Possible, but that probably upsets the submitter and good [[API]] maintainer does not want to upset those who are willing to contribute patches. Accepting silly patch? Well, that creates a maintenance nightmare. No [[API]] maintainer is wishing to spend time bugfixing, expanding and baby sitting an unwanted code. Looks like loose/loose situation! Is there a better solution?

	== Code Injection ==		== Code Injection ==
Line 17:		Line 17:
	<source lang="java" snippet="codeinjection.fourtimes"/>		<source lang="java" snippet="codeinjection.fourtimes"/>

-	But imagine that there is someone who would like to decrement by two. Such person may provide a patch, but ~~maybe it is complicated, maybe it contains code that~~ the ~~[[API]]~~ maintainer ~~does~~ not want to accept. Still, if the maintainer ~~wants to let~~ that submitter ''shot himself into his own foot'', ~~he can open his~~ [[API]] by providing ''code slot'' interface:	+	But imagine that there is someone who would like to decrement by two. Such person may even provide a patch, but the patch needs to complicate things. As such the maintainer may not want to accept it. Still, if the maintainer agrees that under some circumstances, the submitter shall have right to ''shot himself into his own foot'', the [[API]] can be opened up by providing ''code slot'' interface:

	<source lang="java" snippet="codeinjection.slot"/>		<source lang="java" snippet="codeinjection.slot"/>
Line 25:		Line 25:
	<source lang="java" snippet="codeinjection.v2"/>		<source lang="java" snippet="codeinjection.v2"/>

-	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[Component Injection]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0. If no ~~implmentation~~ of the ''slot'' is around, things remain the same as in the first test case~~, but if one registers '''DecrementByTwo'''~~ implementation, behaviour changes:	+	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[Component Injection]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0. If no implementation of the ''slot'' is around, things remain the same as in the first test case. Once some implementation of extender is registered, behaviour changes:

	<source lang="java" snippet="codeinjection.twice"/>		<source lang="java" snippet="codeinjection.twice"/>

-	''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour. For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in. Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. ~~Still, it~~ is the ~~one that provides~~ the best balance by turning an unacceptable patch into acceptable slot.	+	''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour.
		+
		+	For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in.
		+
		+	Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. It is still desirable to evaluate the patch with techniques discussed in [[Teamwork\|chapter 16]]. Yet, use of ''code slots'' seems to provide the best balance by turning an unacceptable patch into acceptable slot.

	<comments/>		<comments/>

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]

JaroslavTulach at 21:38, 10 January 2009

2009-01-10T21:38:58Z

←Older revision		Revision as of 21:38, 10 January 2009
Line 13:		Line 13:
	<source lang="java" snippet="codeinjection.v1"/>		<source lang="java" snippet="codeinjection.v1"/>

-	It is obvious to author of the [[API]] and almost everyone else that '''down()''' means decrement by one. But imagine that there is someone who would like to decrement by two. Such person may provide a patch, but maybe it is complicated, maybe it contains code that the [[API]] maintainer does not want to accept. Still, if the maintainer wants to let that submitter ''shot himself into his own foot'', he can open his [[API]] by providing ''code slot'' interface:	+	It is obvious to author of the [[API]] and almost everyone else that '''down()''' means decrement by one. Just like in this test:
		+
		+	<source lang="java" snippet="codeinjection.fourtimes"/>
		+
		+	But imagine that there is someone who would like to decrement by two. Such person may provide a patch, but maybe it is complicated, maybe it contains code that the [[API]] maintainer does not want to accept. Still, if the maintainer wants to let that submitter ''shot himself into his own foot'', he can open his [[API]] by providing ''code slot'' interface:

	<source lang="java" snippet="codeinjection.slot"/>		<source lang="java" snippet="codeinjection.slot"/>
Line 21:		Line 25:
	<source lang="java" snippet="codeinjection.v2"/>		<source lang="java" snippet="codeinjection.v2"/>

-	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[Component Injection]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0.	+	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[Component Injection]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0. If no implmentation of the ''slot'' is around, things remain the same as in the first test case, but if one registers '''DecrementByTwo''' implementation, behaviour changes:
		+
		+	<source lang="java" snippet="codeinjection.twice"/>

	''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour. For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in. Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. Still, it is the one that provides the best balance by turning an unacceptable patch into acceptable slot.		''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour. For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in. Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. Still, it is the one that provides the best balance by turning an unacceptable patch into acceptable slot.

JaroslavTulach at 21:27, 10 January 2009

2009-01-10T21:27:40Z

←Older revision		Revision as of 21:27, 10 January 2009
Line 25:		Line 25:
	''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour. For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in. Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. Still, it is the one that provides the best balance by turning an unacceptable patch into acceptable slot.		''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour. For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in. Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. Still, it is the one that provides the best balance by turning an unacceptable patch into acceptable slot.

		+	<comments/>

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]

JaroslavTulach at 21:26, 10 January 2009

2009-01-10T21:26:54Z

←Older revision		Revision as of 21:26, 10 January 2009
Line 1:		Line 1:
-	Do you maintain an [[API]] and have you ever received a patch from an external contributor which you considered inappropriate? I did, many times. Also I was many times in a position when I wanted to twist some [[API]] in ways that were not really comfortable for the original maintainer.	+	Do you maintain an [[API]] and have you ever received a patch from an external contributor which you considered inappropriate? I did, many times. Also I was many times in a position when I wanted to twist some [[API]] in ways that were not really comfortable for the original [[API]] maintainer.

	What can be result of such clash? Rejection of the patch? Possible, but that probably upsets the submitter and good [[API]] maintainer does not want to upset those who are willing to contribute patches. Accepting silly patch? Well, that creates a maintenance nightmare. No [[API]] maintainer is wishing to spend time bugfixing, expanding and baby sitting an unwanted code. Looks like loose/loose situation! Is there a better solution?		What can be result of such clash? Rejection of the patch? Possible, but that probably upsets the submitter and good [[API]] maintainer does not want to upset those who are willing to contribute patches. Accepting silly patch? Well, that creates a maintenance nightmare. No [[API]] maintainer is wishing to spend time bugfixing, expanding and baby sitting an unwanted code. Looks like loose/loose situation! Is there a better solution?

JaroslavTulach: /* Code Injection */

2009-01-10T21:21:34Z

Code Injection

←Older revision		Revision as of 21:21, 10 January 2009
Line 21:		Line 21:
	<source lang="java" snippet="codeinjection.v2"/>		<source lang="java" snippet="codeinjection.v2"/>

-	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[~~ComponentInjection~~]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0.	+	This keeps the [[API]] clean of any hacks of subtleties of the foreign code. The [[API]] just defines a ''code slot'' by use of '''ServiceLoader.load''', which is standard [[JDK]] 1.6 interface for doing [[Component Injection]]. Either it is present (someone included additional [[JAR]] on classpath with registration of implementation of the interface), and in such way the decrement is completely handled by new code, or it is missing and then the behaviour remains the same as in version 1.0.

	''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour. For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in. Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. Still, it is the one that provides the best balance by turning an unacceptable patch into acceptable slot.		''Code slots'' provide a nice balance between the need to extend an [[API]] with additional functionality and the fear of maintaining such code. Every [[API]] can be extended to provide ''code slots'' and I see them as a perfect way of providing patches for ''unwanted'' behaviour. For example I want to change [[Felix]] to cooperating with [[NetBeans]] runtime container. Of course I do not want to polute the original [[Felix]] code with anything [[NetBeans]] specific, but maybe all I need is just a single ''code slot'' to hook in. Of course, the [[API]] maintainer needs to be ready to support such ''slot'' and accept any, even surprising behaviour inside it, so the solution is not completely for free. Still, it is the one that provides the best balance by turning an unacceptable patch into acceptable slot.