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
|