Package delimitation is orthogonal to class/method implementation.
It is an arbitrary delimitation just like file and directories are.
Maybe not that arbitrary for some external packages with few and well
identified interaction with base system.
But certainly very arbitrary when it concerns a "Kernel" or "Core" image.

I don't say this delimitation is useless... It could be usefull for
delimiting social responsibilities for example.
I don't say we can't arrange with it, C++ programmers do arrange with files...

I just say that if we start playing with package reorganization like
what is happening in Pharo and in a least measure in Squeak, then
we'll get into troubles because our tools are not tailored for
managing this reorganisation.

After re-re-reading Gilad's blog
http://gbracha.blogspot.com/2010/02/nail-files.html I found amusing
that despite the fact that we abandonned files very early, we
reproduced the same metaphor.

Nicolas


2011/4/8 Chris Muller <asqueaker at gmail.com>:
> I'm having trouble understanding what everyone is criticizing here.
> Is it that PackageInfo does not keep its own state?  That it relies on
> the category names of classes and methods to know what is "contained"
> in it?
>
> Or is it a criticism of the notion of having a delineation of
> classes+methods at all that make up a single executable "program"?
>
> You all are smarter than I, I'm just trying to learn..
>
>> PackageInfo is an awful fake. It not much better than a dummy state holder,
>> while various parts of system (including MC) trying to play with it.
>>
>> It would be much nicer at some day to have a proper reification of
>> packages in system, so they
>> could be in charge what goes inside them, and what are relationships
>> between them.
>>
>> I dreaming that some day we could do stuff like:
>>
>> newClass := Object subclass: #Foo.
>>
>> myPackage add: newClass.
>> myPackage add: (Object>>#extensionMethod)
>
> Wouldn't that be a separate step though?  Right now, we kill two birds
> with one stone:  categorizing classes and methods, AND assigning their
> Package at the same time.  Wouldn't separating these two activities
> lead to extra work and ambiguity about what code is in what
> package(s)?
>
>> and even:
>>
>> myPackage add: icon.
>>
>> and then:
>>
>> myPackage serializeTo: aStream.
>>
>> and then:
>>
>> myPackage := Package loadFrom: aStream.
>>
>> what could be more simpler and powerful?
>
> As for the icon, with MaSarPackage, you can simply override
> #resourceNames in your own PackageInfo subclass and it handles the
> serialization of those files into the Smalltalk-Archive (SAR)
> automatically.  Since that method is saved with the MC package, it
> only needs to be done once.  Very simple.
>
>>> There's no actual modularity going on with them, which is confusing to new people who've had modules in every other language that were namespaces.
>
> I just don't understand this statement.  The modularity is that of a
> set of code-elements that work together to solve a real-world
> problem..
>
>  - Chris
>
>