JaroslavTulach at 07:10, 15 April 2009 - 2009-04-15 07:10:35

←Older revision Revision as of 07:10, 15 April 2009
Line 82: Line 82:
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)
-
There are a couple of DI frameworks for Ruby, such as Needle, but I don't think any of them have gained much popularity. In general, people don't seem to find them as useful in Ruby as in Java - even the author of Needle nowadays considers DI frameworks unnecessary in Ruby. Given Ruby's dynamic nature, there is usually a way to achieve "DI" without needing a DI container; in particular being able to reopen classes and redefine methods takes you a long way. (emononen)
+
There are a couple of DI frameworks for Ruby, such as [http://needle.rubyforge.org/chapter-1.html Needle], but I don't think any of them have gained much popularity. In general, people don't seem to find them as useful in Ruby as in Java - even the author of Needle nowadays considers DI frameworks unnecessary in Ruby. Given Ruby's dynamic nature, there is usually a way to achieve "DI" without needing a DI container; in particular being able to reopen classes and redefine methods takes you a long way. (emononen)

192.9.112.196: /* Ruby Application Context */ - 2009-04-14 11:56:52

Ruby Application Context

←Older revision Revision as of 11:56, 14 April 2009
Line 81: Line 81:
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)
 +
 +
There are a couple of DI frameworks for Ruby, such as Needle, but I don't think any of them have gained much popularity. In general, people don't seem to find them as useful in Ruby as in Java - even the author of Needle nowadays considers DI frameworks unnecessary in Ruby. Given Ruby's dynamic nature, there is usually a way to achieve "DI" without needing a DI container; in particular being able to reopen classes and redefine methods takes you a long way. (emononen)

JaroslavTulach: /* Ruby Application Context */ - 2009-04-12 13:47:02

Ruby Application Context

←Older revision Revision as of 13:47, 12 April 2009
Line 74: Line 74:
== Ruby Application Context ==
== Ruby Application Context ==
-
Hi Jaroslav, Not sure what the procedure is for making comments here so I'm just going to let her rip. I've been reading your book and am going through Chapter 7 and I am finding it to be incredibly interesting. I wrote a [http://simpleconstraints.blogspot.com/2009/04/rails-has-no-application-context.html blog post] about how I'm applying this thinking to managing my Rails-based practice. To summarize, we are finding that there is no standard "application context" to create truly re-usable bits in the context of rails. I am beginning to have this dream of some kind of Rails Service Bus that would produce a standard interface for plugins, gems, whatever, to talk to your domain using a well-defined interface -- an API! -- so that it is possible to create expectations about what a plugin will do to your domain model. As it stands, plugins mercilessly hack at your model objects, so that if you wish to modify them further, you are constrained by spaghetti object implementation details with no interface or contract to fall back on. This is probably not really an intrinsic aspect of rails so much as it is an intrinsic property of rails plugin writers who seem mortally opposed to following modular OO concepts. It makes transitioning hard for a java guy.
+
Hi Jaroslav, Not sure what the procedure is for making comments here so I'm just going to let her rip. I've been reading your book and am going through [[Chapter 7]] and I am finding it to be incredibly interesting. I wrote a [http://simpleconstraints.blogspot.com/2009/04/rails-has-no-application-context.html blog post] about how I'm applying this thinking to managing my Rails-based practice. To summarize, we are finding that there is no standard "application context" to create truly re-usable bits in the context of rails. I am beginning to have this dream of some kind of Rails Service Bus that would produce a standard interface for plugins, gems, whatever, to talk to your domain using a well-defined interface -- an [[API]]! -- so that it is possible to create expectations about what a plugin will do to your domain model. As it stands, plugins mercilessly hack at your model objects, so that if you wish to modify them further, you are constrained by spaghetti object implementation details with no interface or contract to fall back on. This is probably not really an intrinsic aspect of rails so much as it is an intrinsic property of rails plugin writers who seem mortally opposed to following modular OO concepts. It makes transitioning hard for a java guy.
--[[User:SteveShapero]]
--[[User:SteveShapero]]
-
Hello Steve. Thanks for your talk back and thank for your blog post. Trying to simulate Lookup or Spring's injection in Ruby in typeless language may be hard. I am really interested to see how it goes. The important feature of [[Java]] that allows [[Lookup]] and [[Spring]] to work is strict type checking. You can request an interface, get a subclass and you know it implements all its methods. With [[Ruby]]'s duck-typing this may be a challenge. On the other hand [[wikipedia::Microsoft|Microsoft]] managed to create COM in [[C]], so this kind of [[teleinterface]] is definitely possible in any language.
+
Hello Steve. Thanks for your talk back and thank for your blog post. Trying to simulate [[Lookup]] or [[Spring]]'s injection in [[Ruby]] typeless language may be hard. I am really interested to see how it goes. The important feature of [[Java]] that allows [[Lookup]] and [[Spring]] to work is strict type checking. You can request an interface, get a subclass and you know it implements all its methods. With [[Ruby]]'s duck-typing this may be a challenge. On the other hand [[wikipedia::Microsoft|Microsoft]] managed to create COM in [[C]], so this kind of [[teleinterface]] is definitely possible in any language.
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)

JaroslavTulach: /* Ruby Application Context */ - 2009-04-11 19:18:42

Ruby Application Context

←Older revision Revision as of 19:18, 11 April 2009
Line 78: Line 78:
--[[User:SteveShapero]]
--[[User:SteveShapero]]
-
Hello Steve. Thanks for your talk back and thank for your blog post. Trying to simulate Lookup or Spring's injection in Ruby in typeless language may be hard. I am really interested to see how it goes. The important feature of [[Java]] that allows [[Lookup]] and [[Spring]] to work is strict type checking. You can request an interface, get a subclass and you know it implements all its methods. With [[Ruby]]'s duck-typing this may be a challenge. On the other hand [[wikipedia::Microsoft]] managed to create COM in [[C]], so this kind of [[teleinterface]] is definitely possible in any language.
+
Hello Steve. Thanks for your talk back and thank for your blog post. Trying to simulate Lookup or Spring's injection in Ruby in typeless language may be hard. I am really interested to see how it goes. The important feature of [[Java]] that allows [[Lookup]] and [[Spring]] to work is strict type checking. You can request an interface, get a subclass and you know it implements all its methods. With [[Ruby]]'s duck-typing this may be a challenge. On the other hand [[wikipedia::Microsoft|Microsoft]] managed to create COM in [[C]], so this kind of [[teleinterface]] is definitely possible in any language.
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)

