On 09-Feb-16, tyru wrote:
> On Mon, Feb 8, 2016 at 6:48 PM, Bram Moolenaar <[email protected]> wrote:
> >
> > [adjusted the subject, it was "Why is v:none needed"]
> >
> > Takuya Fujiwara wrote:
> >
> >> > [...]
> >> >
> >> > > >> let json = jsonencode({"key": v:none})
> >> > > >> if json is v:none
> >> > > >> echoerr 'error!'
> >> > > >> return ...
> >> > > >> endif
> >> > > >
> >> > > > Well, let's just return an empty string. Returning a different type
> >> > > > often makes it more complicated.
> >> > >
> >> > > I agree.
> >> > > However, I think "E706: Variable type mismatch" should be removed
> >> > > becase it is not so useful for me...
> >> >
> >> > Where do you get that? Or do you mean that the sticky type checking
> >> > isn't all that useful in general? I've been wondering whether we would
> >> > be better off without it.
> >>
> >> I don't think it is useful in lightweight languages
> >> (I don't think *only* a strict type checking is useful).
> >> A strict type checking is useful for a language which has a strong type
> >> system.
> >> Because we can detect errors by different types, and so on.
> >
> > At the time it seemed like a good idea, to have some type checking to
> > avoid mistakes. Over time I can't say this has uncovered a problem. I
> > did run into the error when I didn't want it. Currently I think we
> > might be better off without it.
> >
> > So, let's ask: who finds the sticky type checking useful?
>
> +1.
>
> I'll show a example here, why we might be better off a sticky type checking.
>
> for i in ['foo', 'bar', {'key': 'baz'}]
> echo string(i)
> endfor
>
> Will output:
>
> 'foo'
> 'bar'
> E706: Variable type mismatch for: i
>
> We need 'unlet i'.
> It is easy to miss it...
>
> for i in ['foo', 'bar', {'key': 'baz'}]
> echo string(i)
>
> " If you :continue here, you need to :unlet in the condition, too...
> if ...
> unlet i
> continue
> endif
>
> " We need this always!
> unlet i
> endfor
+1 for these, they are somewhat a nuisance.
OTOH, sticky type checking has found problems for me, e.g. when I
changed the way a list was created, sticky type checking pointed to the
places where I forgot to update code that uses the list.
Generally, I believe type checking is more useful in low level
languages, where type mismatches are very likely to have real, even
catastrophic bugs as consequences.
In script languages I tend to prefer it when the language and script
functions do something "sensible" for each data type, including
automatic data type conversion. Errors can be found more easily through
testing.
Script languages typically avoid catastrophic errors such as
segfaults, and they are interpreted, so no setup time is required
for every test. So testing each change quickly is a much more
viable option than for low level languages.
That being said, I more or less often need a mechanism that finds all
uses of some data structure, including when used through aliases. This
helps to find all code that must be adapted after changing the
definition of a data structure. This could be done during tests by
injecting a wrong data type into a data structure and then looking for
errors, or by locking the changed data item in the structure (if that
works consistently).
So IMHO one alternative for sticky types is consistent locks.
--
Olaf Dabrunz (oda <at> fctrace.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 [email protected].
For more options, visit https://groups.google.com/d/optout.
