March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] packages :)

by Henrik Johansen

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

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

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

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 17 March 2010 11:46, Lukas Renggli <renggli(a)gmail.com> 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.

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

> 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

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

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 > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 17 March 2010 10:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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. > same as above about 'offline'... what you mean by manipulating 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). > Indeed, or reversely - a package knows what methods belonging to it. 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.

March 17, 2010

Re: [Pharo-project] packages :)

by Lukas Renggli

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

March 17, 2010

[Pharo-project] (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'

by stephane ducasse

in Squeak (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' true in pharo (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00'. false. Apparently the false in pharo comes from a bug in readFrom: in DateAndTime Now the question is does it make sense to have a DateAndTime = to its string representation. For me I would prefer not (aDateAndTime offset: '0:12:00:00') = '1901-01-01T00:00:00+12:00' -> false (aDateAndTime offset: '0:12:00:00') printString = '1901-01-01T00:00:00+12:00' -> true DateAndTime>>= comparand "comparand conforms to protocol DateAndTime, or can be converted into something that conforms." | comparandAsDateAndTime | self == comparand ifTrue: [^ true]. comparandAsDateAndTime := [comparand asDateAndTime] on: MessageNotUnderstood do: [^ false]. ^ self offset = comparandAsDateAndTime offset ifTrue: [self hasEqualTicks: comparandAsDateAndTime ] ifFalse: [self asUTC ticks = comparandAsDateAndTime asUTC ticks] What do you think Stef

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 17 March 2010 10:23, Lukas Renggli <renggli(a)gmail.com> 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 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? > > Incremental development. Separation of concerns. > > 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. >> If you remember, i put some thoughts about packages here before. And >> even implemented a prototype package model myself (did you looked at >> it?). My concepts is simple and object-oriented (instead of >> symbolic-names oriented ;) ) : > > Where? > There was a series of topics, One of them - 'System changes & security model' and then others where i tried to describe things a little more. >> 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. > > 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. I envisioned a Package (real one) to replace a PackageInfo (hollow one). Like in attachment. >> 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 suggested Stef to look at the environments in the refactoring > engine. They are a proven implementation for more than 10 years, they > work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge), > and have been applied in many different scenarios (introspection, > reflection, refactorings, changes, lint, virtual code, ...). > >> 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? > > What would a method object refer to other than its class and its > selector? 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? > Is the introduction of another layer of objects that > duplicates Class, PseudoClass, MCClassDefinition, RBClass and > CompiledMethod, MethodReference, MCMethodDefinition, RBMethod > reasonable? > I fail to see a whole point in having these symbolic referencing, instead of direct ones. If you need to turn a symbolic name into an object, you can always do it, when loading the code. Keeping them inside image after that serving no purpose. > Remember, this is just the internal implementation. I agree that to > the outside a package should be represented using dedicated objects. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 17, 2010

Re: [Pharo-project] packages :)

by Tudor Girba

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. Cheers, Doru -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

March 17, 2010