Professional Web Applications Themes

Finer-grained modules (like Enumarable) for Collections? - Ruby

I've been wondering what fine-grained module structure (like Enumerable) would make sense for collections, and just came across this work where the Smalltalk collections were refactored using somthing they called Traits (for all practical purposes, these are like Ruby modules). [url]http://www.iam.unibe.ch/~scg/Archive/Papers/Blac02aTraitsHierarchy.pdf[/url] There were some very useful ideas in this re-factoring. e.g. module TEmptiness #requires "size" def isEmpty () ... def notEmpty () ... def ifEmpty (&block) def ifNotEmpty (&block) etc. end Beyond this, there are many other candidates for module-like refactoring e.g. see Larch traits [url]http://www.cs.iastate.edu/~leavens/Handbooks.html[/url]. Any thoughts on the benefits / possibility of using some ideas from here to ...

  1. #1

    Default Finer-grained modules (like Enumarable) for Collections?

    I've been wondering what fine-grained module structure (like Enumerable)
    would make sense for collections, and just came across this work where the
    Smalltalk collections were refactored using somthing they called Traits (for
    all practical purposes, these are like Ruby modules).

    [url]http://www.iam.unibe.ch/~scg/Archive/Papers/Blac02aTraitsHierarchy.pdf[/url]

    There were some very useful ideas in this re-factoring. e.g.

    module TEmptiness
    #requires "size"
    def isEmpty () ...
    def notEmpty () ...
    def ifEmpty (&block)
    def ifNotEmpty (&block)
    etc.
    end

    Beyond this, there are many other candidates for module-like refactoring
    e.g. see Larch traits [url]http://www.cs.iastate.edu/~leavens/Handbooks.html[/url].

    Any thoughts on the benefits / possibility of using some ideas from here to
    provide more fine-grained modules in Ruby libraries?

    Cheers ....


    Its Me Guest

  2. #2

    Default Re: Finer-grained modules (like Enumarable) for Collections?


    "Its Me" <itsme213hotmail.com> schrieb im Newsbeitrag
    news:pLm8b.12869$834.1581twister.austin.rr.com...
    > I've been wondering what fine-grained module structure (like Enumerable)
    > would make sense for collections, and just came across this work where
    the
    > Smalltalk collections were refactored using somthing they called Traits
    (for
    > all practical purposes, these are like Ruby modules).
    >
    > [url]http://www.iam.unibe.ch/~scg/Archive/Papers/Blac02aTraitsHierarchy.pdf[/url]
    >
    > There were some very useful ideas in this re-factoring. e.g.
    >
    > module TEmptiness
    > #requires "size"
    > def isEmpty () ...
    > def notEmpty () ...
    > def ifEmpty (&block)
    > def ifNotEmpty (&block)
    > etc.
    > end
    Interesting approach. I like these kind of things because they increase
    modularity and improve reusability though I can't comment on efficiency
    issues with Ruby in this case. (We'd get lot's of modules that are
    included in Enumerable which in turn is included in std collection types.)

    The question remains whether it is worthwile. Because of Ruby's nature it
    does not hurt to include Enumerable - even if it would depend on more than
    just a single method and not all of these methods were present. IMHO the
    small gain would be expressions like "obj.kind_of? TEmptiness" but we'd
    get a lot more modules at the same time. This need not necessary mean
    "more readable doentation" and it can mean slower execution.
    > Any thoughts on the benefits / possibility of using some ideas from here
    to
    > provide more fine-grained modules in Ruby libraries?
    While we're at it: I'd suggest to include size and empty? in Enumerable.
    It would not hurt IMHO and there might be custom collections which can't
    implement size and empty? more efficiently than via iterating all
    elements.

    Regards

    robert

    Robert Klemme Guest

  3. #3

    Default Re: Finer-grained modules (like Enumarable) for Collections?

    On Sat, Sep 13, 2003 at 02:17:54AM +0900, Robert Klemme wrote:
    > > There were some very useful ideas in this re-factoring. e.g.
    > >
    > > module TEmptiness
    > > #requires "size"
    > > def isEmpty () ...
    > > def notEmpty () ...
    > > def ifEmpty (&block)
    > > def ifNotEmpty (&block)
    > > etc.
    > > end
    >
    > Interesting approach. I like these kind of things because they increase
    > modularity and improve reusability though I can't comment on efficiency
    > issues with Ruby in this case. (We'd get lot's of modules that are
    > included in Enumerable which in turn is included in std collection types.)
    This can be leveraged to ease Ruby-in-Ruby or to reimplement the
    interpreter: see matju's MetaRuby.


    --
    _ _
    | |__ __ _| |_ ___ _ __ ___ __ _ _ __
    | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
    | |_) | (_| | |_\__ \ | | | | | (_| | | | |
    |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    * LG loves czech girls.
    <vincent> LG: do they have additional interesting "features" other girls don't have? ;)
    -- #Debian

    Mauricio Fernández Guest

Similar Threads

  1. Replies: 0
    Last Post: July 27th, 02:45 PM
  2. Replies: 4
    Last Post: July 10th, 11:57 AM
  3. Fine-grained auditing question
    By Trent in forum Oracle Server
    Replies: 4
    Last Post: December 17th, 12:59 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139