- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo and Namespaces

by Frank Shearar

On 26 June 2012 22:17, camille teruel <camille.teruel(a)gmail.com> wrote: > As far as I understand the video ofÂ GermÃ¡n's implementation, the import's > granularity is at the environment level, for both source-side and sink-side, > not at class level: he imports a whole environment into another. All the > class defined inside the source environment become accessible to the sink > environment without prefixing with the source environment name. > > IMO, the problems of importing a whole namespace into another are: > > you have to manage name clashes. > > Ex: you have a namespace A that imports namespaces B and C developped by > some other guys, then a guy add a class to B whose name is already used in C > for another class that A uses => A is now broken. > > you can't see how many dependencies a namespace has without doing some code > analysis. > > > However if you makes your imports class by class, you can see how many > dependency a namespace has and you are always sure that your code refers to > the classes you want. > >> I just say that changing binding of variables at the class level is not a >> good granularity. I do not want to have >> Object subclass: #NameOfSubclass >> Â Â Â Â instanceVariableNames: '' >> Â Â Â Â classVariableNames: '' >> Â Â Â Â poolDictionaries: '' >> Â Â Â Â category: 'Bob' >> >>> Â Â environment: > > > You have to specify in which environment a class is at some point. If you > look at class builder, there is the super long method: > #name:inEnvironment:subclassOf:...... > For the moment, the environment is always the system dictionary. But if you > have several environements, you'll have to add the extra argument you don't > want when creating new classes. No: you store the current environment in a dynamic variable. ClassBuilder's convenience method checks the value of that variable, and you're done. If you look at the squeak-dev archives for today you'll see Colin Putney's Environment prototype which does exactly that. frank > BTW, do we want to have just namespace categories or a hierachical namespace > imbrication?

June 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by camille teruel

As far as I understand the video of GermÃ¡n's implementation, the import's granularity is at the environment level, for both source-side and sink-side, not at class level: he imports a whole environment into another. All the class defined inside the source environment become accessible to the sink environment without prefixing with the source environment name. IMO, the problems of importing a whole namespace into another are: - you have to manage name clashes. Ex: you have a namespace A that imports namespaces B and C developped by some other guys, then a guy add a class to B whose name is already used in C for another class that A uses => A is now broken. - you can't see how many dependencies a namespace has without doing some code analysis. However if you makes your imports class by class, you can see how many dependency a namespace has and you are always sure that your code refers to the classes you want. I just say that changing binding of variables at the class level is not a > good granularity. I do not want to have > Object subclass: #NameOfSubclass > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Bob' > >>> environment: You have to specify in which environment a class is at some point. If you look at class builder, there is the super long method: #name:*inEnvironment: *subclassOf:...... For the moment, the environment is always the system dictionary. But if you have several environements, you'll have to add the extra argument you don't want when creating new classes. BTW, do we want to have just namespace categories or a hierachical namespace imbrication?

June 26, 2012

Re: [Pharo-project] [update 2.0] #20162

by Sean P. DeNigris

Issue 6076: Pharo 2.0 Jenkins build trigger not working http://code.google.com/p/pharo/issues/detail?id=6076 I did a "Build now" to get to the latest update. From https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/urltriggerPo… : [URLTrigger] - Poll with a URL Inspecting Monitor a change of the content content for URL http://pharo.gforge.inria.fr/updates/pharo2.0/updates20.list Polling started on Jun 17, 2012 3:21:24 PM Polling for the job Pharo-2.0 Looking nodes where the poll can be run. Looking for a candidate node to run the poll. Looking for a polling node with the assigned project label pharo-build. Polling remotely on pharo-build Using Basic Authentication with the user 'bruni' [ERROR] - SEVERE - Polling error null -- View this message in context: http://forum.world.st/update-2-0-20162-tp4636765p4636789.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by StÃ©phane Ducasse

On Jun 26, 2012, at 9:30 PM, James Foster wrote: > On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: > >>>>> What happened to the project from GermÃ¡n Leiva >>>>> http://www.youtube.com/watch?v=n4I7fSVNX2A >>>> >>>> we do not want class level namespace because this is the mess >>> >>> As the sponsor for GermÃ¡n's project, I have some interest in this topic. StÃ©phane has said a couple times that it is wrong but has never taken time to explain his objections. >> >> We do not want to have class name resolution at the granularity of a class. > > And are you saying this because you think GermÃ¡n's implementation does this? > >> Why because it means that in the same package reading the code containing a class Foo could be a different one. >> Why because it means that in the same package, reading the code containing a class Foo could be a different one. ^^^^^ Class level namespace import means that in a given class, a method accessing the variable Foo may end up pointing to another class Foo in a class in the same package importing another namespace. > I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think GermÃ¡n's implementation does not support this use case? No I just say that changing binding of variables at the class level is not a good granularity. I do not want to have Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Bob' >>> environment: >> I'm saying that since years. > > I agree you have been saying that GermÃ¡n's implementation isn't what you want. I just don't understand what you don't like about it. because this is a class level import. > Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. Usually this is the class of the method. > This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. no this is a question of language design. > In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) No we do not want to have that. We want import to be specified at the border: i.e. during module import. Inside a module the world is flat and as a developer I do not want to know that this Point is from Core when that one is from MyCore. If I want both, at the module import level I write Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint; > or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. I dislike them both. A module should provide a certain level of encapsulation, else naming convention is good enough. Because else having namespace does not prevent you to have to declare that WA is not a namespace somebody else should use. > If you don't have time to discuss this in depth I would be less frustrated if you would wait to say it is wrong until you have time to explain why. > > James Foster > >

