[Pharo-project] packages :)

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Mar 17 08:20:38 EDT 2010


On Mar 17, 2010, at 11:52 AM, Igor Stasenko wrote:

> Sorry, i was felt like you are at stage of 'making a first-class packages'.

this is a first class package but not a module system nor a namespace.

Stef

> 
> I understand that we going slowly to that, i just wanted to be sure
> that you doing right thing :)
> Sure, if RPackage is just an improved implementation of PackageInfo ,
> i see nothing wrong with that.
> 
> Thanks for listening my rants. :)
> 
> 
> On 17 March 2010 12:38, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>>> 
>>> Explicitly only! Because package is in control and should govern all
>>> of such operations:
>>> 
>>> package remove: someclass.
>> 
>> in my first implementation I got
>> package removeClassFromSystem:....
>> 
>> but it implies too much changes. So the goal is now. Let us have real
>> Package objects, support the transition with PackageInfo, support MC
>> and do the next steps when the next steps is needed.
>> 
>>> 
>>> how do you removing a class from a system?
>>> Right:
>>> 
>>> Smalltalk removeClassNamed: aName
>>> 
>>> so, what is wrong with that?
>>> 
>>>> How does the package know when a class is deleted from within a
>>>> #doSilently: block?
>>>> 
>>> this is irrelevant. Because if you build a system from a first
>>> principles, where a package is one of
>>> the key concepts in it, instead of a hollow abstraction, sure thing
>>> you taking care about all of it in proper manner.
>> 
>> but there are more urgent things to fix: network and others.
>> So let us be incremental.
>> 
>>>> RPackage is explicit, it manages and knows its own contents.
>>>> 
>>> Sure thing. In same way as i can write a brief description about something.
>>> But description of a subject cannot replace a subject itself. Because
>>> its missing a behavior and many other aspects.
>> 
>> the behavior of RPackage is to let know if a class is extended, which are its participants.
>> 
>> 
>>>>> you refer to a model, which doesn't takes this into account. Sure
>>> thing, it wont work.
>>> If you remember,  i told about packages having policies, when any
>>> modification of a package, such as adding or changing a method,
>>> should go through package policy verification, and only then added to
>>> package, or rejected.
>>> This is what i think will be a cool thing. This is what i could easily
>>> implement with a new model.
>>> Now think how you could do that in yours.
>> 
>> RPackage is not a namespace nor an hyper cool package system. It is a simple replacement
>> of the bad packageInfo hack. Now just making sure replacement will take us a lot of energy
>> and we will do it.
>> 
>>> Another thing: your model allows only classes to be a real citizens of package.
>>> While with mine, i can export any object which belongs to a package,
>>> as long as it knows how to serialize/deserialize itself.
>>> This means that i can define named variables in scope of package, like:
>>> - Display, Sensor , World etc etc..
>> 
>> Good but this is not the purpose of RPackage.
>> We need a good serializer in the future too.
>> 
>>>> It is not practicable because its not complete.
>>> Browser usually operating only with a small subset of a package - a
>>> class and its methods.
>>> I don't see how such organization could affect the performance.
>>> 
>>> If you refer to things like #classes , compare mine:
>>> 
>>> classes
>>>       ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
>>> 
>>> and the old PackageInfo:
>>> 
>>> classes
>>>       ^(self systemCategories gather:
>>>               [:cat |
>>>               (SystemOrganization listAtCategoryNamed: cat)
>>>                       collect: [:className | Smalltalk at: className]])
>>>                               sortBy: [:a :b | a className <= b className]
>>> 
>>> and you stating that mine will work slower?
>>> I really doubt that, given how things like #listAtCategoryNamed: implemented.
>> 
>> We are not talking about the old packageInfo
>> 
>> 
>> In RPackage
>>        classes
>>                ^ definedClasses
>> 
>> :)
>> 
>>> Unless you want to generate a thousands lengthy lists in your tools.
>>> But then it is impractical from either side - users can't cope with
>>> such big amounts of information.
>>> And this is where we using an automated things for refactoring. But
>>> then, a performance in a mass-refactoring tools is not very relevant.
>> 
>> It is with Moose PackageInfo nearly killed us we have to build a cache that takes 2 or 3 min
>> to build before being able to work.
>> 
>> Stef
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project





More information about the Pharo-dev mailing list