Traits approaching mainstream Squeak

Herbert König herbertkoenig at gmx.net
Wed Aug 31 18:41:00 UTC 2005


Hello David,

DPH> Why do you say this?  There are ways and means to deal with this - if it
DPH> is actually a significant problem.  Time saved in 
DPH> development/maintenance may mitigate this, also. 

Software being said to be sluggish is in a big distvantage. In road
design where I plan to use squeak commercially there is a speed
difference between 3.6 and 3.7 and not using accessors and pushing
methods down the hierarchy makes a difference.

And though I like LookEnhancements I always notice the speed penalty.

I have big hopes for Exupery and Morphic cleanup/splitters, which seem
to address the main speed handicaps.

As for traits, there are times when I feel I have to overburden some
classes due to single inheritance and there definitely is code which
isn't speed sensitive. So I appreciate this too and as people point
out that you can use it but needn't to I think it's an improvement.

As always judicious choice is the key and the more tools you have at
hand the better you are off.

DPH> Possibly -- but I do not think Squeak was really ever meant to be a
DPH> production environment -- would be nice to be able to throw a 
DPH> (preferences) switch to  'production' :-)

At least seaside seems to aim at production and there seems to be a
direction making Squeak usable for production. In the long run I think
these attempts will give Squeak a better future.


Cheers,

Herbert                            mailto:herbertkoenig at gmx.net




More information about the Squeak-dev mailing list