[squeak-dev] Did we really nailed files?

Casey Ransberger casey.obrien.r at gmail.com
Fri Apr 8 19:29:15 UTC 2011


Wow, I hadn't thought about that. Ironic. 

On Apr 8, 2011, at 8:54 AM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:

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



More information about the Squeak-dev mailing list