JaroslavTulach at 19:16, 11 April 2009 - 2009-04-11 19:16:14

←Older revision Revision as of 19:16, 11 April 2009
Line 72: Line 72:
--[[User:JaroslavTulach|JaroslavTulach]] 09:14, 30 September 2008 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 09:14, 30 September 2008 (UTC)
-
Hi Jaroslav, Not sure what the procedure is for making comments here so I'm just going to let her rip. I've been reading your book and am going through Chapter 7 and I am finding it to be incredibly interesting. I wrote a [http://simpleconstraints.blogspot.com/2009/04/rails-has-no-application-context.html blog post] about how I'm applying this thinking to managing my Rails-based practice. To summarize, we are finding that there is no standard "application context" to create truly re-usable bits in the context of rails. I am beginning to have this dream of some kind of Rails Service Bus that would produce a standard interface for plugins, gems, whatever, to talk to your domain using a well-defined interface -- an API! -- so that it is possible to create expectations about what a plugin will do to your domain model. As it stands, plugins mercilessly hack at your model objects, so that if you wish to modify them further, you are constrained by spaghetti object implementation details with no interface or contract to fall back on. This is probably not really an intrinsic aspect of rails so much as it is an intrinsic property of rails plugin writers who seem mortally opposed to following modular OO concepts. It makes transitioning hard for a java guy. --[[User:SteveShapero]]
+
== Ruby Application Context ==
 +
 
 +
Hi Jaroslav, Not sure what the procedure is for making comments here so I'm just going to let her rip. I've been reading your book and am going through Chapter 7 and I am finding it to be incredibly interesting. I wrote a [http://simpleconstraints.blogspot.com/2009/04/rails-has-no-application-context.html blog post] about how I'm applying this thinking to managing my Rails-based practice. To summarize, we are finding that there is no standard "application context" to create truly re-usable bits in the context of rails. I am beginning to have this dream of some kind of Rails Service Bus that would produce a standard interface for plugins, gems, whatever, to talk to your domain using a well-defined interface -- an API! -- so that it is possible to create expectations about what a plugin will do to your domain model. As it stands, plugins mercilessly hack at your model objects, so that if you wish to modify them further, you are constrained by spaghetti object implementation details with no interface or contract to fall back on. This is probably not really an intrinsic aspect of rails so much as it is an intrinsic property of rails plugin writers who seem mortally opposed to following modular OO concepts. It makes transitioning hard for a java guy.
 +
 
 +
--[[User:SteveShapero]]
 +
 
 +
Hello Steve. Thanks for your talk back and thank for your blog post. Trying to simulate Lookup or Spring's injection in Ruby in typeless language may be hard. I am really interested to see how it goes. The important feature of [[Java]] that allows [[Lookup]] and [[Spring]] to work is strict type checking. You can request an interface, get a subclass and you know it implements all its methods. With [[Ruby]]'s duck-typing this may be a challenge. On the other hand [[wikipedia::Microsoft]] managed to create COM in [[C]], so this kind of [[teleinterface]] is definitely possible in any language.
 +
 
 +
--[[User:JaroslavTulach|JaroslavTulach]] 19:16, 11 April 2009 (UTC)

Basscakes: /* Modularity */ - 2009-04-10 22:37:17

Modularity

←Older revision Revision as of 22:37, 10 April 2009
Line 71: Line 71:
Thanks for your comments and I am looking forward to chat more.
Thanks for your comments and I am looking forward to chat more.
--[[User:JaroslavTulach|JaroslavTulach]] 09:14, 30 September 2008 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 09:14, 30 September 2008 (UTC)
 +
 +
Hi Jaroslav, Not sure what the procedure is for making comments here so I'm just going to let her rip. I've been reading your book and am going through Chapter 7 and I am finding it to be incredibly interesting. I wrote a [http://simpleconstraints.blogspot.com/2009/04/rails-has-no-application-context.html blog post] about how I'm applying this thinking to managing my Rails-based practice. To summarize, we are finding that there is no standard "application context" to create truly re-usable bits in the context of rails. I am beginning to have this dream of some kind of Rails Service Bus that would produce a standard interface for plugins, gems, whatever, to talk to your domain using a well-defined interface -- an API! -- so that it is possible to create expectations about what a plugin will do to your domain model. As it stands, plugins mercilessly hack at your model objects, so that if you wish to modify them further, you are constrained by spaghetti object implementation details with no interface or contract to fall back on. This is probably not really an intrinsic aspect of rails so much as it is an intrinsic property of rails plugin writers who seem mortally opposed to following modular OO concepts. It makes transitioning hard for a java guy. --[[User:SteveShapero]]

JaroslavTulach at 09:34, 30 September 2008 - 2008-09-30 09:34:04

←Older revision Revision as of 09:34, 30 September 2008
Line 1: Line 1:
 +
== Duck-typing ==
 +
This is where Java's strong typing steps in your way. What about languages which do not have such strong typing? For example Ruby's duck-typing seems to sidestep this problem in a simple way - because there is no need for "abstract" in Ruby, this issue obviously does not exist there. The price you pay for this flexibility in Ruby in this case is that you should use introspection (xx.respond_to? :getHTMLTitle) to find out whether the object xx actually provides the method getHTMLTitle or not. However, if you have not used Ruby before, beware - Java programmers usually do hate it, just because it is not strong typed - they refuse the duck-typing just because it seems perverse to them. However, it is not so perverse once you get used to it. ;-)
This is where Java's strong typing steps in your way. What about languages which do not have such strong typing? For example Ruby's duck-typing seems to sidestep this problem in a simple way - because there is no need for "abstract" in Ruby, this issue obviously does not exist there. The price you pay for this flexibility in Ruby in this case is that you should use introspection (xx.respond_to? :getHTMLTitle) to find out whether the object xx actually provides the method getHTMLTitle or not. However, if you have not used Ruby before, beware - Java programmers usually do hate it, just because it is not strong typed - they refuse the duck-typing just because it seems perverse to them. However, it is not so perverse once you get used to it. ;-)
Line 48: Line 50:
--[[User:JaroslavTulach|JaroslavTulach]] 15:48, 22 September 2008 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 15:48, 22 September 2008 (UTC)
 +
 +
== Modularity ==
If you would like to write a code which could use both the old version of the class (which does not provide some method) and the new version of the class (which provides that method), you would obviously end up with the code similar to "if (using_new_class) { use_provided_method } else { do_it_yourself }", which is not nice.
If you would like to write a code which could use both the old version of the class (which does not provide some method) and the new version of the class (which provides that method), you would obviously end up with the code similar to "if (using_new_class) { use_provided_method } else { do_it_yourself }", which is not nice.

JaroslavTulach at 09:14, 30 September 2008 - 2008-09-30 09:14:33

←Older revision Revision as of 09:14, 30 September 2008
Line 54: Line 54:
If used with a proper versioning system (based for example on something like RubyGems' "gem 'library_name', '>= 3.1', '< 4.0'" attached to the client code), this could result in a quite nice approach to API evolution, couldn't it? The infrastructure would ensure that you would have a class with proper version available, so you could avoid writing the ugly code testing for availability of the methods you would like to use. On the other hand you would be obligated to increase the major version number of the library every time you introduce any backward-incompatible change to it. It would be nice to have such version numbers generated automatically, but because it is impossible to do it 100% correctly (think about semantic changes, time or memory effectiveness, etc.), letting the author of the library to assign the version numbers seems like a reasonable approach.
If used with a proper versioning system (based for example on something like RubyGems' "gem 'library_name', '>= 3.1', '< 4.0'" attached to the client code), this could result in a quite nice approach to API evolution, couldn't it? The infrastructure would ensure that you would have a class with proper version available, so you could avoid writing the ugly code testing for availability of the methods you would like to use. On the other hand you would be obligated to increase the major version number of the library every time you introduce any backward-incompatible change to it. It would be nice to have such version numbers generated automatically, but because it is impossible to do it 100% correctly (think about semantic changes, time or memory effectiveness, etc.), letting the author of the library to assign the version numbers seems like a reasonable approach.
 +
 +
 +
-- Anonymous, Sep 29, 2008
 +
 +
Re: ''benefit of Ruby''. My whole point is that this is not really due to ''duck-typing''. In fact I can rewrite the whole paragraph and use Java and it will still be true:
 +
''I think that the benefit of Java in this case is that you can seamlessly use the new version of the class with some legacy code which uses this class (with absolutelly no change needed for that legacy code). Of course only if the new version of the class would not break whatever the old version of the class has provided already. Adding new functionality is allowed.''
 +
 +
Re: ''proper versioning system''. Exactly, proper versioning system is very important prerequisite for good API design. The JDK (up to version 6) suffers from not using versioning system, so do regular Java applications. On the other hand, this is not weakness of [[Java]]. [[NetBeans]] have its module system and there is [[OSGi]]. Both these systems allow to precisely express the required APIs together with their minimal version. They also support some kind of major incompatible version release. Similar to Gems, I guess. You are right that we are missing tools that would guarantee easy [[Upgradability]] of one version by another, so it is more or less matter of common sense and compatibility rules awareness of the library author.
 +
 +
I guess that, if [[TheAPIBook]] offers some knowledge not widely spread among the Java SE community, then it is the modularity, its use and benefits. The book propagates use of module architecture in [[Use_Modular_Architecture|Chapter 7]], it describes few adventures when trying to make multiple versions of the same library co-exist with each other in [[Evolving_the_API_Universe|Chapter 15]] and finally it also shows the advantages of proper versioning for ''end of life'' policies in [[End_Of_Life_Procedures|Chapter 19]]. I believe modularity is necessary component for modern applications in any language.
 +
 +
Thanks for your comments and I am looking forward to chat more.
 +
--[[User:JaroslavTulach|JaroslavTulach]] 09:14, 30 September 2008 (UTC)

88.100.26.106 at 00:52, 29 September 2008 - 2008-09-29 00:52:17

←Older revision Revision as of 00:52, 29 September 2008
Line 48: Line 48:
--[[User:JaroslavTulach|JaroslavTulach]] 15:48, 22 September 2008 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 15:48, 22 September 2008 (UTC)
 +
 +
If you would like to write a code which could use both the old version of the class (which does not provide some method) and the new version of the class (which provides that method), you would obviously end up with the code similar to "if (using_new_class) { use_provided_method } else { do_it_yourself }", which is not nice.
 +
 +
I think that the benefit of Ruby in this case is that you can seamlessly use the new version of the class with some legacy code which uses this class (with absolutelly no change needed for that legacy code). Of course only if the new version of the class would not break whatever the old version of the class has provided already. Adding new functionality is allowed.
 +
 +
If used with a proper versioning system (based for example on something like RubyGems' "gem 'library_name', '>= 3.1', '< 4.0'" attached to the client code), this could result in a quite nice approach to API evolution, couldn't it? The infrastructure would ensure that you would have a class with proper version available, so you could avoid writing the ugly code testing for availability of the methods you would like to use. On the other hand you would be obligated to increase the major version number of the library every time you introduce any backward-incompatible change to it. It would be nice to have such version numbers generated automatically, but because it is impossible to do it 100% correctly (think about semantic changes, time or memory effectiveness, etc.), letting the author of the library to assign the version numbers seems like a reasonable approach.

JaroslavTulach at 16:22, 22 September 2008 - 2008-09-22 16:22:15

←Older revision Revision as of 16:22, 22 September 2008
Line 45: Line 45:
Only then you simplify life of your API clients. I'd bet that similar code can be rewritten to Ruby, without use of duck-typing. As such, I'd like to conclude that duck-typing does not simplify API evolution, at least not in this particular case.
Only then you simplify life of your API clients. I'd bet that similar code can be rewritten to Ruby, without use of duck-typing. As such, I'd like to conclude that duck-typing does not simplify API evolution, at least not in this particular case.
-
Looks like [[Blogs:JaroslavTulach:LanguagesForEvolution|Languages Ready for Evolution]] are unlikely to benefit from duck-typing.
+
Looks like [[Blogs:JaroslavTulach:Theory:LanguagesForEvolution|Languages Ready for Evolution]] are unlikely to benefit from duck-typing.
--[[User:JaroslavTulach|JaroslavTulach]] 15:48, 22 September 2008 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 15:48, 22 September 2008 (UTC)