Sometimes quantity is quality. self ---- . Python . Smalltalk . Lua . Ruby . Rust . Legacy vimscript dict obj
this ---- . Dart . C++ . Java . C# . Php use $this-> Neither this or self, but instance.member ---- .Julia .Actionscript 3 . Fortran 90, 2003 Instance created by new ClassName/Object --------- . C++ . Dart . C# . Php . R . Actionscript 3 var obj:Object = new Object(); Instance:MyClass = MyClass ----- . Python . Julia ... Etc.. Le vendredi 23 décembre 2022 à 18:40:15 UTC+1, bfrg a écrit : > > 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/70cc2d07-72ad-479d-a772-f36b82367b70n%40googlegroups.com.
