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

function dict['/foo']() fails

Expand Messages
  • thinca
    Hi list. Please see the following code. ... let dict = {} function dict[ /foo ]() endfunction = E475: Invalid argument: /foo function dict[ foo ]()
    Message 1 of 11 , Jun 17, 2013
    • 0 Attachment
      Hi list.

      Please see the following code.
      ----------
      let dict = {}

      function dict['/foo']()
      endfunction
      " => E475: Invalid argument: /foo

      function dict['foo']()
      endfunction
      " OK.

      let dict['/foo'] = function('tr')
      function! dict['/foo']()
      endfunction
      " Overwrite is OK

      call dict['/foo']() " OK.
      ----------

      I also expect ":function dict['/foo']()" to be ok.
      I write a patch and test for this.

      https://gist.github.com/thinca/5797391

      However, I am not confident for this patch.
      Please check it.

      Regards.
      --
      thinca <thinca@...>

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... I do not like the idea of accessing functions with arbitrary names. I would rather also disallow: let dict[ /foo ] = function( tr ) Would that break any
      Message 2 of 11 , Jun 17, 2013
      • 0 Attachment
        Thinca wrote:

        > Hi list.
        >
        > Please see the following code.
        > ----------
        > let dict = {}
        >
        > function dict['/foo']()
        > endfunction
        > " => E475: Invalid argument: /foo
        >
        > function dict['foo']()
        > endfunction
        > " OK.
        >
        > let dict['/foo'] = function('tr')
        > function! dict['/foo']()
        > endfunction
        > " Overwrite is OK
        >
        > call dict['/foo']() " OK.
        > ----------
        >
        > I also expect ":function dict['/foo']()" to be ok.
        > I write a patch and test for this.
        >
        > https://gist.github.com/thinca/5797391
        >
        > However, I am not confident for this patch.
        > Please check it.

        I do not like the idea of accessing functions with arbitrary names.

        I would rather also disallow:

        let dict['/foo'] = function('tr')

        Would that break any plugin?


        --
        "Women marry men hoping they will change. Men marry women hoping
        they will not. So each is inevitably disappointed."
        - Einstein

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • mattn
        ... I use already this syntax with my own plugins. The keys allows any strings. In javascript, it is allowed. I don t understand why you don t like this
        Message 3 of 11 , Jun 17, 2013
        • 0 Attachment
          On Tuesday, June 18, 2013 4:34:00 AM UTC+9, Bram Moolenaar wrote:
          > Thinca wrote:
          > I do not like the idea of accessing functions with arbitrary names.
          > I would rather also disallow:
          > let dict['/foo'] = function('tr')
          > Would that break any plugin?

          I use already this syntax with my own plugins.
          The keys allows any strings.

          In javascript, it is allowed. I don't understand why you don't like this syntax.

          - Yasuhiro Matsumoto

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • thinca
          ... I also use this syntax. This syntax is useful, for example, Sinatra like framework: function! s:get[ / ]() return hello endfunction function!
          Message 4 of 11 , Jun 19, 2013
          • 0 Attachment
            2013/6/18 Bram Moolenaar <Bram@...>:
            > I do not like the idea of accessing functions with arbitrary names.
            >
            > I would rather also disallow:
            >
            > let dict['/foo'] = function('tr')
            >
            > Would that break any plugin?

            I also use this syntax.

            This syntax is useful, for example,

            Sinatra like framework:
            function! s:get['/']()
            return 'hello'
            endfunction
            function! s:get['/user/:name'](name)
            return 'hello ' . a:name
            endfunction

            Another example: Rspec style testing framework:
            function! s:it['should be true']()
            call s:assert(1 + 1 == 2)
            endfunction

            Please rethink.

            --
            thinca <thinca@...>

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Ben Fritz
            ... I think of it as accessing a dict element with an arbitrary name not accessing a function with an arbitrary name . It just happens that the dict element
            Message 5 of 11 , Jun 19, 2013
            • 0 Attachment
              On Monday, June 17, 2013 2:34:00 PM UTC-5, Bram Moolenaar wrote:
              >
              > I do not like the idea of accessing functions with arbitrary names.
              >
              > I would rather also disallow:
              >
              > let dict['/foo'] = function('tr')
              >
              > Would that break any plugin?
              >

              I think of it as "accessing a dict element with an arbitrary name" not "accessing a function with an arbitrary name".

              It just happens that the dict element holds a function reference instead of "normal" data.

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Ben Fritz
              ... Hi, Bram! I saw in your recent todo.txt update that you still have a note about possibly removing this functionality. Consider the following use case based
              Message 6 of 11 , Jun 25, 2013
              • 0 Attachment
                On Monday, June 17, 2013 2:34:00 PM UTC-5, Bram Moolenaar wrote:
                >
                > I do not like the idea of accessing functions with arbitrary names.
                >
                > I would rather also disallow:
                >
                > let dict['/foo'] = function('tr')
                >
                > Would that break any plugin?
                >

                Hi, Bram! I saw in your recent todo.txt update that you still have a note about possibly removing this functionality.

                Consider the following use case based on a real need I had once:

                A communication protocol has 2-byte IDs for commands. Each command identified by this 2-byte ID has potentially different command lengths and meaning of the remaining bytes in the message.

                I want to parse a capture file containing a hex representation of this communication protocol. In real life, I would probably do this using Perl so others on my team can use it, but I *could* do it in Vim.

                So, I create a Dict in vim with key strings corresponding to the hex value of the command IDs, e.g. "12AE". I assign each key a function reference to be used to parse the rest of that particular message.

                Note that "12AE" is an invalid function name. But I want to be able to call a function corresponding to that name in a lookup table anyway.

                Now, "12AE" isn't too weird of a name. But the protocol could be based on ASCII characters instead of byte values. Perhaps commands look like /command and data looks like [data]. Perhaps I want to be able to look up "/command" in the lookup table.

                I think allowing arbitrary dict keys to point to function references is a very useful feature. And it isn't confusing if you remember that you're storing a function reference in a Dict, not naming a function with a weird name. I think we should definitely keep the ability to assign a function reference to an arbitrary dict key. Furthermore, using this syntax:

                function dict['/foo']()
                endfunction

                allows doing this in a way that will not pollute the function namespace with extra functions that never get called directly.

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Ingo Karkat
                ... +1; Dictionaries use (arbitrary) strings as keys, and they can map to Funcrefs. Clean and simple. Though I haven t made use of this shorthand notation yet,
                Message 7 of 11 , Jun 25, 2013
                • 0 Attachment
                  On 25-Jun-2013 17:45 +0200, Ben Fritz wrote:

                  > On Monday, June 17, 2013 2:34:00 PM UTC-5, Bram Moolenaar wrote:
                  >>
                  >> I do not like the idea of accessing functions with arbitrary names.
                  >>
                  >> I would rather also disallow:
                  >>
                  >> let dict['/foo'] = function('tr')
                  >>
                  >> Would that break any plugin?
                  >>
                  >
                  > Hi, Bram! I saw in your recent todo.txt update that you still have a note about possibly removing this functionality.
                  >
                  > Consider the following use case based on a real need I had once:
                  >
                  > A communication protocol has 2-byte IDs for commands. Each command identified by this 2-byte ID has potentially different command lengths and meaning of the remaining bytes in the message.
                  >
                  > I want to parse a capture file containing a hex representation of this communication protocol. In real life, I would probably do this using Perl so others on my team can use it, but I *could* do it in Vim.
                  >
                  > So, I create a Dict in vim with key strings corresponding to the hex value of the command IDs, e.g. "12AE". I assign each key a function reference to be used to parse the rest of that particular message.
                  >
                  > Note that "12AE" is an invalid function name. But I want to be able to call a function corresponding to that name in a lookup table anyway.
                  >
                  > Now, "12AE" isn't too weird of a name. But the protocol could be based on ASCII characters instead of byte values. Perhaps commands look like /command and data looks like [data]. Perhaps I want to be able to look up "/command" in the lookup table.
                  >
                  > I think allowing arbitrary dict keys to point to function references is a very useful feature. And it isn't confusing if you remember that you're storing a function reference in a Dict, not naming a function with a weird name. I think we should definitely keep the ability to assign a function reference to an arbitrary dict key. Furthermore, using this syntax:
                  >
                  > function dict['/foo']()
                  > endfunction
                  >
                  > allows doing this in a way that will not pollute the function namespace with extra functions that never get called directly.

                  +1; Dictionaries use (arbitrary) strings as keys, and they can map to
                  Funcrefs. Clean and simple. Though I haven't made use of this shorthand
                  notation yet, it looks useful. (But I also agree that a "normal"
                  :function definition should still be bound to the existing rules.)

                  -- regards, ingo

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • Yasuhiro MATSUMOTO
                  +1 -- - Yasuhiro Matsumoto -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to.
                  Message 8 of 11 , Jun 25, 2013
                  • 0 Attachment
                    +1

                    --
                    - Yasuhiro Matsumoto

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • thinca
                    This item was removed from todo list.
                    Message 9 of 11 , Jul 8 9:40 AM
                    • 0 Attachment
                      This item was removed from todo list.

                      https://code.google.com/p/vim/source/diff?spec=svnad6996a23e3e63c5495cbb0d4c1447aed068b8c5&old=ceb5f21cda796051585afc665de66c8007f32064&r=ad6996a23e3e63c5495cbb0d4c1447aed068b8c5&format=unidiff&path=%2Fruntime%2Fdoc%2Ftodo.txt

                      Why?

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    • thinca
                      Resend: My post was removed from google groups... ... This item was removed from todo list.
                      Message 10 of 11 , Jul 8 6:38 PM
                      • 0 Attachment
                        Resend: My post was removed from google groups...

                        ----------
                        This item was removed from todo list.

                        https://code.google.com/p/vim/source/diff?spec=svnad6996a23e3e63c5495cbb0d4c1447aed068b8c5&old=ceb5f21cda796051585afc665de66c8007f32064&r=ad6996a23e3e63c5495cbb0d4c1447aed068b8c5&format=unidiff&path=%2Fruntime%2Fdoc%2Ftodo.txt

                        Why?
                        --
                        thinca <thinca@...>


                        2013/7/9 thinca <thinca@...>:
                        > This item was removed from todo list.
                        >
                        > https://code.google.com/p/vim/source/diff?spec=svnad6996a23e3e63c5495cbb0d4c1447aed068b8c5&old=ceb5f21cda796051585afc665de66c8007f32064&r=ad6996a23e3e63c5495cbb0d4c1447aed068b8c5&format=unidiff&path=%2Fruntime%2Fdoc%2Ftodo.txt
                        >
                        > Why?

                        --
                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php

                        ---
                        You received this message because you are subscribed to the Google Groups "vim_dev" group.
                        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                        For more options, visit https://groups.google.com/groups/opt_out.
                      • thinca
                        hi Bram, please response -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For
                        Message 11 of 11 , Aug 4, 2013
                        • 0 Attachment
                          hi Bram, please response

                          --
                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php

                          ---
                          You received this message because you are subscribed to the Google Groups "vim_dev" group.
                          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                          For more options, visit https://groups.google.com/groups/opt_out.
                        Your message has been successfully submitted and would be delivered to recipients shortly.