On Fri, Mar 24, 2017 at 10:52:23PM +0100, Levente Uzonyi wrote:
> Another con is that it makes it harder, sometimes way harder, to find 
> references to a given variable.
> 
> Levente

I agree. I used to think that it was a good idea to use accessors whenever
possible. Now, I am embarrassed by code written in that style, and I try
to clean up the unnecessary use of accessors. The result is easier to read,
easier to search for references, and easier to understand because I do not
need to wonder if there may be side effects of an accessor that e.g. may
or may not do lazy initialization.

Enforced use of accessor methods is one of those things that sounds like
it should be a good idea, but in practice it is not so great.

Dave


> 
> 
> On Fri, 24 Mar 2017, tim Rowledge wrote:
> 
> >
> >>On 24-03-2017, at 12:56 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >>
> >>All instvars should be required to have accessors; I don't want see any 
> >>code that accesses instvars directly _execpt_ accessors???
> >
> >Well, there???s pro???s and con???s for that.
> >
> >Pro 
> >- nice regular feature; you always use a message and never an instvar 
> >reference (except some variety of magic to allow the one and only accessor 
> >to work) and then maybe you could remove all the ivar accessing bytecodes 
> >too. With a naive implementation you can do
> >       ^foo ifNil:[foo := MyClass makeFoo]
> >type lazy initialisation easily. Obviously a little more involved if you 
> >go the Self route, but equally obviously, doable since they already did it.
> >
> >Con 
> >- almost certainly slower and particularly so for a version with a lazy 
> >init since that will always get checked. Potentially fixable with Sista 
> >tricks.
> >- makes it far too easy and inviting to write truly appalling code. For 
> >example, how often do we see less experienced people write code that might 
> >as well be C?
> >e.g.
> >testval := (dog legs first paw claws) at: 2.
> >testval type = #cutRecently ifTrue:[ ((dog legs first paw claws) at: 2) 
> >type: #buffedAndPolished].
> >
> >Which is an example of massive violation of encapsulation, dreadful design 
> >integrity, poor maintainability, and general awfulness. Worse, it???s a 
> >very common pattern.
> >
> >Now certainly simply having ivar accessors is not the sole and complete 
> >cause of such horrors but it certainly makes it very inviting. If - big if 
> >- we could make such accessors actually private then there might be a 
> >better argument for them. 
> >I???m sure we could come up with something that might work if we really 
> >want to; in fact how about this rough concept (which I dare say is already 
> >extant in someone???s PhD thesis somewhen)
> >
> >Use of ivar name in code is treated as now - it access that object within 
> >???self??? BUT if the value is nil it diverts (like ifTrue: does for 
> >non-booleans) to a method named something vaguely intuitable like 
> >#initialiseIVar{name}. If no such method exists then the accessor is as 
> >before - with obvious costs similar to cache-flushing any time one is 
> >added or deleted or otherwise relevantly changed.
> >
> >This would keep the ivar name a private thing to the class (just as now) 
> >unless someone specifically wanted to provide it as a public accessor. 
> >Writing code that refers to iVar would work exactly as now.  Adding 
> >#initialiseIVar would cause recompiling of all methods using the 
> >applicable bytecode(s) to use some other bytecode(s) that test and send 
> >#initialiseIVar when required. Deleting it would do the obvious.
> >
> >tim
> >--
> >tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> >The problem with the gene pool is that there is no lifeguard.

>