[squeak-dev] Re: Shout
Andreas Raab
andreas.raab at gmx.de
Sun Aug 16 03:56:42 UTC 2009
Colin Putney wrote:
> One, lets not conflate these two issues. Including Shout is unrelated to
> removing Services; either could be done without the other. Let the two
> proposals stand or fall based on their merits.
Yes, good point.
> Two, removing Services sounds like a good plan. For services to be
> really worthwhile, lots of other stuff would have to be rewritten to use
> them. That hasn't happened, and it looks like it never will. Services
> should be easy to make into a loadable package, so if any other packages
> out there happen to use it, they can keep doing so.
My thoughts exactly.
> Three, I'm a little ambivalent about Shout. Syntax coloring is cool, but
> it seems to sink its tentacles fairly deeply into Morphic.
> Understandable, given that it must respond to every keystroke. I'm in
> the middle of reworking the Shout support in OmniBrower, to break the
> dependency it introduces between the Smalltalk domain model and Morphic.
Ah. I think I wasn't clear here. The goal is to provide syntax
highlighting hooks directly in SmalltalkEditor (see the earlier
discussion about the SmalltalkEditor/TextEditor distinction). These
hooks just happen to look a lot like the extension methods Shout uses
today ;-) But by the end of the day, all you will need from Shout are
the categories Shout-Parsing and Shout-Styling and you will get
highlighting without extra dependencies. If you happen to write an
alternative package that can be utilized with the same protocol you will
be able to hook this in seamlessly. And if you think that syntax
highlighting is a waste of memory, you can just unload Shout.
> These aren't really show-stoppers, but they make me think that it would
> be better to keep Shout as a separate package, with really clear
> boundaries. Maybe someone who knows Shout better could convince me
> otherwise, or come up with a way to have Shout in the kernel image that
> would keep it separate from the default toolset, available to alternate
> toolsets such as OmniBrowser, and easily unloadable.
That is the goal.
> Finally, we ought to have some sort of policy or philosophy for deciding
> what is included in the base image. Are we still trying to create a
> minimal image that can be bootstrapped up to a more complete image? Are
> "extras" eligible for inclusion if they have broad enough appeal?
Great questions. I've been waiting for people to propose things they'd
like to see in Squeak (assuming that they are also willing to work on
them). And although I think we'd all like the image to get smaller, more
compact and simpler, I don't think we should exclude anything before
discussing it concretely. So yeah, I'd think that if people have stuff
that is broadly desirable, please do put it forward.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|