[squeak-dev] Re: Etoys developer chat log

Bert Freudenberg bert at freudenbergs.de
Tue Apr 27 15:32:14 UTC 2010


On 27.04.2010, at 17:21, Sean P. DeNigris wrote:
> 
> 
> Bert,
> 
> In http://forum.world.st/Call-For-Your-Opinion-td2015726.html#a2015887 , you
> mentioned that y'all are looking at how to get older packages to load in
> newer squeaks.  How's that coming?

For now it's just an idea. I'm pasting the relevant part of the log again below.

- Bert -

Begin forwarded message:
> From: Bert Freudenberg <bert at freudenbergs.de>
> Date: 12. April 2010 23:53:42 MESZ
> To: etoys-dev dev <etoys-dev at squeakland.org>
> Cc: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
> Subject: [squeak-dev] Etoys developer meeting notes
> Reply-To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>

[...]

> <bander> I'm interested in discussing Etoys project conversion
> <bander> I have a cunning plan :-)

[...]

> <bander> the problem with project conversion is that we need a more "semantic" conversion than we have today

[...]

> <bander> so what I'm intending to do is to change project loading that all classes that are loaded are mapped to proxy classes first
> <bander> I.e., SystemWindow -> ProxySystemWindowEtoys4
> <bander> These would match the layout of the 'old classes'
> <bander> Then, these dudes can perform semantic conversion
> <bander> For example: ProxySystemWindowEtoys4 would delete all but the panel widgets
> <bander> It would merely create a new SystemWindow, add those panels, return that
> <bander> For unchanged classes, you'd keep the originals with the option to proxy them if there have been semantic changes
> <bander> The proxy classes can be bundled up in some MC package i.e., "Etoys4-Import"
> <bertf> How would you make the proxies?
> <bander> You write 'em - perhaps with some help from the importer in creating proper class stubs
> <bander> It's not fully automatic - it can't be
> <bertf> right
> <bander> So that's roughly it - it's a process rather than a finished solution but I think it could work
> <bertf> well, not too different from teh class-reshape methods we have already
> <bertf> or am I missing something?
> <bander> VERY different :-)
> <bander> Have you tried loading a SystemWindow exported in 3.10 into 4.1?
> <bertf> becasue it's higher-level
> <bertf> not yet
> <bander> I used this example for a reason - there are no class shapes; there are semantic differences
> <bander> Things like event handlers
> <bertf> right
> <bander> And it gives us a specific way to handle imports from various Etoys versions if we can identify the version beforehand
> <bander> I.e., there might be ProxySystemWindow38 and ProxySystemWindowEtoys4 that do different things
> <jecel> Yes, it would be great to unbreak some older projects that don't current load
> <bander> When I was looking at Edgar's issues it dawned to me that we need more semantic conversion here.
> <bander> Preserve the user content, throw away the old stuff that is no longer in use
> <bertf> sounds like it could work

[...]

> <bander> With regards to testing, one good thing is that Edgar has been asking for better project support, so this will be an excellent test case. When the fundamentals are in place, the Etoys import should "just" be an application of the mechanism
> <bertf> oh man, that's exciting :)
> <bertf> I really need to sit down and port the etoys stuff to trunk
> <bander> I've always considered projects the 'deal-breaker' when it comes to move to a different basis...

- Bert -





More information about the Squeak-dev mailing list