Loading ...
Sorry, an error occurred while loading the content.
 

multimethods, selectors, messages, etc.

Expand Messages
  • Mike
    In everybody s experience, what are your thoughts on using selectors, methods, messages, etc. That is very vague, so let me paint a picture: # A) Create slot
    Message 1 of 6 , Nov 1, 2002
      In everybody's experience, what are your thoughts on using selectors,
      methods, messages, etc. That is very vague, so let me paint a
      picture:

      # A) Create slot 'dothis'
      slot dothis { :arg1, that:arg2 | ... }
      # B) Create slot 'dothis:that:'
      slot dothis:that: { arg1, arg2 | ... }

      # A) Send object method 'dothis' message ':10 and: 20'
      object dothis: 10 and: 20
      # B) Send object message 'dothis:10 and:20'
      object dothis: 10 and: 20

      I'm gravitating towards B because you can separate the message from
      the method, to store or pass it to another object for example.

      The following methods take the same parameters:

      drawLine: 10,10 to: 20,20
      drawRect: 10,10 to: 20,20

      In case A, I can package the message ':10,10 to:20,20' and do
      something like:

      drawLine: message
      drawRect: message

      Whereas with B I cannot because the method is part of the selector.
      Also, B starts looking ugly with variable arguments:

      perform: a with: b with: c with: d

      would need three methods defined for each number of with: parameters.
      On the other side, using A allows a type of multimethods. For
      example:

      method drawRect: 10,10 to: 20,20
      method drawRect: 10,10 width: 10,10

      Would invoke two different methods.

      I just woke up, so if I sound dyslexic that's why :)
      Mike
    • Jack Waugh
      In your option A, what would be the effect of any keywords in the message? They have to be correct or it s an error? Anyway, almost all my OO experience is
      Message 2 of 6 , Nov 2, 2002
        In your option A, what would be the effect of any keywords in the
        message? They have to be correct or it's an error?

        Anyway, almost all my OO experience is with Smalltalk, where the
        keywords are part of the selector and their order matters. (I have
        been thinking that for a new language, I would try saying keywords
        are part of the selector but their order does not matter.)

        > In case A, I can package the message ':10,10 to:20,20' and do
        > something like:
        >
        > drawLine: message
        > drawRect: message
        >
        > Whereas with B I cannot because the method is part of the selector.

        I don't think you can possibly mean what you wrote. The term
        "method" means the procedure that the dispatch mechanism can
        invoke in response to a message. The term "selector" means a
        key that we find in the message and in (or associated to) each
        method, such that one of the requirements for a given method
        to field a given message is that their selectors are equal.

        I guess you mean that with B you cannot, because B doesn't provide
        a way to sever the selector completely from a message (or part of
        a message) that the language lets you encapsulate.

        > On the other side, using A allows a type of multimethods. For
        > example:
        >
        > method drawRect: 10,10 to: 20,20
        > method drawRect: 10,10 width: 10,10
        >
        > Would invoke two different methods.

        That doesn't look like multimethods to me. Multimethods means
        that what method gets invoked to field a given message can depend
        on the (dynamic) types of more than one of the arguments.
        In your example above, the arguments are all number pairs, and
        the selectors differ.
      • Mike
        Sorry, I don t code by profession so my terminology is a bit off. My latest ideas on syntax revolve around method signatures i.e. drawLine instead of
        Message 3 of 6 , Nov 3, 2002
          Sorry, I don't code by profession so my terminology is a bit off. My
          latest ideas on syntax revolve around method signatures
          i.e. 'drawLine' instead of 'drawLine:to:', and keyword messages.

          drawLine = { from: x1y1, to: x2y2, ... }
          drawLine from: 10,10 to: 20,20

          By using optional keywords, I can translate this into:
          v
          drawLine :10,10 to: 20,20
          v
          drawLine: 10,10 to: 20,20
          or
          drawLine: 10,10 : 20,20 if you wanted.

          Just my thoughts.

          --- In langsmiths@y..., "Jack Waugh" <waugh@a...> wrote:
          > In your option A, what would be the effect of any keywords in the
          > message? They have to be correct or it's an error?
          >
          > Anyway, almost all my OO experience is with Smalltalk, where the
          > keywords are part of the selector and their order matters. (I have
          > been thinking that for a new language, I would try saying keywords
          > are part of the selector but their order does not matter.)
          >
          > > In case A, I can package the message ':10,10 to:20,20' and do
          > > something like:
          > >
          > > drawLine: message
          > > drawRect: message
          > >
          > > Whereas with B I cannot because the method is part of the
          selector.
          >
          > I don't think you can possibly mean what you wrote. The term
          > "method" means the procedure that the dispatch mechanism can
          > invoke in response to a message. The term "selector" means a
          > key that we find in the message and in (or associated to) each
          > method, such that one of the requirements for a given method
          > to field a given message is that their selectors are equal.
          >
          > I guess you mean that with B you cannot, because B doesn't provide
          > a way to sever the selector completely from a message (or part of
          > a message) that the language lets you encapsulate.
          >
          > > On the other side, using A allows a type of multimethods. For
          > > example:
          > >
          > > method drawRect: 10,10 to: 20,20
          > > method drawRect: 10,10 width: 10,10
          > >
          > > Would invoke two different methods.
          >
          > That doesn't look like multimethods to me. Multimethods means
          > that what method gets invoked to field a given message can depend
          > on the (dynamic) types of more than one of the arguments.
          > In your example above, the arguments are all number pairs, and
          > the selectors differ.
        • Brian T Rice
          This is why it pays to learn from the past, i.e. Smalltalk. The method is the implementation of a behavior. The selector is the name of the method or message;
          Message 4 of 6 , Nov 3, 2002
            This is why it pays to learn from the past, i.e. Smalltalk. The method is
            the implementation of a behavior. The selector is the name of the method
            or message; it's usually a symbol such as #drawLineFrom:to: which is one
            symbol with a separate identity from the methods that are named with it
            and the messages that use it to find a method on the receiver(s). Messages
            are the dynamically-created objects (usually they don't exist as separate
            objects except in a debugging context), and dispatch is what selects a
            method to implement a message-send and return a result.

            --
            Brian T. Rice
            LOGOS Research and Development
            mailto:water@...
            http://tunes.org/~water/

            On Sun, 3 Nov 2002, Mike wrote:

            > Sorry, I don't code by profession so my terminology is a bit off. My
            > latest ideas on syntax revolve around method signatures
            > i.e. 'drawLine' instead of 'drawLine:to:', and keyword messages.
            >
            > drawLine = { from: x1y1, to: x2y2, ... }
            > drawLine from: 10,10 to: 20,20
            >
            > By using optional keywords, I can translate this into:
            > v
            > drawLine :10,10 to: 20,20
            > v
            > drawLine: 10,10 to: 20,20
            > or
            > drawLine: 10,10 : 20,20 if you wanted.
            >
            > Just my thoughts.
          • Jack Waugh
            I didn t mean to beat you into silence. I m curious about what you are actually asking. It looks as though you are suggesting a notation involving something
            Message 5 of 6 , Nov 5, 2002
              I didn't mean to beat you into silence. I'm curious about what you
              are actually asking. It looks as though you are suggesting a
              notation involving something like:

              message-send ::= receiver verb argument-package.
              receiver ::= exp.
              verb ::= ID.
              argument-package ::=
              composed-argument-package
              | encapsulated-argument-package.
              encapsulated-argument-package ::= exp.
              composed-argument-package ::= {keyword argument}*.
              keyword ::= ID ":".
              argument ::= exp.

              I used the grameme "argument-package" for what you called
              the "message".

              The receiver expression evaluates to a reference to some object, the
              receiver. The dispatch mechanism uses the receiver and the verb as
              keys to look up a method. The system executes the method, passing
              the argument-package as an argument. The method can ask the argument-
              package for the argument associated to any keyword inside the
              argument-package. Is this what you are getting at?
            • Mike
              Hahah! No you didn t beat me into silence :) I was just busy tweaking the syntax. I changed my idea a little, so that there are true messages sent, i.e.
              Message 6 of 6 , Nov 5, 2002
                Hahah! No you didn't beat me into silence :) I was just busy
                tweaking the syntax. I changed my idea a little, so that there are
                true messages sent, i.e. 'do:1 to:10', but the method dispatcher only
                looks at the first keyword (do:). This allows me to use the same
                syntax for method invocation and variable assignment -- variable
                assignment, not 'slot' assignment -- like Io's <- operator.
                Assignment works simply by 'executing' an object. This has not been
                testest, so there might still be some ambiguity in more complex
                examples.

                drawLine is a Block, title is an String Object:

                win = Window clone
                win drawLine: 10
                -- send message 'drawLine:10' to win
                -- which does win.drawLine.execute(10)
                win title: 'hello'
                -- send message 'title:hello' to win
                -- which does win.title.execute(hello)
                x: 10
                -- send message 'title:hello' to local block
                -- which does block.x.execute(10)

                I assume position independent keywords would not be hard to
                impliment, and I could still do some tricks with ommited keywords
                such as:

                ` if: x > 10 do:
                could be
                ` if: x > 10:
                for a Pythonish, condensed syntax.

                Since the keyword is not given, it could assume it is the first
                argument.

                I also want to support conditional assignment such as:
                ` x = if: x > 10: 'hi' else: 'bye'

                Again, this is all hypothetical. Just thinking out loud. Thanks for
                your comments and suggestions!


                Regards,
                Mike

                --- In langsmiths@y..., "Jack Waugh" <waugh@a...> wrote:
                > I didn't mean to beat you into silence. I'm curious about what you
                > are actually asking. It looks as though you are suggesting a
                > notation involving something like:
                >
                > message-send ::= receiver verb argument-package.
                > receiver ::= exp.
                > verb ::= ID.
                > argument-package ::=
                > composed-argument-package
                > | encapsulated-argument-package.
                > encapsulated-argument-package ::= exp.
                > composed-argument-package ::= {keyword argument}*.
                > keyword ::= ID ":".
                > argument ::= exp.
                >
                > I used the grameme "argument-package" for what you called
                > the "message".
                >
                > The receiver expression evaluates to a reference to some object,
                the
                > receiver. The dispatch mechanism uses the receiver and the verb as
                > keys to look up a method. The system executes the method, passing
                > the argument-package as an argument. The method can ask the
                argument-
                > package for the argument associated to any keyword inside the
                > argument-package. Is this what you are getting at?
              Your message has been successfully submitted and would be delivered to recipients shortly.