[squeak-dev] Object>>className

Levente Uzonyi leves at caesar.elte.hu
Fri Mar 24 21:52:23 UTC 2017


Another con is that it makes it harder, sometimes way harder, to find 
references to a given variable.

Levente


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.


More information about the Squeak-dev mailing list