when to start trimming?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

when to start trimming?

Chris Muller-3
> Having said that, we _should_ start a conversation around what will
> become Squeak 4.4.
>
> I'd like to see a greater emphasis on modularity, myself: if not
> having Environments in the base image now, then at least identifying
> the worst entanglements and working on cutting those. And tests.
> Tests, tests, tests. The tools especially need some kind of framework
> within which to test. A mock environment permitting one to test lovely
> things like #removeClass would be fantastic. (There are building
> blocks all over the place, but nothing assembled in the base image.)

Another thing which might be low-hanging fruit for the next version is
simply cutting out some of our deprecated stuff.

  - Removing old methods sending isThisEverCalled.
  - the 311Deprecated and 39Deprecated packages?
  - unloadability of some of the packages

Reply | Threaded
Open this post in threaded view
|

Re: when to start trimming?

Frank Shearar-3
On 22 July 2012 19:41, Chris Muller <[hidden email]> wrote:

>> Having said that, we _should_ start a conversation around what will
>> become Squeak 4.4.
>>
>> I'd like to see a greater emphasis on modularity, myself: if not
>> having Environments in the base image now, then at least identifying
>> the worst entanglements and working on cutting those. And tests.
>> Tests, tests, tests. The tools especially need some kind of framework
>> within which to test. A mock environment permitting one to test lovely
>> things like #removeClass would be fantastic. (There are building
>> blocks all over the place, but nothing assembled in the base image.)
>
> Another thing which might be low-hanging fruit for the next version is
> simply cutting out some of our deprecated stuff.
>
>   - Removing old methods sending isThisEverCalled.
>   - the 311Deprecated and 39Deprecated packages?
>   - unloadability of some of the packages

+1 I'm always happy with cruft removal. Would you mind expanding on
the last point ("unloadability of some of the packages")? Which
packages, and what exactly do you mean? Do you mean making sure that
certain packages may be unloaded and still have a functioning image?

frank

Reply | Threaded
Open this post in threaded view
|

Re: when to start trimming?

Levente Uzonyi-2
In reply to this post by Chris Muller-3

On Sun, 22 Jul 2012, Chris Muller wrote:

>> Having said that, we _should_ start a conversation around what will
>> become Squeak 4.4.
>>
>> I'd like to see a greater emphasis on modularity, myself: if not
>> having Environments in the base image now, then at least identifying
>> the worst entanglements and working on cutting those. And tests.
>> Tests, tests, tests. The tools especially need some kind of framework
>> within which to test. A mock environment permitting one to test lovely
>> things like #removeClass would be fantastic. (There are building
>> blocks all over the place, but nothing assembled in the base image.)
>
> Another thing which might be low-hanging fruit for the next version is
> simply cutting out some of our deprecated stuff.
>
>  - Removing old methods sending isThisEverCalled.

I think I ran into one of these once, but don't remember which one. :)

>  - the 311Deprecated and 39Deprecated packages?

Stuff in 39Deprecated is still being used, 311Deprecated seems to be okay
to be removed.

>  - unloadability of some of the packages

I think we should just make sure that those packages can be unloaded and
the system is still functional (this is not entirely true now), and
that we get the same functionality again after reload.


Levente

>
>