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/a5d88361-2326-4f36-9e68-ac50fd03b8f0n%40googlegroups.com.
