Professional Web Applications Themes

"stereotyping" (was: Strong Typing (Managing metadataabout attribute types) ) - Ruby

> In sean's case, class and/or module were sufficient to define > interface. [...] He goes on to say the same re: inheritance > and module inclusion. To be fair, he goes beyond class/module model. The reason we tend to object to the class/module model of interfaces is that things like StringIO, which has no module or inheritance relationship with IO, tends to be used in places where an IO object is expected. But Sean also proposes an interface command that can be used to indicate non-class/non-module conformance. You can say ... class StringIO interface IO end The interface command ...

  1. #1

    Default Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadataabout attribute types) )

    > In sean's case, class and/or module were sufficient to define
    > interface. [...] He goes on to say the same re: inheritance
    > and module inclusion.
    To be fair, he goes beyond class/module model. The reason we tend to object
    to the class/module model of interfaces is that things like StringIO, which
    has no module or inheritance relationship with IO, tends to be used in
    places where an IO object is expected.

    But Sean also proposes an interface command that can be used to indicate
    non-class/non-module conformance. You can say ...

    class StringIO
    interface IO
    end

    The interface command adds IO to a list of supported interfaces for the
    StringIO class. It gets no implementation from IO, nor does it inherit from
    IO. The interface command is just there so that any conformance testing on
    a StringIO object can say "Oh look. This object claims to be able to do
    whatever an IO object would do".

    This decouples conformance from mere class inheritance/module inclusion,
    although class inheritance and module inclusion still count as conformance.

    I haven't decided whether I like this or not. Right now I'm kinda neutral.
    It avoids the problem of decreased flexibility at the cost of an extra line
    of code.

    --
    -- Jim (still thinking about it) Weirich

    Weirich, James Guest

  2. #2

    Default Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

    On Fri, Nov 21, 2003 at 09:21:42AM +0900, Austin Ziegler wrote:
    > On Fri, 21 Nov 2003 08:07:34 +0900, Weirich, James wrote:
    > > I haven't decided whether I like this or not. Right now I'm kinda
    > > neutral. It avoids the problem of decreased flexibility at the cost
    > > of an extra line of code.
    > I don't like it because it's an empty promise.
    Until I know that Object (or Foo, elsewhere, for that matter) hasn't had
    method_missing redefined to catch read(bytes) and do something sensible
    with it self.kind_of?(Foo), I can't declare the below to be an "empty
    promise"... ;)
    > class Foo
    > interface IO
    > end
    > Now, if I try to use Foo somewhere, I've promised that it can do IO --
    > but it can't. I haven't implemented any of the methods required to do
    > so.
    Then allow interface to check for required methods.

    (And IMNSHO, IO would be a useless interface - it's far too broad for at
    least 80% of cases. It should be broken down into at least
    IOStreamRead, IOStreamWrite, IOStreamSeekable and possibly more.
    Although interface combinations might be useful.)
    > It also doesn't get us any closer to the concept of signature
    > metadata, which despite my misgivings about wanting "contractual
    > obligations", I believe Ruby needs for exposing programs to
    > non-dynamic languages over wire protocols.
    I don't follow. If I write a library which operates on or with a
    complex (ie. non-built in type), then I need to define how this complex
    object should behave in terms of required methods. The best mechanism I
    have seen anywhere in any language for doing this is an interface.
    However traditional interface constraints (as per staticly typed
    languages) might limit usefulness of such a feature in a language as
    dynamic as Ruby, so a softer (probably runtime) approach would be more
    in keeping with existing language features and checks.

    That said, in the interests of programmers who use irb for doentation
    and reflection in general, it is also highly desirable for the
    expectations and provisions of an interface to queryable from Ruby code.

    And it does get us closer - not all the way to a C function declaration,
    but closer to a workable and rubyish contractual obligation between
    classes.

    TTFN,


    Geoff.



    Geoff Youngs Guest

  3. #3

    Default Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

    il Fri, 21 Nov 2003 10:53:21 +0900, Geoff Youngs
    <gintersect-uk.co.uk> ha scritto::
    >(And IMNSHO, IO would be a useless interface - it's far too broad for at
    >least 80% of cases. It should be broken down into at least
    >IOStreamRead, IOStreamWrite, IOStreamSeekable and possibly more.
    >Although interface combinations might be useful.)
    >
    well, apart from more Rubysh names (like Input and Output)
    I strongly agree with you.

    em... cough..rcr..cough
    gabriele renzi Guest

Similar Threads

  1. Replies: 0
    Last Post: November 20th, 10:38 PM
  2. Replies: 4
    Last Post: November 20th, 10:25 AM
  3. Replies: 0
    Last Post: November 20th, 02:46 AM
  4. Replies: 11
    Last Post: November 20th, 02:27 AM
  5. Replies: 3
    Last Post: November 19th, 09:08 PM

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