packages :)
Locked
12
12
 
|
>> If the package would contain the real classes and real methods one had
>> to change (literally) thousands of places in the system. >> > Hmm.. why is that? > Currently everything in image is centered mainly around classes and > methods & categories. > And only a little around packages. How does the package know when a class is deleted? How does the package know when a class is deleted from within a #doSilently: block? >> RPackage is about a PackageInfo replacement, not about a namespace >> implementation. Arguably namespacing is something entirely different. >> > As i said, it doesn't implements a new model, but a different view on > existing one. RPackage does not implement a different view: PackageInfo is implicit, it takes all information from elsewhere (category and protocol names). RPackage is explicit, it manages and knows its own contents. > Err, what you mean by that? > If a 'method object' is a method, then it should behave like a method > - conform on a method's protocol. Isnt? The question is if you really want to store the real thing (compiled method)? RPackage chose to store a reference, because the real thing can easily and quickly be looked up. Package.st stores compiled methods in a large IdentitySet. Recompiling a method means that it need to be removed and re-added whenever something changes in the system. Somebody doing something in a #doSilently: block will immediately screw up your complete package model, because you suddenly miss methods or have different methods that are actually the same. Package.st does not seem practicable to build an efficient GUI. Having to iterate over the complete package contents to find certain elements is deadly to a responsive GUI. Getting the classes and methods must be a fast operation (ideally constant time) that does not depend on the number of elements in the package and the number of other packages. RPackage aims to answer questions a GUI might have quickly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 17 March 2010 10:47, Stéphane Ducasse <[hidden email]> wrote:
> > On Mar 17, 2010, at 8:32 AM, Igor Stasenko wrote: > >> Hi Stef, >> >> i took a look on your implementation and i don't like it. :) > > Ok fair > My first implementation was holding classes and objects and people did not like it either. > >> It tries to work with methods and classes through symbolic names.. > > > The first implementation was only holding classes and compiled methods/methodreferences > and the problems is that you cannot reason about off-line system. > It sounds like you can reason about contents of an image file if you open it in a text editor or hex dump. > Lukas told me ok this is not good because of that. Look at RBEnvironment. So I rewrote everything > 3 times. So I'm started to get bored. > So, looks like i am little late in the game.. Too bad. >> I don't know what is the purpose of making a package to be a dead >> piece of flesh, which reflects own organization by using symbols, >> instead of real objects? Who are you trying to deceive with that? > > > Off image package manipulation. > I fail to see how this is relevant to a in-image representation. I can choose any file-out/in format i want - binary, xml, .st , whatever... So, i really don't understand what you talking about 'off-line' here. >> If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at >> it?). > > Now where is the code? Strange, i thought i shown it before.. i could send it to you if you want. I remember i presented most of my ideas & concerns about this couple months ago, and we did talked about it. > What is the cost to find all the extendingClasses, if a method is included in a packages, > classes extensions, how do we hook event for classremoval, classaddition, without raising multiple times > the same. > In a properly implemented system it will be same or less. Because model is same, since you refer to same object(s), having same structural organization. So why it should be any slower? > >> My concepts is simple and object-oriented (instead of >> symbolic-names oriented ;) ) : >> If we take a most abstract and stripped down concept then, in order to >> define a package, we need just two things: >> - a set of objects , which belong to that package >> - and a namespace (name->object), where name is a symbol and object is >> one of the objects, which >> belong to package. >> >> note, that there is no any 'methods' or 'classes' . It is just objects >> and names. And then you can start adding flesh on that skeleton by >> implementing things , like covenient adding/defining/lookup classes, >> methods , etc etc. >> But if you don't that , you model will remain a piece of flesh, >> without skeleton - it can't move , it can only lie on the ground and >> rot :) >> >> I don't understand, why to not work with actual objects, instead of >> names? Please enlighten me, why you want to refer to objects >> indirectly and leaving to somethings else in the system to decide how >> these names turned into a real objects. >> What is the benefit of having such indirect model? > > We could create package and manipulate them even if they are not in the image. > something which lives and having a flesh only if it runs inside an image? > >> In such form, a package becomes only a view of something which already >> exists in a system without it. It doesn't defining a domain space - >> just reflecting existing one (a years-old existing system organization >> (classes and methods)). > > Exactly. > But if you want to introduce Package then a method should know its package (which I did > in my first implementation). > Take a look at ClassOrganizer it using similar approach. A method doesn't knows to what category it belongs to. But still, tools are able to determine that. Except that , again a ClassOrganizer refers to methods indirectly, through 'selectors', like selectors have anything to do with behavior , which is any compiled method holding. Or maybe this is what you talking about 'manipulating offline'? You can file out class name and selectors it contains. Now you can manipulate with these names... for no purpose, because you missing a key thing which makes all of these names reason to exist - a behavior and data:) We saying 'each method of class belongs to a certain category'. This means that there are relation between category name and a method. The question is where to put that relation - you can either add a 'category' or 'categories' field to a compiled method and you done or start building a mess. >> And thus, you will have a hard times when you would want to migrate to >> a new system organization, because all levers of control lying >> elsewhere, instead in a package itself. > > Did not get this one. > ClassOrganizer is your guide. ;) > >> >> -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Tudor Girba
On Mar 17, 2010, at 10:05 AM, Tudor Girba wrote: > Hi Stef, > > On 17 Mar 2010, at 09:50, Stéphane Ducasse wrote: > >> On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote: >> >>>> It tries to work with methods and classes through symbolic names.. and >>>> you immediately end up with >>>> gemmorage of a need to keep separate 'core' and 'extension' , 'meta' >>>> and 'instance-side' methods in your model. >>> >>> Yes, that's what I suggested, merge the extension and core dictionaries. >> >> I do not see how? >> without first class class and no string match: '* class' ? >> I'm curious > > > The issue is not between instance side and meta side. The issue is with having two dictionaries for each: one for extensions and one for definitions. If we have the information about which classes are defined in this package, we only need to store the methods for the class and we know which are extensions and which are not. this is not that simple. For each class I have to know the methods (defined | extended) So I have to encode that information why because not all the methods of a defined class are defined in a package! The class point defined in package graphics can be extended by myPackage and these methods should not be part of the Graphics. So I always need three information Class * method * extended|defined > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
> I fail to see how this is relevant to a in-image representation. > I can choose any file-out/in format i want - binary, xml, .st , whatever... > So, i really don't understand what you talking about 'off-line' here. Because we could browse squeaksource mc file using the same browser. Just need to have the representation. Lukas pointed to the problems if we go for real living objects we will have to pay attention to a lot of places and may be this is something to do in a second step. I would prefer to have classes and methods but this is more brittle. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On 17 March 2010 11:46, Lukas Renggli <[hidden email]> wrote:
>>> If the package would contain the real classes and real methods one had >>> to change (literally) thousands of places in the system. >>> >> Hmm.. why is that? >> Currently everything in image is centered mainly around classes and >> methods & categories. >> And only a little around packages. > > How does the package know when a class is deleted? > Explicitly only! Because package is in control and should govern all of such operations: package remove: someclass. 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. >>> RPackage is about a PackageInfo replacement, not about a namespace >>> implementation. Arguably namespacing is something entirely different. >>> >> As i said, it doesn't implements a new model, but a different view on >> existing one. > > RPackage does not implement a different view: PackageInfo is implicit, > it takes all information from elsewhere (category and protocol names). 'Elsewhere' is a key word here, which means that PackageInfo is a view, and nothing more. > 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. >> Err, what you mean by that? >> If a 'method object' is a method, then it should behave like a method >> - conform on a method's protocol. Isnt? > > The question is if you really want to store the real thing (compiled > method)? RPackage chose to store a reference, because the real thing > can easily and quickly be looked up. > > Package.st stores compiled methods in a large IdentitySet. Recompiling > a method means that it need to be removed and re-added whenever > something changes in the system. Somebody doing something in a > #doSilently: block will immediately screw up your complete package > model, because you suddenly miss methods or have different methods > that are actually the same. > 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. 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.. > Package.st does not seem practicable to build an efficient GUI. Having > to iterate over the complete package contents to find certain elements > is deadly to a responsive GUI. Getting the classes and methods must be > a fast operation (ideally constant time) that does not depend on the > number of elements in the package and the number of other packages. > RPackage aims to answer questions a GUI might have quickly. > 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. And either way, at any time, i can add an inst var which will cache classes , if i would think this is not enough. 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. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
On Mar 17, 2010, at 11:23 15AM, Igor Stasenko wrote: >> 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. > >>>> RPackage is about a PackageInfo replacement, not about a namespace >>>> implementation. Arguably namespacing is something entirely different. >>>> >>> As i said, it doesn't implements a new model, but a different view on >>> existing one. >> >> RPackage does not implement a different view: PackageInfo is implicit, >> it takes all information from elsewhere (category and protocol names). > > 'Elsewhere' is a key word here, which means that PackageInfo is a > view, and nothing more. Yes, you are talking about two entirely different kinds of Package. RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
> Explicitly only! Because package is in control and should govern all
> of such operations: > > package remove: someclass. > > how do you removing a class from a system? > Right: > > Smalltalk removeClassNamed: aName > > so, what is wrong with that? Nothing is wrong. It sounds great, but unfortunately we have an existing system that doesn't work like this. And big-bang changes like you propose don't work. There will be thousands of lines of code to be adapted in the image and in external packages. >> 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. Yes, but we don't build a new system. We fix and improve an existing one. >>>> RPackage is about a PackageInfo replacement, not about a namespace >>>> implementation. Arguably namespacing is something entirely different. >>>> >>> As i said, it doesn't implements a new model, but a different view on >>> existing one. >> >> RPackage does not implement a different view: PackageInfo is implicit, >> it takes all information from elsewhere (category and protocol names). > > 'Elsewhere' is a key word here, which means that PackageInfo is a > view, and nothing more. Yes, PackageInfo is a view. I am just saying that RPackage is not a view. > 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.. The question is if we really want to have that. You're proposal seems to try to solve too many problems: packaging, namespaces, import, export, serialization, ... RPackage aims to solve one thing only, packaging. > 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 am not talking about PackageInfo. I think we agree that PackageInfo is not ideal. What I am saying is that Package.st is no better than PackageInfo, because it iterates over a large set of objects to select the interesting parts. That slows tools down. RPackage has a structural model and can return the classes without having to filter. > 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. You need to be able to generate thousands of (small) lists for classes, protocols and methods when you for example scroll through a package tree. Select a package in O2 or a category in OB and scroll down using the down arrow to see what I mean. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 17 March 2010 12:16, Stéphane Ducasse <[hidden email]> wrote:
> >> I fail to see how this is relevant to a in-image representation. >> I can choose any file-out/in format i want - binary, xml, .st , whatever... >> So, i really don't understand what you talking about 'off-line' here. > > Because we could browse squeaksource mc file using the same browser. > Just need to have the representation. > Ah, i see. And what about it? Instantiate a class object an put everything you need there. You can avoid compiling methods, but put a 'NotYetLoadedMethod' instances into its dict. Look, i can do similar things to what is MethodReference or PseudoClass is used for in current implementation, means that instead of reifying a real object, put a proxies to unreal ones. And then you can browse it and do same things. Where is the problem? > Lukas pointed to the problems if we go for real living objects we will have to pay attention > to a lot of places and may be this is something to do in a second step. > Right. Introducing my idea will require a lot of changes in various places. So, if your only argument, that we're not ready for it yet, i accepting that :) > I would prefer to have classes and methods but this is more brittle. > Nope. Explicit control is always less brittle than implicit. > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Henrik Sperre Johansen
> RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send.
No, this is not true. RPackage does not have a cache. Please, have a look at the code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Sorry, i was felt like you are at stage of 'making a first-class packages'.
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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On 17 March 2010 12:45, Lukas Renggli <[hidden email]> wrote:
>> RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send. > > No, this is not true. RPackage does not have a cache. Please, have a > look at the code. > Strongly speaking, it is a cache, because you can recreate a full package info by searching through different places in system. This is a main difference to what i have proposed, i think. > Lukas > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 17 March 2010 12:54, Igor Stasenko <[hidden email]> wrote:
> On 17 March 2010 12:45, Lukas Renggli <[hidden email]> wrote: >>> RPackage is, like PackageInfo, just a view of the underlying system, but maintaining a cache of the essential data instead of recomputing at every message send. >> >> No, this is not true. RPackage does not have a cache. Please, have a >> look at the code. >> > > Strongly speaking, it is a cache, because you can recreate a full i meant 'strictly speaking'. Sorry, my english fails me sometimes :) > package info by searching through different places in system. > This is a main difference to what i have proposed, i think. > > >> Lukas >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
>> No, this is not true. RPackage does not have a cache. Please, have a
>> look at the code. > > Strongly speaking, it is a cache, because you can recreate a full > package info by searching through different places in system. > This is a main difference to what i have proposed, i think. Only if you keep the category and protocols up-to-date with all operations. I don't think that this is done/planned with RPackage. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
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 <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Hi Stef,
On 17 Mar 2010, at 11:09, Stéphane Ducasse wrote: > On Mar 17, 2010, at 10:05 AM, Tudor Girba wrote: > >> Hi Stef, >> >> On 17 Mar 2010, at 09:50, Stéphane Ducasse wrote: >> >>> On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote: >>> >>>>> It tries to work with methods and classes through symbolic >>>>> names.. and >>>>> you immediately end up with >>>>> gemmorage of a need to keep separate 'core' and 'extension' , >>>>> 'meta' >>>>> and 'instance-side' methods in your model. >>>> >>>> Yes, that's what I suggested, merge the extension and core >>>> dictionaries. >>> >>> I do not see how? >>> without first class class and no string match: '* class' ? >>> I'm curious >> >> >> The issue is not between instance side and meta side. The issue is >> with having two dictionaries for each: one for extensions and one >> for definitions. If we have the information about which classes are >> defined in this package, we only need to store the methods for the >> class and we know which are extensions and which are not. > > this is not that simple. > For each class I have to know the methods (defined | extended) > So I have to encode that information > why because not all the methods of a defined class are defined in a > package! > > The class point defined in package graphics can be extended by > myPackage and these methods should not be part of the Graphics. > > So I always need three information > Class * method * extended|defined Not quite. At this moment, for any given class in a package, you can either have entries in the defined or in the extension dictionaries, but not in both in the same time. So, this is an indication that you can simply merge the two dictionaries. As soon as you add a method to a package, you know exactly if that method is defined or not by knowing whether the class is defined in that package. Also, if you do have the methods in one dictionary, then you also won't have to care whether you moved the definition of a class between packages. Right now, if you move the definition of a class without touching the methods, you will have to ensure in the two packages that the methods that were defined are not extensions and the other way around. If you interpret the extension by looking at where the class is defined, then you do not lose anything. Yet another point is that I typically first want to know the methods of a class from a package. I do not want to know which is extended or which is not. So, I currently have to look it up in two dictionaries which is not necessarily optimal. Or am I missing something? Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>>
>> >> So I always need three information >> Class * method * extended|defined > > Not quite. > > At this moment, for any given class in a package, you can either have entries in the defined or in the extension dictionaries, but not in both in the same time. So, this is an indication that you can simply merge the two dictionaries. sure but you have them to filter after. > As soon as you add a method to a package, you know exactly if that method is defined or not by knowing whether the class is defined in that package. Yes this was the first implementation I did and it was boring to always check. Is the class defined or not. > Also, if you do have the methods in one dictionary, then you also won't have to care whether you moved the definition of a class between packages. Ummm I do not buy that. How? > Right now, if you move the definition of a class without touching the methods, you will have to ensure in the two packages that the methods that were defined are not extensions and the other way around. yes. > If you interpret the extension by looking at where the class is defined, then you do not lose anything. speed? Indeed I could merge all the methods into two dictionaries instead of four and always check the classes defined in the packages. but I will be doing includes: all the time. I can give a try. May be I will do another implementation to be able to measure. I will first remove the isExtension: > Yet another point is that I typically first want to know the methods of a class from a package. I do not want to know which is extended or which is not. So, I currently have to look it up in two dictionaries which is not necessarily optimal. you have the method methodForClass: for that, you get all the methods defined or extended for a class in a given package. > Or am I missing something? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |