[squeak-dev] The Trunk: CommandLine-fbs.1.mcz

Chris Muller asqueaker at gmail.com
Sat Nov 2 23:42:34 UTC 2013


>> How about using the new Error>>#printDetailsOn:?
>
> You mean Error >> #printVerboseOn: I presume? I could. One thing that
> CommandLineToolSet class >> #debugError: does that #printVerboseOn:
> doesn't, is that it prints out the source of the method in which an
> MNU occurs. It's there precisely because it's the only way to figure
> out what the heck just happened in the event of an MNU.

It seems like the purposes of the two methods are the same -- to print
a lot of information about the error to a stream so it can be somewhat
understood and somewhat debugged outside of the image environment.
I'm not opposed if you can enhance it to include the source of the
offending method.

>> Why does this need to be yet another new package instead of simply
>> part of Tools?  It's two classes that should never be unloaded,
>> because command-line operations are something that should always be
>> part of the system.
>
> It should be a separate package because it serves a different purpose.

Is that a good reason?

> CommandLineToolSet provides some basic infrastructure for command line
> things. StandardToolSet does the same for a headful image. The two
> should not belong in the same package any more than MorphicUIManager
> and ST80UIManager do.

Morphic and ST80 are entire graphical frameworks, but CommandLineTools
is for supporting a headless system on a core "engine".  If you're
still saying it should be a separate package, maybe you're making a
case that it should be an external package?

Modules don't scale in all the dimensions we need them to scale
anyway, so shouldn't we take a reasonably pragmatic (vs. purist)
approach to defining package boundaries?  "Truly minimal" will never
be achieved even if we defined hundreds of tiny little packages,
because there'll always be some extra classes and/or methods which
"serve a different purpose" than what is truly minimally required for
application XYZ.

And yet, moving toward micro-modules increases the complexity for
humankind to assemble working systems.  If we really care about truly
minimal I think we should get Spoon going and leave the packages
reasonably chunky-grained..  There'll always be the need for various
"shrinking" acitivities if someone is concerned about that, and such
shrinkage can include unloading individual classes if they wish.




> You're nearly right in that they should never be unloaded. (Because a
> truly minimal image would be able to do nothing but load another
> package.) But Tools should be :)


More information about the Squeak-dev mailing list