On 2 April 2016 at 03:06, Robert Withers <robert.w.with...@gmail.com> wrote:

> 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.
>
> I would certainly recommend to construct objects prefilled with sane
defaults, especially taking advantage of having extra niceties from VM, and
especially when it about UI domain, where insane complexity knocking to
your doors right from the beginning.
But alas, due to inherent nature of UI that tends to be complex, often you
need to generate a whole subgraph of objects, and therefore you are limited
in choice: basically you have to carefully design a multi-stage
initialization procedure, sorting out all chickens and their eggs, before
giving things away for later use.
That is doable and once you define in your object soup who gonna make a
first move, you defining the order of initialization and consequently the
constraints of being able to access certain properties during partial
initialization or not.
Else, if you not define any constraints, and let things grow naturally,
sure you will end up using on-do-nothing more and more often, up to the
point that you find youself unable to initialize any object without taking
'advantage' provided by such pattern. :)


> ---
> 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.
>
>


-- 
Best regards,
Igor Stasenko.

Reply via email to