June 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by Schwab,Wilhelm K

+1 on not adding syntax. Never do to a language that which can be done with the language. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of James Foster [Smalltalk(a)JGFoster.net] Sent: Tuesday, June 26, 2012 3:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo and Namespaces On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: >>>> What happened to the project from GermÃ¡n Leiva >>>> http://www.youtube.com/watch?v=n4I7fSVNX2A >>> >>> we do not want class level namespace because this is the mess >> >> As the sponsor for GermÃ¡n's project, I have some interest in this topic. StÃ©phane has said a couple times that it is wrong but has never taken time to explain his objections. > > We do not want to have class name resolution at the granularity of a class. And are you saying this because you think GermÃ¡n's implementation does this? > Why because it means that in the same package reading the code containing a class Foo could be a different one. I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think GermÃ¡n's implementation does not support this use case? > I'm saying that since years. I agree you have been saying that GermÃ¡n's implementation isn't what you want. I just don't understand what you don't like about it. Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. If you don't have time to discuss this in depth I would be less frustrated if you would wait to say it is wrong until you have time to explain why. James Foster

June 26, 2012

Re: [Pharo-project] [update 2.0] #20162

by Marcus Denker

On Jun 26, 2012, at 9:25 PM, StÃ©phane Ducasse wrote: > strnage I did not find it on jenkins. Jenks stopped to build automatically after we do an update. (we need a jenkis bug tracker...) > When I updated from 57 i got problems (may be my image was shaky). > > On Jun 26, 2012, at 8:40 PM, Marcus Denker wrote: > >> 20162 >> ----- >> >> Issue 6157: remove dead lmmplugin code >> http://code.google.com/p/pharo/issues/detail?id=6157 >> >> Issue 6161: Finder: Change Pattern back to Examples >> http://code.google.com/p/pharo/issues/detail?id=6161 >> >> Issue 6168: Changeset>>#superclassOrder: should be only used by ChangeSet related objects >> http://code.google.com/p/pharo/issues/detail?id=6168 >> >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > > -- Marcus Denker -- http://marcusdenker.de

June 26, 2012

Re: [Pharo-project] Pharo and Namespaces

by James Foster

On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: >>>> What happened to the project from GermÃ¡n Leiva >>>> http://www.youtube.com/watch?v=n4I7fSVNX2A >>> >>> we do not want class level namespace because this is the mess >> >> As the sponsor for GermÃ¡n's project, I have some interest in this topic. StÃ©phane has said a couple times that it is wrong but has never taken time to explain his objections. > > We do not want to have class name resolution at the granularity of a class. And are you saying this because you think GermÃ¡n's implementation does this? > Why because it means that in the same package reading the code containing a class Foo could be a different one. I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think GermÃ¡n's implementation does not support this use case? > I'm saying that since years. I agree you have been saying that GermÃ¡n's implementation isn't what you want. I just don't understand what you don't like about it. Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. If you don't have time to discuss this in depth I would be less frustrated if you would wait to say it is wrong until you have time to explain why. James Foster

June 26, 2012

Re: [Pharo-project] [update 2.0] #20162

by StÃ©phane Ducasse

strnage I did not find it on jenkins. When I updated from 57 i got problems (may be my image was shaky). On Jun 26, 2012, at 8:40 PM, Marcus Denker wrote: > 20162 > ----- > > Issue 6157: remove dead lmmplugin code > http://code.google.com/p/pharo/issues/detail?id=6157 > > Issue 6161: Finder: Change Pattern back to Examples > http://code.google.com/p/pharo/issues/detail?id=6161 > > Issue 6168: Changeset>>#superclassOrder: should be only used by ChangeSet related objects > http://code.google.com/p/pharo/issues/detail?id=6168 > > > > -- > Marcus Denker -- http://marcusdenker.de > >

June 26, 2012

Re: [Pharo-project] MCSqueaksourceRepository

by StÃ©phane Ducasse

On Jun 26, 2012, at 8:51 PM, Sven Van Caekenberghe wrote: > In your case I would diagnose that as a 'Ruby Fat Finger' ;-) :) We should learn and take what is good there. - good nice support for file - string manipulation - ` with the new small kernel it will be interesting to see coral

June 26, 2012

[Pharo-project] Nautilus - Can't Rename Temporary

by Sean P. DeNigris

Issue 6174: [Bug]: Nautilus - Can't Rename Temporary http://code.google.com/p/pharo/issues/detail?id=6174 1. In a Nautilus code pane, select a temporary 2. Click to bring up the menu with "Source code refactoring" 3. Choose Rename Temporary 4. Fill in a new name You will see and invalid variable name error. This is because NautilusRefactoring>>renameTemporaryNamed: oldname Between: anInterval from: aMethod is receiving an empty Text for oldName Any ideas? -- View this message in context: http://forum.world.st/Nautilus-Can-t-Rename-Temporary-tp4636773.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 26, 2012