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

Re: [self-interest] arguments and assignment

Expand Messages
  • Toby Everett
    ... Why is perform:With:With:With: no longer acceptable? Doesn t that really mean that with should receive an array of objects? And really mean that it
    Message 1 of 9 , Apr 30, 2001
    • 0 Attachment
      > Bad points: some keywords would have to be renamed so we wouldn't have
      > arguments named 'on' and so forth. In particular,
      > 'perform:With:With:With:' would no longer be acceptable. This would
      > complicate the set of 'value:With:With:' messages for blocks. It would
      > also be easier to end up with an argument with the same name as an
      > object's slot, though that shouldn't be hard to spot.
      Why is perform:With:With:With: no longer acceptable? Doesn't that really mean
      that with should receive an array of objects? And really mean that it should
      be possible to say perform:[With]:, which would be interpreted by the system
      to automatically match perform:With: and perform:With:With: and
      perform:With:With:With: and so forth, with all of them getting assigned to
      the array with?

      ObDisclaimer: I haven't coded in Self since I left college in '96 and I've
      never coded in Smalltalk (but I did read Beck's Patterns book all the way
      through just for fun), so if this doesn't make sense, I apologize in advance.

      --Toby Everett
    • Steve Dekorte
      ... That sounds like a good idea to me. One of the common problems with keyword argument lists is handling variable number of arguments. Your scheme takes care
      Message 2 of 9 , May 1 1:42 PM
      • 0 Attachment
        Toby Everett wrote:
        > Why is perform:With:With:With: no longer acceptable? Doesn't that
        > really mean
        > that with should receive an array of objects? And really mean that it
        > should
        > be possible to say perform:[With]:, which would be interpreted by the
        > system
        > to automatically match perform:With: and perform:With:With: and
        > perform:With:With:With: and so forth, with all of them getting assigned
        > to
        > the array with?

        That sounds like a good idea to me. One of the common problems with
        keyword argument lists is handling variable number of arguments. Your
        scheme takes care of that. Lua uses a similar mechanism but does so but
        default on all functions. If you pass in more arguments than the
        function has declared argument variables for, it put the extras into a
        "args" array. This makes implementing message forwarding a lot simpler.
        It's also helpful to have a way to call a method with a list of
        arguments.

        Steve
      • Jecel Assumpcao Jr
        ... Well, my proposal was to generate argument names automatically from the keyword parts, so they would have to be all different.
        Message 3 of 9 , May 1 2:20 PM
        • 0 Attachment
          On Tuesday 01 May 2001 02:27, Toby Everett wrote:
          > Why is perform:With:With:With: no longer acceptable?

          Well, my proposal was to generate argument names automatically from the
          keyword parts, so they would have to be all different.
          'performSelector:Arg1:Arg2:Arg3:' would work, though I wanted to avoid
          such unimaginative names.

          > Doesn't that
          > really mean that with should receive an array of objects? And really
          > mean that it should be possible to say perform:[With]:, which would
          > be interpreted by the system to automatically match perform:With: and
          > perform:With:With: and perform:With:With:With: and so forth, with all
          > of them getting assigned to the array with?

          That would be interesting. Self doesn't have a syntax for array
          literals, so you have to write

          ( 1 & 3 & 9 & 11 ) asVector

          where in Smalltalk you would have

          #(1 3 9 11)

          and so we have methods with different selectors for small numbers of
          arguments. Some Smalltalks have a different syntax for when you need an
          array of generic expressions instead of literals. I thought we also had
          one more selector in Self for accepting an array of arguments, but it
          seems we don't. You can send at most 5 arguments to a block, for
          example, and have at most 2 arguments with the perform primitive.

          Anyway, I looked through the list of 1600 unique argument names (out of
          a total of 22,000 argument slots) and don't think my idea would cause
          any great hardship (if you don't consider incompatibility with what we
          have now as such).

          -- Jecel
        • Dru Nelson
          Yes, Perl and Python do this as well.
          Message 4 of 9 , May 2 10:14 AM
          • 0 Attachment
            Yes, Perl and Python do this as well.

            > That sounds like a good idea to me. One of the common problems with
            > keyword argument lists is handling variable number of arguments. Your
            > scheme takes care of that. Lua uses a similar mechanism but does so but
            > default on all functions. If you pass in more arguments than the
            > function has declared argument variables for, it put the extras into a
            > "args" array. This makes implementing message forwarding a lot simpler.
            > It's also helpful to have a way to call a method with a list of
            > arguments.
            >
            > Steve
            >
            >
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >
            >
            >
          • Steve Dekorte
            ... Right, I thought Lua was different in that variable arg lists didn t have to be declared. But I checked the manual and they do need to be declared.
            Message 5 of 9 , May 2 12:45 PM
            • 0 Attachment
              Dru Nelson wrote:
              > Yes, Perl and Python do this as well.

              Right, I thought Lua was different in that variable arg lists didn't
              have to be declared. But I checked the manual and they do need to be
              declared.

              Proposed Self: ...f:arg1 [With:]
              Lua: function foo(arg1, arg2, ...) ... end
              Python: def foo(arg1,arg2,*args,**keywordAgs):
              Perl: ?
              Ruby: def foo(*args) ... end

              Steve
            • Dru Nelson
              Perl has a hidden variable that lets you access the args for that activation. Neat, but can be dangerous in the wrong hands.. Dru Nelson San Mateo, California
              Message 6 of 9 , May 2 2:41 PM
              • 0 Attachment
                Perl has a hidden variable that lets you access
                the args for that activation.

                Neat, but can be dangerous in the wrong hands..

                Dru Nelson
                San Mateo, California


                On Wed, 2 May 2001, Steve Dekorte wrote:

                >
                > Dru Nelson wrote:
                > > Yes, Perl and Python do this as well.
                >
                > Right, I thought Lua was different in that variable arg lists didn't
                > have to be declared. But I checked the manual and they do need to be
                > declared.
                >
                > Proposed Self: ...f:arg1 [With:]
                > Lua: function foo(arg1, arg2, ...) ... end
                > Python: def foo(arg1,arg2,*args,**keywordAgs):
                > Perl: ?
                > Ruby: def foo(*args) ... end
                >
                > Steve
                >
                >
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
                >
                >
              • Toby Everett
                ... Perl also supports prototypes, which allows the subroutine to define what sorts of things it expects, so as to allow the parser to make things behave
                Message 7 of 9 , May 2 8:53 PM
                • 0 Attachment
                  > Perl has a hidden variable that lets you access
                  > the args for that activation.
                  >
                  > Neat, but can be dangerous in the wrong hands..
                  Perl also supports prototypes, which allows the subroutine to "define" what
                  sorts of things it expects, so as to allow the parser to make things behave
                  more like the builtins.

                  For instance, the built-in "grep" can take a subroutine as an argument, as in:

                  @foo = grep {$_ > 20} @bar;

                  Which assigns into the array @foo all those elements of @bar which are greater
                  than 20 (the $_ is a "default" variable).

                  If I wrote my own grep, mygrep, without prototypes, it would have to be
                  called like this:

                  @foo = mygrep sub {$_ > 20}, @bar;

                  The sub {} indicates that it's a subroutine (otherwise it would normally be an
                  anonymous hash constructor:).

                  But if you write the proper prototype for the mygrep subroutine, it too can
                  behave just like the built-in grep.


                  Getting back to the original issue, though, it strikes me as ugly that Self
                  has to have multiple definitions for perform. They're all the same thing, and
                  it just _feels_ ugly to have multiple definitions. Like there's something
                  wrong with the language.

                  As an analog, I'm guessing that no-one has much Visio experience, but Visio is
                  an incredibly cool drawing program. Not the Visio 90% of people use, but the
                  Visio just under the skin. Every shape in Visio is the result of a
                  "ShapeSheet" - a sort of spreadsheet. Every vertex on the shape is, by
                  default, assigned to Width*x and Height*y, where x and y lie between 0 and 1,
                  and the coordinates are in a shifted reference frame that is relative to the
                  shapes location and rotation. But that's all changeable - just go into the
                  ShapeSheet and change the formula. The result is a "programable" shape. It's
                  an _incredibly_ powerful concept that lets people create intelligent shapes
                  very easily. The achilles heel, however, is that it has no "looping"
                  construct. So developers of shapes that by their nature have "n" elements
                  frequently pick some specific number of maximum elements and hand-code the
                  rest. Say I wanted to implement a polygon shape - it would have a
                  user-defined property that specified the number of sides, and it would
                  generate a regular polygon. I would pick, say, 20 as the maximum number of
                  sides. The resultant shape would have 20 vertexes, but when n was less than
                  20, I would simply stack all the unused vertexes over one vertex. Ugly, ugly,
                  ugly, ugly. Looping should have been built into the ShapeSheet structure from
                  the beginning (and I've even come up with a proposal for how it would be done
                  - it would not be that difficult). But they didn't, and everytime I'm faced
                  with that sort of situation I cringe and copy and paste.

                  OK, that was probably way off track. But it is very similar to the perform
                  situation.

                  --Toby Everett
                • Tripp Lilley
                  ... Framer-D has a similar situation. In the C implementation of its call primitive, it has a switch statement based on the number of arguments, with a
                  Message 8 of 9 , May 2 10:16 PM
                  • 0 Attachment
                    On Wed, 2 May 2001, Toby Everett wrote:

                    > OK, that was probably way off track. But it is very similar to the perform
                    > situation.

                    Framer-D has a similar situation. In the C implementation of its "call"
                    primitive, it has a switch statement based on the number of arguments,
                    with a hardcoded maximum somewhere around 9 or 10. Sigh. :) That's on my
                    personal list of things to "fix" when I have the time.

                    --
                    Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
                    --------------------------------------------------------------------------
                    "If people would stop behaving like greedy idiots, I'd be sweetness
                    and light every fucking day." - Dave Winer, Scripting News, 2001-04-11
                  Your message has been successfully submitted and would be delivered to recipients shortly.