AssemblableTypes - Revision history

JaroslavTulach at 20:14, 25 May 2011

2011-05-25T20:14:32Z

←Older revision		Revision as of 20:14, 25 May 2011
Line 49:		Line 49:


-	[[Category:APIDesignPatterns]] [[APIDesignPatterns:Evolution]] [[Category:APIDesignPatterns:Meta]]	+	[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Evolution]] [[Category:APIDesignPatterns:Meta]]

JaroslavTulach at 17:09, 14 May 2011

2011-05-14T17:09:51Z

←Older revision		Revision as of 17:09, 14 May 2011
Line 47:		Line 47:

	Here we are getting to the concept of [[AssemblableTypes]]. Not only we disassemble the parameters of some method, but we make sure, that there exist important types in the system that implement all these [[AssemblableTypes]]. If we have such types we can marry the modularity with ease of use. Type parameters stay modular, yet there are implementations that naturaly fullfil them all.		Here we are getting to the concept of [[AssemblableTypes]]. Not only we disassemble the parameters of some method, but we make sure, that there exist important types in the system that implement all these [[AssemblableTypes]]. If we have such types we can marry the modularity with ease of use. Type parameters stay modular, yet there are implementations that naturaly fullfil them all.
		+
		+
		+	[[Category:APIDesignPatterns]] [[APIDesignPatterns:Evolution]] [[Category:APIDesignPatterns:Meta]]

JaroslavTulach at 16:55, 14 May 2011

2011-05-14T16:55:27Z

←Older revision		Revision as of 16:55, 14 May 2011
Line 1:		Line 1:
-	By splitting [[API]]s into multiple [[module]]s one increases ~~their~~ flexibility. The [[API]] become independent and can be used in new contexts, without the rest of the [[API]]s ~~being present~~. However one also complicates the usage, as for some, original (in case the [[API]] used to be present as a whole) [[usecase]]s, the users need to try harder to make the [[API]]s work together. That is indeed not [[good]] (as it increases [[Time To Market]]). This article describes one of my advantures where I had to deal with similar situation.	+	By splitting [[API]]s into multiple [[module]]s one increases flexibility of their reuse. The [[API]]s become more independent and can be used in new contexts, without the rest of the [[API]]s dragged around. However one also complicates the usage, as for some, original (in case the [[API]] used to be present as a whole) [[usecase]]s, the users need to try harder to make the [[API]]s work together. That is indeed not [[good]] (as it increases [[Time To Market]]). This article describes one of my advantures where I had to deal with similar situation.

	== Setup ==		== Setup ==
Line 16:		Line 16:
	== History ==		== History ==

-	The common style to achieve this is to create a new, [[AbstractedTypes]] and put them into new module that both ''text'' and ''loaders'' [[API]] ~~will~~ depend on. This ~~works~~ fine, but requires creation of whole new [[API]] module. In my case that was not really appropriate. Any other option?	+	The common style to achieve this is to create a new, [[AbstractedTypes]] and put them into new module that both ''text'' and ''loaders'' [[API]] would depend on. This is fine approach, but requires creation of whole new [[API]] module. In my case that was not really appropriate. Any other option?

	== Improvements ==		== Improvements ==
Line 26:		Line 26:
	</source>		</source>

-	This is gettting closer to the style of functional programming as pioneered by [[Haskell]] (or [[Clean]]). Define a lot of abstract ''categories'' (in their terminology ''classes'', but don't confuse that with [[OOP]] classes) and then use these categories to ~~define~~ appropriate type for each function/method.	+	This is gettting closer to the style of functional programming as pioneered by [[Haskell]] (or [[Clean]]). Define a lot of abstract ''categories'' (in their terminology ''classes'', but don't confuse that with [[OOP]] classes) and then use these categories to assemble appropriate type for each function/method.

-	In case one can find ~~good enough~~ types in the ~~base~~, this kind of ''on the fly'' creation of types is usually more flexible.	+	In case one can find suitable types in the common dependencies (like in [[JDK]]), this kind of ''on the fly'' creation of types is usually more flexible.

	== Result ==		== Result ==
Line 46:		Line 46:
	Not only {{NB\|org-openide-util-lookup\|org/openide/util\|Lookup.Provider}} is simpler interface with a single method (and thus easier to honor the contract and make it serializable), but if you look at type definition of {{NB\|org-openide-loaders\|org/openide/loaders\|DataObject}}, you'll notice that it already implements both - the {{NB\|org-openide-util-lookup\|org/openide/util\|Lookup.Provider}} as well as {{JDK\|java/io\|Serializable}}!		Not only {{NB\|org-openide-util-lookup\|org/openide/util\|Lookup.Provider}} is simpler interface with a single method (and thus easier to honor the contract and make it serializable), but if you look at type definition of {{NB\|org-openide-loaders\|org/openide/loaders\|DataObject}}, you'll notice that it already implements both - the {{NB\|org-openide-util-lookup\|org/openide/util\|Lookup.Provider}} as well as {{JDK\|java/io\|Serializable}}!

