2011/4/8 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 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
>

And also, this is a message of humility to think twice before giving
lessons to the rest of the world.

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