On Mon, Apr 24, 2017 at 8:20 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

> On Sat, Apr 22, 2017 at 3:49 AM, Chris Cunningham <cunningham.cb at gmail.com
> > wrote:
>
>>
>>
>> On Apr 21, 2017 11:23 AM, "Bert Freudenberg" <bert at freudenbergs.de>
>> wrote:
>>
>> 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.
>>
>
> Ah, I see what you mean. Basically the non-standard palette behavior would
> only be implemented in ExternalForm and ExternalScreen.
>
> This makes sense, except that it would lead to lots of code duplication.
> The closest common ancestor of ExternalForm and ExternalScreen is Form, and
> I'm certain that's why Andreas put the code for dealing with non-standard
> palette code in Form. (I guess nowadays this could be solved with a
> NonStandardPaletteTrait that would be used by both ExternalForm and
> ExternalScreen, but I'm not sure this is preferable to just leaving it in
> Form).
>
>
>> 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.
>>
>
> Wow.  I was writing this on my phone over the weekend, and didn't check
what the phone had done to what I tried to write.  The entire previous
paragraph was about code rot:
     Yes this approach can also ROT over time - but at least ExternalForm
will be consistent with itself.  And it might not ROT as fast as leaving
the mixed methods in there now. The only good way not to ROT is to put the
classes back in, really.
I wasn't talking about speed at all.  Took me awhile to decode what I had
intended to write - so I'm not surprised you came away with the angle you
did.  Basically, there is reason to be concerned about packages diverging
to the point where it isn't as easy as pulling it back in - especially if
no one uses the code.

It's not about speed, it's about being able to mix regular and external
> forms. But if you can refactor it so it still works and all the code is
> preserved, awesome!
>
> One more thing:
>
> It just occurred to me that the right place to put this is the Balloon3D
> repository:
> http://www.squeaksource.com/Balloon3D.html
>
> I just added you as a developer.
>
> I also noticed that there is already a Graphics-External package in there.
> I have not compared it to yours, but it might be interesting to check.
>
> Again, thanks for doing this :)
>
> - Bert -
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170424/2f40dc04/attachment.html>