[cc-ing Laszlo-dev, in case there are better memories out there than mine. Surely there are.]
On 2011-03-22, at 09:33, Lou Iorio wrote: > In the Views tutorial, section 2.2 Operations in constraints > http://labs.openlaszlo.org/trunk-nightly/docs/developers/tutorials/views-tutorial.html#d0e6412 > <http://labs.openlaszlo.org/trunk-nightly/docs/developers/tutorials/views-tutorial.html#d0e6412> > In the paragraph following the last example, we have this gem: > > In the above example we are using two methods of referencing properties of a > view. For example, we use this.width and this.width. They are different, and > there are specific situations when you can and can't use the this.width > syntax. In short, this.width can only be used in constraints. > > I don't understand the point the author is trying to make. Can you clarify? Me either. It looks like either a transcription error or a global search and replace gone wrong. Perhaps you can use 'svn blame' to see who last touched this and why. Otherwise I would delete it, as it currently reads like gibberish. It's possible that the code used to say just `width` in the constraint and `this.width` in the onclick method. Waaaay back in the day, only constraints had the feature called 'implicit this', which is what Don has been working on extending everywhere. Later, but still a long time ago, we decided that stylistically we didn't want to encourage users leaving off the `this.`, especially on the left-hand side of an assignment, that we wanted them to always write it out longhand. With Don's changes, it becomes less important, so going forward it is really a matter of personal preference. Personally, I've not established a clear style, as you can see from my code. Sometimes I think it is clearer to explicitly say `this.`, to make it obvious that I am referring to an instance var, rather than a global or local var; but other times, particularly in complex code, `this.` becomes just a lot of extra noise and actually makes the code harder to read. I don't think you can give a hard and fast rule. In any case, it is a general issue of O-O programming, not something peculiar to LZX.