-	Here we are getting to the concept of [[AssemblableTypes]]. Not only we disassemble the parameters of some method, but we make sure, that there exist important types in the system that implement all these [[~~abstractedtypes~~]]. If we have such types we can marry the modularity with ease of use. Type parameters stay modular, yet there are implementations that naturaly fullfil them.	+	Here we are getting to the concept of [[AssemblableTypes]]. Not only we disassemble the parameters of some method, but we make sure, that there exist important types in the system that implement all these [[AssemblableTypes]]. If we have such types we can marry the modularity with ease of use. Type parameters stay modular, yet there are implementations that naturaly fullfil them all.

JaroslavTulach at 19:48, 8 May 2011

2011-05-08T19:48:13Z

←Older revision		Revision as of 19:48, 8 May 2011
Line 32:		Line 32:
	== Result ==		== Result ==

-	[[~~TBD~~]]	+	Thus I tried to use similar approach in the new version of the ''multiview'' [[API]]. Sure, I knew the most common use is to pass in ''DataObject'' (but I could not). Then I realized that the only two capabilities I need from such ''DataObject'' are ability to query for additional interface (e.g. [[Lookup]]) and being {{JDK\|java/io\|Serializable}}. For a while I was considering to use:
		+
		+	<source lang="java">
		+	<T extends Lookup & Serializable> Component createMultiView(String mimeType, T context);
		+	</source>
		+
		+	This would require people to create their own subclasse of [[Lookup]] and make sure they know how to persist it (at least as a reference) and recover its state during serialization. Not impossible, but a bit complicated. Then I got another idea:
		+
		+	<source lang="java">
		+	<T extends Lookup.Provider & Serializable> Component createMultiView(String mimeType, T context);
		+	</source>
		+
		+	Not only {{NB\|org-openide-util-lookup\|org/openide/util\|Lookup.Provider}} is simpler interface with a single method (and thus easier to honor the contract and make it serializable), but if you look at type definition of {{NB\|org-openide-loaders\|org/openide/loaders\|DataObject}}, you'll notice that it already implements both - the {{NB\|org-openide-util-lookup\|org/openide/util\|Lookup.Provider}} as well as {{JDK\|java/io\|Serializable}}!
		+
		+	Here we are getting to the concept of [[AssemblableTypes]]. Not only we disassemble the parameters of some method, but we make sure, that there exist important types in the system that implement all these [[abstractedtypes]]. If we have such types we can marry the modularity with ease of use. Type parameters stay modular, yet there are implementations that naturaly fullfil them.

JaroslavTulach: /* Improvements */

2011-05-08T19:30:46Z

Improvements

←Older revision		Revision as of 19:30, 8 May 2011
Line 20:		Line 20:
	== Improvements ==		== Improvements ==

