Subject: Re: When to Augment? - msg#00021

Previous Message by Date:

Re: Specifying a assembly library path

On Jan 8, 2008 10:18 PM, Tizzo <schaveyt-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote: You are correct. BizModel.dll does rely on Common.dll. Unfortunatelythe compiler option isn't viable for how we were hoping to useRuby.NET. I'm stumped :-( Based on your original post, Common.dll is signed.  Is installing it into the GAC an option?-- /M:DM. David PetersonCo-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david-XrOFGb+KrGt/A6jMX7u9Dg@xxxxxxxxxxxxxxxx | m.david-joz/7I5UqYw@xxxxxxxxxxxxxxxxMobile: (206) 418-9027http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354

Next Message by Date:

Re: When to Augment?

Joshua Graham wrote: In the JRuby effort (and Charles please correct me if I'm wrong) the only augmentation of Java classes baked directly into JRuby is in transliterating method names from a Java convention into a Ruby convention - mostly it's providing Ruby-style lowercase_underscore method names of Java's lowerCamelCase ones. This is a general feature applied to all Java classes in use by the Ruby code. I did have a patch to add similar conversion, I wonder what ever happened to it. I think following JRuby where possible is appropriate. But I'm curious, do ordinary Java instances not respond to 'to_s', 'hash' and 'is_a?' ? These seem fairly crucial. 'each' while not crucial, seems a very useful case for IEnumerable since this also enables the ruby 'for x in y' syntax. If I had some Java component whose API was "clumsy" from a Ruby point of view, and the Ruby world didn't already have something acceptable, I would either create a new type in Ruby with an appropriate interface and delegate to the Java class, or use JRuby's Java support to extend the Java class with additional Ruby methods. I'd then release that as part of a Ruby gem because having such augmentations built into JRuby would be a bit of a headache I suspect. There's some JRuby "extras" gems useful for augmenting major libraries implemented in Java with no good Ruby equivalent. Ok, it sounds like a similar approach would work here, it is easy enough to augment from within ruby.net. Doug

Previous Message by Thread:

When to Augment?

Tizzo wrote: Awesome thanks. Should this type of augmentation be committed to the main trunk as I think it would be very common usages? Same goes for hashtables.... Yes, I think this should go into the repo, it seems useful. This patch already applys to (System.Collections.HashTable), but it will yeild KeyValuePairs rather than |key,value|. This can of course be altered to match ruby. However I'm wondering how far we should take this. Take Ruby::Hash and S.C.HashTable for example. If HashTable appears to respond to "each" will a user be confused if it doesn't also respond to "each_key" and the rest of the Ruby API? We could go ahead and augment with most of the equivalent Ruby API, but still only to a certain extent. eg. ruby's hash supports a default value, while the BCL hash cannot. My initial motivation for adding augmentations was to support only the very basic object methods "to_s", "hash", "kind_of?"... How can we determine what the fundamental methods are? "each" seems a useful primitive, but so does much of the Ruby API ;) Doug

Next Message by Thread:

Re: When to Augment?

Joshua Graham wrote: In the JRuby effort (and Charles please correct me if I'm wrong) the only augmentation of Java classes baked directly into JRuby is in transliterating method names from a Java convention into a Ruby convention - mostly it's providing Ruby-style lowercase_underscore method names of Java's lowerCamelCase ones. This is a general feature applied to all Java classes in use by the Ruby code. I did have a patch to add similar conversion, I wonder what ever happened to it. I think following JRuby where possible is appropriate. But I'm curious, do ordinary Java instances not respond to 'to_s', 'hash' and 'is_a?' ? These seem fairly crucial. 'each' while not crucial, seems a very useful case for IEnumerable since this also enables the ruby 'for x in y' syntax. If I had some Java component whose API was "clumsy" from a Ruby point of view, and the Ruby world didn't already have something acceptable, I would either create a new type in Ruby with an appropriate interface and delegate to the Java class, or use JRuby's Java support to extend the Java class with additional Ruby methods. I'd then release that as part of a Ruby gem because having such augmentations built into JRuby would be a bit of a headache I suspect. There's some JRuby "extras" gems useful for augmenting major libraries implemented in Java with no good Ruby equivalent. Ok, it sounds like a similar approach would work here, it is easy enough to augment from within ruby.net. Doug