On 2 November 2013 23:42, Chris Muller <asqueaker at gmail.com> wrote:
>>> 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.

If you're suggesting that I move the CommandLineToolSet's extra info
displaying into Error, and then using Error's new abilities, sure, I'm
OK with that. That scratches both our itches.

>>> 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?

Yes :) Take the opposite extreme: we can trivially solve all this
complexity about packages by having a single, gigantic package called
Squeak. Job done.

>> 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?

It should be an external package, but then so should Morphic. But
since we're nowhere near moving Morphic to an external package, and
since CI is rather important, the pragmatic approach would be to leave
it in Trunk.

Or, if you prefer, I think it's more important to have
CommandLineToolSet in Trunk than it is to have Tools/Morphic in Trunk.

> 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.

No, that's just the thing. Moving towards smaller packages makes it
_easier_ to assemble these things, because you don't build your system
out of giant baroque shapes, but simple little pieces. There is a
middle ground between our gigantic all-the-things packages and
"micro-modules" (I'm not sure how small things need to be before
they're micro, nor why small is bad. My Maybe and Either packages are
both a single class, and that's exactly the size package they ought to
be.)

I care a lot about minimalism, but I am _not_ tackling minimalism. I
am attacking _modularity_, which is related but not identical. I do
not want to shrink or melt things. I want to build things out of
separate parts. I want Lego, not lost wax castings.

Look at System, for instance. It has high level parts, and low level
parts. It depends on just about everything in the image: Collections,
Compiler, Compression, Environments, Files, Graphics,
'Installer-Core', Kernel, Monticello, MonticelloConfigurations,
Morphic, MorphicExtras, Multilingual, Network, 'PackageInfo-Base',
Sound, 'ToolBuilder-Kernel', Tools, TrueType. And yet it's supposedly
"low level".

PARTS of System are low level, and PARTS of System are high level, and
these parts do not belong in the same package. The only solution to
that (that is not simply giving up) is to add more packages. And you
know what? That's OK. We're not talking about 1000 packages, we're
talking about maybe a few more dozen. I'm sure our tools can handle
that. And if they can't, we should make better tools.

frank