On Apr 21, 2017 11:23 AM, "Bert Freudenberg" <bert at freudenbergs.de> wrote:

On Thu, Apr 20, 2017 at 11:29 PM, Chris Cunningham <cunningham.cb at gmail.com>
wrote:

>
> On Thu, Apr 20, 2017 at 9:32 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> <snip/>
>
>> Yeah, isn't it fun to untangle a monolithic system? ;)
>>
> Not bad if you don't try and change things...
>
>>
>>
> <snip/>
>
>> Anything else lying around?
>>>
>>
>> There is also the stuff with hasNonStandardPalette and convertARGB etc
>> which is only used if there are external forms, but that seems a bit harder
>> to remove because the hooks need to be there. I think it's fine to leave
>> that as it is, unless you notice something that's easily removable.
>>
>> There is a new version in the inbox with those 4 method moved.
> The rest are doable.  THe right way to do them, I think, is to remove most
> of these methods completely from Form. Then, adjust the methods that call
> them (in Form) to do the standard form code; and have override varients in
> ExternalForm (and/or ExternalScreen) that does the very specific alternates
> - or delegates to Form if it should.  Those dependant methods seem to have
> a lot of assumptions about what the other variants might be.
>
> I might get to this next week at some point, but I won't promise anything.
>

I think we should leave this as is. The hooks need to stay in place if we
still want to support external forms.

We might want to amend the comment in #hasNonStandardPalette with some
mention of the new external graphics package.

 - Bert -


I became interested in this because a test failed, so I can stop when it is
deemed right to do so. That said:

The current methods calling the methods you mention will look very weird
without the ExternalForm loaded. There are branches that make no sense with
that package removed. I did 3+ years from now if someone needs to work on
Form and especially those methods they might be tempted to just remove them
and then we are much worse off.

What I'm suggesting is to factor out ExternalForm versions of those methods
into ExternalForm and ExternalScreen where they will make sense to someone
looking over it in the future. In the process the methods in Form should
also get simple and more understandable (although there is a lot of but
twiddling left in them).  As a bonus I would leave a note in the Form
comment about the existence of ExternalForm in case someone was looking for
such a thing.

Yes this approach can also for over time - but at least ExternalForm will
be consistent with itself.  And it might not for as fast asvleaving the
mixed methods in there now. The only good way not to for is to put the
classes back in, really.

Thanks,
cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170421/820c07ce/attachment.html>