On 8 April 2011 01:55, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> IMHO fake packages are awful.
>
+10000.

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)

and even:

myPackage add: icon.

and then:

myPackage serializeTo: aStream.

and then:

myPackage := Package loadFrom: aStream.

what could be more simpler and powerful?

> 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.
>
> All I get out of PackageInfo is having to make two commits instead of one when I modify behavior that reaches across "packages" and hope that trunk isn't broken for anyone who happens to click update before my second commit.
>
> I like the naming convention for extensions, actually. OTOH I *hate* the overrides. I don't care how convenient it is, it fuels Balkanization because it makes porting apps painful.
>
> PackageInfo := Bag mixed.
>
> Note that while I'm criticizing MC & PackageInfo here, I will quite confidently say that the new community development model has been a huge success: Squeak development is now unclogged. So MC is working, I just don't think it's ideal.
>
> On Apr 7, 2011, at 4:23 PM, Chris Muller <asqueaker at gmail.com> wrote:
>
>> I'm with you on the filtering.  But a lot of that could be solved at a
>> tool-level.
>>
>> I think a Package is a essential unit of organization; semantically
>> and practically.  I agree it would be nice for inter-package
>> operations, as well as refactoring operations, to be able to be better
>> integrated.
>>
>> I also agree that file-based SCM does introduce challenges and a lot
>> of redundancy.
>>
>> But MC1 is impressive by its staying power and relative simplicity.
>>
>> - Chris
>>
>>
>> On Thu, Apr 7, 2011 at 5:35 PM, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> File based SCM are a nightmare. Did you ever tried to re-organize
>>> source files into a different directory structure, or even worse
>>> reorganize classes/functions in files ?
>>> Fortunately Parc nailed files from Smalltalk for us a while ago, didn't they?
>>>
>>> Files, yes, but the idea of directory/folders is sticky.
>>> One avatar is the package, at least as it is defined now in
>>> Squeak/Pharo/VW: an arbitrary boundary for organizing class and
>>> methods with no semantic. Smell a lot like file/directories, doesn't
>>> it?
>>>
>>> The bad news is that our tools for handling those blobs are as bad as
>>> the others from this POV.
>>> If you move a class/method to a different package, you ain't gonna
>>> track it/diff it/merge it that easily with MC1...
>>> And this is a concrete problem when you wanna merge some Squeak/Pharo
>>> changes for example.
>>> VW Store suffers from same Achille heel AFAIK.
>>> Not only is it unpracticle, it was (is?) bugged (especially if you
>>> have silly ideas like playing with overrides)...
>>> Just browse the numbers of ARs related to interpackage motions if you
>>> have access to such database .
>>>
>>> At the end I find myself still using rough filed out change sets...
>>> Just the leafs of the arbitrary organizational tree, but that's enough
>>> they carry all the semantic.
>>> A pity (but thanks they are still there).
>>> Barely enough are the filtering tools (especially in Squeak/Pharo -
>>> Even MC UI seriously lack filtering facilities, a must-have for cherry
>>> picking).
>>> Should I have a look to MC2?
>>>
>>> Nicolas
>>>
>>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.