> No, I prefer 'this' over 'self'. I was considering if its possible to go without any keyword for it. For example, these days we also have syntax highlighting which can give a different color for member variables and arguments.
In order to give different colors for member variables and function arguments you need a very sophisticated parser. Otherwise you cannot distinguish the two in code. For the same reason C++ developers often prefix member variables with `m_`, like `m_age`, others use a postfix underscore like `age_` etc. I don't like it because it's not consistent. Personally, I would prefer `this` (or `self` etc.) for member variables. It makes the syntax script a lot simpler and the syntax highlighting will work 100%. It will also be easier to `:grep` for all usages of a member variable since every reference of a member variable will contain `this`. On Monday, December 19, 2022 at 4:12:37 PM UTC+1 ch...@createng.com wrote: > On Tuesday, 20 December 2022 at 01:26:15 UTC+11 Bram Moolenaar wrote: > >> >> > I'm not a big fan of the "this" keyword. I agree if going to use it, >> > ensure to use it everywhere. Consistency is good. I like simplicity, >> and >> > dislike redundancy. >> >> What do you mean, do you prefer "self"? >> > > No, I prefer 'this' over 'self'. I was considering if its possible to go > without any keyword for it. For example, these days we also have syntax > highlighting which can give a different color for member variables and > arguments. > > >> > So, about "this", alternatively, don't use it anywhere, but maybe you >> > could throw an error if a function argument name is also member >> variable >> > name. >> >> That is actually very common. It is very likely that methods pass >> arguments to set or modify the object members, thus using the same name >> is very likely to happen. > > > Yes, it is common, and it is a source of confusion & errors - especially > when its not referring to the same thing. Thats my point. It seems like > it would be better practice to use different names for different context, > especially when those contexts overlap in scope. > > >> > OR, perhaps another option, just thinking outside the box, if a >> function >> > argument does actually happen to match a member variable name - then >> > automatically force it to actually set that variable. When (if) this >> > becomes the expected behavior, I think it would enable simplifying some >> > things a lot. >> >> Boundary checks are often done on arguments, assuming that the argument >> is always assigned to an object member is too limiting. >> > > To be clear, I didn't mean that every argument is always assigned to an > object member, I only meant assign it when it has the same name... I think > you understood anyay, but just in case I was ambiguous. > > But, yes, I see that it could be restrictive. Still, really, if you are > using the same name to mean something different, then that is also a > potential pitfall. > > > >> I also want to avoid doing things very differently from what existing >> languages are doing. Some different syntax and rules can be acceptable, >> but introducing new mechanisms that are hard to understand are to be >> avoided. >> > > It is unusual, I agree. I've never seen it done like that in any modern > major language. It reminds me of some languages that don't really use > scope very well, where ALL of the variable names were pretty much scoped to > the whole class, no matter where they were declared in that class. I can't > recall what language I saw that in, that was over 20 years ago. > > >> > class Blahh >> > this.toX: TYPE_A >> > this.toY: TYPE_B >> > fn SetXandY(toX: TPYE_A, toY: TYPE_B ) >> > this.toX = toX >> > this.toY = toY >> > enfunc >> > endclass >> > >> > So, I find that pattern happens a lot. And it gets real tedious. I >> > think this could be simplified to the following; >> > >> > class Blahh >> > toX: TYPE_A >> > toY: TYPE_B >> > fn SetXandY(toX, toY) >> > enfunc >> > endclass >> > >> > ie. This would set the member variables, toX and toY automatically. >> >> I don't know any language that does this and I find it very obscure and >> confusing. Also, it makes giving useful errors difficult. Using an >> argument name that happens to be a member name would not result in any >> error but silently turned into an assignment. > > > Yeah, it could be confusing to get used to it. But, there would not need > to be any error messages, because it wouldn't be an error. It would be a > feature. And, once you got used to it, you'd realise it solves a number of > problems. > > I take your point though. Considering it would behave different to > current paradigm of most popular languages, then users would get surprised > that they didn't get an error - because they were expecting something > different to happen. > > But, at the end of the day, "this" is a pragmatic choice, and I like your > idea of enforcing it everywhere such member variables are used. > > > > -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/12c8dafa-214d-4ce4-93e3-a36c59b94784n%40googlegroups.com.
