Good to see you again, Igor. Would it make sense to define instVar initializers in the class object allowing the install of init forwarders in the object slots on VM for a Squeak-style implicitly typed dependency injection? Welcome.
--- robert > On Apr 1, 2016, at 19:48, Igor Stasenko <siguc...@gmail.com> wrote: > > Another approach would be to prefill the object with initial default values, > so that it has no any inconsistency right from its birth. Even if your next > statement has 99.9% chance to override these defaults, you eliminating this > 0.01% that causing nil errors. That, of course, raising another problem - > that you might be dealing with 'wrong' initial state, but it is much less > harmful than dealing with nils popping out of nowhere. > > >> On 2 April 2016 at 02:20, Igor Stasenko <siguc...@gmail.com> wrote: >> >> >>> On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nerga...@uia.no> wrote: >>> >Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late >>> >initialized objects. For example, imagine a Morph with height that is >>> >equal to >owner's height. In this case one would write in #initialize: >>> >>> >Initialize >>> >>> > self height: [ :morph | morph owner height ]. >>> >>> No. >>> >>> ownerChanged >>> >>> self height: owner height. >>> >>> ………….. >>> >>> One should not rely on the owner being set during initialization (90% of >>> the time at least), it makes morphs too reliant on certain cases, which >>> makes them harder to use/understand. >>> >>> If the morph must have an owner to operate properly, it loses many of its >>> abilities such as being its own root, for example to make images. >>> >>> ThatMorph new exportAsPng. >>> >> >> Amen. Simply avoid using objects in incomplete state to prevent errors like >> we see in this topic. That means, you should not mess with object's >> properties until it is fully initialized, that's what #initialize for. >> If you have coupling and chicken and egg problem like parent/child >> relationship - you shall again make sure nobody accessing that couple from >> outside while it is still in inconsistent state, and then once it is fully >> initialized - you don't need to guard against silly nil errors, because >> everything is set up. >> And in that couple, you can split things on stages, making sure that on >> initial stage, you again don't use/access not yet initialized properties. >> You need a plan, to be able to not put cart in front of the horse and that >> is much better than putting it that way and then trying to deal with it in a >> way like on-do-nothing pattern. >> >> Once again, one way or another - you don't need to use on-do-nothing, if you >> doing things right. And if you need it - then that indicates that you got a >> problem, and instead of solving and fixing it, you bury it under "catch-all >> and shut-up" gravestone :) >> >>> Best regards, >>> >>> Henrik >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko.