-	[[~~TBD~~]]	+	Interesting new possibility is to use [[Java]] generics. Instead of abstracting the common interface (that ''text'' and ''loaders'' [[API]] needs), one can enumerate a set of common interfaces comming for example from [[JDK]] and require them all:
		+
		+	<source lang="java">
		+	<T extends Runnable & Callable & PropertyChangeListener> int myMethod(T multiType);
		+	</source>
		+
		+	This is gettting closer to the style of functional programming as pioneered by [[Haskell]] (or [[Clean]]). Define a lot of abstract ''categories'' (in their terminology ''classes'', but don't confuse that with [[OOP]] classes) and then use these categories to define appropriate type for each function/method.
		+
		+	In case one can find good enough types in the base, this kind of ''on the fly'' creation of types is usually more flexible.
		+
	== Result ==		== Result ==

	[[TBD]]		[[TBD]]

JaroslavTulach: /* History */

2011-05-08T19:25:28Z

History

←Older revision		Revision as of 19:25, 8 May 2011
Line 16:		Line 16:
	== History ==		== History ==

-	[[~~TBD~~]]	+	The common style to achieve this is to create a new, [[AbstractedTypes]] and put them into new module that both ''text'' and ''loaders'' [[API]] will depend on. This works fine, but requires creation of whole new [[API]] module. In my case that was not really appropriate. Any other option?

	== Improvements ==		== Improvements ==

JaroslavTulach: /* Setup */

2011-04-21T06:27:14Z

Setup

←Older revision		Revision as of 06:27, 21 April 2011
Line 11:		Line 11:
	Users of the [[NetBeans]] [[API]] People often create their own {{NB\|org-openide-loaders\|org/openide/loaders\|DataObject}} implementations to represent textual data. Good, there is support for that in the ''Loaders API''. There is however common requirement to show not only editor, but also other view, e.g. to use ''MultiView API''.		Users of the [[NetBeans]] [[API]] People often create their own {{NB\|org-openide-loaders\|org/openide/loaders\|DataObject}} implementations to represent textual data. Good, there is support for that in the ''Loaders API''. There is however common requirement to show not only editor, but also other view, e.g. to use ''MultiView API''.

-	However ''Loaders API'' knows nothing about ''MultiView API'' and ''MultiView API'' knows nothing about ''Loaders API''. Their only common dependency is the ''Text API''. Can I write a wizard to generate simple, maintainable code that defines {{NB\|org-openide-loaders\|org/openide/loaders\|DataObject}} represented by a	+	However ''Loaders API'' knows nothing about ''MultiView API'' and ''MultiView API'' knows nothing about ''Loaders API''. Their only common dependency is the ''Text API''. Can I write a wizard to generate simple, maintainable code that defines {{NB\|org-openide-loaders\|org/openide/loaders\|DataObject}} represented by few
-	{{NB\|org-netbeans-core-multiview\|org/netbeans/core/spi/multiview\|MultiViewElement}}?	+	{{NB\|org-netbeans-core-multiview\|org/netbeans/core/spi/multiview\|MultiViewElement}}s including one for text editor?

	== History ==		== History ==

JaroslavTulach at 06:26, 21 April 2011

2011-04-21T06:26:12Z

←Older revision		Revision as of 06:26, 21 April 2011
Line 1:		Line 1:
-	By splitting [[API]]s into multiple [[module]]s one increases their flexibility. The [[API]] become independent and can be used in new contexts, without the rest of the [[API]]s being present. However one also complicates the usage, as for some, original (in case the [[API]] used to be present as a whole) [[usecase]]s, the users need to try harder to make the [[API]]s work together. That is indeed not [[good]] (as it increases '[[~~time to market~~]]). This article describes one of my advantures where I had to deal with similar situation.	+	By splitting [[API]]s into multiple [[module]]s one increases their flexibility. The [[API]] become independent and can be used in new contexts, without the rest of the [[API]]s being present. However one also complicates the usage, as for some, original (in case the [[API]] used to be present as a whole) [[usecase]]s, the users need to try harder to make the [[API]]s work together. That is indeed not [[good]] (as it increases [[Time To Market]]). This article describes one of my advantures where I had to deal with similar situation.

	== Setup ==		== Setup ==

JaroslavTulach: New page: By splitting APIs into multiple modules one increases their flexibility. The API become independent and can be used in new contexts, without the rest of the APIs being pres...

2011-04-21T06:22:28Z

New page: By splitting APIs into multiple modules one increases their flexibility. The API become independent and can be used in new contexts, without the rest of the APIs being pres...

New page

By splitting [[API]]s into multiple [[module]]s one increases their flexibility. The [[API]] become independent and can be used in new contexts, without the rest of the [[API]]s being present. However one also complicates the usage, as for some, original (in case the [[API]] used to be present as a whole) [[usecase]]s, the users need to try harder to make the [[API]]s work together. That is indeed not [[good]] (as it increases '[[time to market]]). This article describes one of my advantures where I had to deal with similar situation.

== Setup ==

There are following modules In the [[NetBeans]] [[API]]s:

* ''Text API'' - contains class like {{NB|org-openide-text|org/openide/text|CloneableEditorSupport.Pane}} and some of its implementations and can open editor for any source of characters
* ''MultiView API'' - depends on ''Text API'' and provides another implementation of the pane which can be created by {{NB|org-netbeans-core-multiview|org/netbeans/core/spi/multiview|MultiViewFactory}}.
* ''Loaders API'' - which depends on ''Text API'' and connects it with real files on disk via functionality provided by {{NB|org-openide-loaders|org/openide/loaders|DataObject}}.

Users of the [[NetBeans]] [[API]] People often create their own {{NB|org-openide-loaders|org/openide/loaders|DataObject}} implementations to represent textual data. Good, there is support for that in the ''Loaders API''. There is however common requirement to show not only editor, but also other view, e.g. to use ''MultiView API''.

However ''Loaders API'' knows nothing about ''MultiView API'' and ''MultiView API'' knows nothing about ''Loaders API''. Their only common dependency is the ''Text API''. Can I write a wizard to generate simple, maintainable code that defines {{NB|org-openide-loaders|org/openide/loaders|DataObject}} represented by a
{{NB|org-netbeans-core-multiview|org/netbeans/core/spi/multiview|MultiViewElement}}?

== History ==

[[TBD]]

== Improvements ==

[[TBD]]
== Result ==

[[TBD]]