[Pharo-project] packages :)
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.
> 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?
>>> 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:
>>> ^ contents select: [:object | object isBehavior and: [ object isMeta not] ]
>>> and the old PackageInfo:
>>> ^(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
>> ^ 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.
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Best regards,
> Igor Stasenko AKA sig.
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev