Object>>className
Locked
 
|
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > >The problem with the gene pool is that there is no lifeguard. > |
|
|
In reply to this post by Levente Uzonyi
I agree.
Cheers, Bernhard > Am 24.03.2017 um 19:36 schrieb Levente Uzonyi <[hidden email]>: > > On Fri, 24 Mar 2017, Tobias Pape wrote: > >> >>> On 24.03.2017, at 18:10, Eliot Miranda <[hidden email]> wrote: >>> - doesn't provide much utility as it is effectively foo class name, and foo className saves one character. >> >> Law of Demeter. > > Blindly applying such ideas will result in a huge mess. In this case #className and #name cause more trouble than benefit. Object should shadow as few accessors as possible. > > Levente > >> >> Best regards >> -Tobias |
|
|
In reply to this post by Levente Uzonyi
Am 24.03.2017 um 12:21 schrieb Levente Uzonyi <[hidden email]>:
> > On Fri, 24 Mar 2017, Tobias Pape wrote: > >> >>> On 24.03.2017, at 01:17, tim Rowledge <[hidden email]> wrote: >>>> On 23-03-2017, at 3:10 PM, Chris Muller <[hidden email]> wrote: >>>> I would rather get rid of "create inst var accessors" altogether, then >>>> you would not have that problem. :) >>> If I could think of a way of getting away with it I’d make it completely impossible to make methods with the same name as an ivar. All it does is encourage the sort of scoundrels ( cads! bounders! mountebanks I tell you!) that treat classes as Pascal records or C structs. Didn’tortabealloweditellya. >> >> I'd rather have the opposite direction. >> All instvars should be required to have accessors; I don't want see any code that accesses instvars directly _execpt_ accessors… > > Why would that be any good? > If it is a good idea, then what are instance variables good for? Cheers, Bernhard |
|
|
(from 1960-66--Early OOP and other formative ideas of the sixties, Section I) What I got from Simula was that you could now replace bindings and assignment with goals. The last thing you wanted any programmer to do is mess with internal state even if presented figuratively. Instead, the objects should be presented as site of higher level behaviors more appropriate for use as dynamic components. (...) It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs. Many programs are loaded with "assignment-style" operations now done by more expensive attached procedures. ... Assignment statements--even abstract ones--express very low-level goals, and more of them will be needed to get anything done. Generally, we don't want the programmer to be messing around with state, whether simulated or not.... The basic idea (influenced by Sketchpad) is that most variables/values are in dynamic -relationships- with each other (maintained by the interior of the object), so being able to directly reset a value from the outside is dangerous. Because (in Smalltalk anyway) there is at least a setter method required, this allows the possibility of an outside setting action to be mediated by the internal method to maintain the desired interrelationships. But most people who use setters simply use them to simulate direct assignments to interior variables, and this violates the spirit and intent of real OOP. But objects do have "world lines" of changes in time. This can be thought of as a -history- of versions of the object in which the -relationships- are in accord. There are no race conditions in this scheme ... an object is only visible when it is stable and no longer computing. This is like a two phase clock in HW. (Idea from Strachey, and in a different from by McCarthy, and influenced by Lucid.) Best wishes, Alan Kay From me: I've seen state stored in some really crazy ways, processing done, and intermediate state stored in ways that were really inefficient. If the internal state of objects is sufficiently isolated you could fix all of that without having to worry that some object somewhere else is relying on the fact that you created temp storage for processing. You could change your internal state and remove the horrible string and parser you developed without worrying that some other object is also parsing that horrible string. It makes much more sense to define what messages an object needs to process, questions that the Object needs to answer or processing it needs to do, if you answer all the questions properly and process the data properly, no other object should care how you arrived at that answer. An accessor or mutator is useful if that is part of the external definition or to help maintain proper processing and state but they should not be added or used otherwise. When you have access to an object and you are looking at the instance variables of the object, it makes more sense to add a method that answers your questions about that object. It helps others understand what you are doing, what state you are examining, how you are using the object. It means that if someone needs to remove that instance variable later they can do that by properly responding to your method using the new method. One other benefit of doing things this way is that there may already be a method that does what you need, and reading through the interface of the object might stop you from processing the same answer in a different way. (something that will come back and bite you later if the answer has new dependencies but your answer or direct access to ivars doesn't take that into account). All the best, Ron Teitelbaum On Sun, Mar 26, 2017 at 3:33 PM Bernhard Pieber <[hidden email]> wrote: Am 24.03.2017 um 12:21 schrieb Levente Uzonyi <[hidden email]>: |
| Free forum by Nabble | Edit this page |