Lazy Loading (was: Re: [squeak-dev] The Trunk: MorphicExtras-cmm.131.mcz)

>> OK, I see what you mean. We do this kind of lazy loading in several
>> places. Every time I see it, I feel a strong ambivalence. On one hand,
>> it's really easy to write, and it's really convenient, but! (b) it's a
>> totally rubbish UX when you're offline. Click on something and
>
> But, if you're offline, you won't be able to load that package
> manually anyway.  One way or another, that function is unavavailable,
> period.
>
> So, what difference does it make _what_ error you get in that 1% case
> of being offline if, for the 99% case (on-line), no error is incurred
> at all?
>
>> suddenly random failures happen because omigosh you're not connected
>> to the internet.
>
> I know you still don't have it on the train but persistent internet
> connections are coming -- it's inevitable.  We should decide about the
> future in the context of the future.

> On 9 December 2013 21:18, Chris Muller <[hidden email]> wrote:
>>>>> I think lazy loading like this should be a last resort. Surely we can do better?
>>>>
>>>> Why should it be a last resort instead of a first resort?  What do you
>>>> propose for better?
>>>
>>> Well, I don't have a monopoly on good ideas :). But how about this: if it's that important that you go to the trouble of hooking in a lazy load, why not just load the package in eagerly?
>>
>> Because Nicolas wants to eliminate MorphicExtras static dependency on
>> UpdateStream, which is what started this thread.
>
> I don't want to eliminate only static dependencies. It's not that big
> a deal for MorphicExtras, because that's like icing on the gingerbread
> house: you can scrape it off with little more than cosmetic damage.
>
>> You contend lazy loading doesn't eliminate the dependency, it only
>> defers it until runtime.  That's true, but how else could the
>> _original_ behavior be met?  Nicolas proposed that it shouldn't
>> anyway:  Change the original behavior.
>
> Yep, and I'm glad he found a better way.
>
>> In this case, I agree with him.  System initialization of this sort
>> can be done myriad of ways -- we don't need lazy-loading for this
>> case.  But it is good to remember this is a tool in our toolbox toward
>> achieving the same goals as the modularity effort.  -- I think your
>> expression of it being an additional "dependency" on the Internet is
>> not true.
>
> How so? Well, making use of the package-cache or some other
> local-network cache would go a long way towards mitigating the
> problem. But the code's outside the image, and it has to come from
> _somewhere_.
>
>> Sometimes the modularization effort employs only "pure package
>> factoring" (preserving original behaviors).  Sometimes chopping out
>> behaviors to eliminate dependencies becomes necessary.  Ok, I
>> understand now why you "last resort" and I agree, but it _is_ useful
>> at times.
>
> I agree, it is useful. I suppose I'd object less to lazy loading being
> driven off a user action. The only example I can think off is how we
> load WebClient lazily when updating through the SqueakMap browser.
> There (a) it's driven directly off user input and (b) the nature of
> updating necessarily involves a network connection anyway, so lazy
> loading looks like a natural part of the flow.
>
> But imagine if we used lazy loading all over the place, and you could
> never be sure when things would or wouldn't require a network
> connection. As a user things would randomly fail with mysterious
> debugger windows popping up talking about primitive failures, and as a
> product developer you wouldn't be able to know in advance that you
> shipped the image with all necessary parts.