On 2011/04/08 16:58, Nicolas Cellier wrote:
> 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.

A couple of points:

* Gilad's vision's great and all, but it's not what we have today. We 
have a world where Smalltalk's been touting images for 30 years... and 
noone else uses them. In particular, Gilad says " You don't need to know 
how your code is scattered among files anymore than you need to know 
what disk sector it's on". That's perfectly true, and I _don't_ want to 
care about where my method's being persisted. But what I also _don't_ 
want to do is to have to reinvent everything all the time. For instance, 
I was reading a method and wondered who wrote it. Sure, there's the 
latest author, but that's precious little. In other languages I'd simply 
ask my version control - "git blame" or "hg annotate". So someone will 
say "so write that so Monticello can do it", which is to precisely make 
my point. I don't _want_ to write standard tools that someone else has 
already done.

* What I'd really like is something much more like Newspeak's modules. 
In fact, I'd like to ruthlessly pillage Newspeak for every good idea it has.

* If our tools will break, maybe we should fix them. Otherwise our 
horses won't be able to fit in our cars' bonnets.

My point is that there are many, many clever people doing clever things 
out in the rest of the world, and we don't have the time or resources to 
reinvent stuff. That's just playing catch-up, and (a) we'll never be 
able to keep up, (b) we'll keep our NIH reputation, and (c) we'll never 
be able to _invent_the_future_.

frank

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