[Pharo-project] Pharo and Namespaces
Since Colin opened a new thread on Squeak-dev about namespaces together with an implementation for environments: http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html I thought it would be good to ask on Pharo too about the state. What happened to the project from Germán Leiva http://www.youtube.com/watch?v=n4I7fSVNX2A I know it is always a time issue - but what is the overall plan? Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
We are working on a module system but it takes time.
Since Colin opened a new thread on Squeak-dev about namespaces together with an implementation for environments:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html
I thought it would be good to ask on Pharo too about the state.
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
I know it is always a time issue - but what is the overall plan?
Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
On Jun 26, 2012, at 12:08 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. James Foster
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. Why because it means that in the same package reading the code containing a class Foo could be a different one. I'm saying that since years. Now as I said our plate is FULL. If colin has cycle perfect for him. Namespaces are not urgent. So far we have on our roadmap - new compiler - cleaning it - all the tools been rewritten - new canvas - new event - systemNotification -> announcement - package and package metadata - UIBuilder - FileSystem integration - validation process of configuration and distributions ... and I guess I forgot some works. So let us focus on finishing. Because starting something is the easiest part. Finishing is the key part. 5% but 80% of the importance because if the last 5% are not done nothing is really done.
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
+1 on not adding syntax. Never do to a language that which can be done with the language. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of James Foster [Smalltalk@JGFoster.net] Sent: Tuesday, June 26, 2012 3:30 PM To: Pharo-project@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
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
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?
On 26 June 2012 22:17, camille teruel <camille.teruel@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?
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods. Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean. I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required. If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)? What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it? Thanks for engaging in the discussion. James Foster
James sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them. Stef On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
Stephane, Wow, there is a limit to your utter awesomeness... Take care! On this namespace thing... Well, in fact, I found that nice with Java but at the end of the day, what matters is the modular bit. And we have that with packages and MC. We do no need the namespaces really. Prefixing the classes works and scales. Look at any Obj-C app, there are prefixes everywhere.... and it works well. No having this additional level makes Pharo much more approachable for new people. And in order to get traction, this is important. Phil 2012/6/27 Stéphane Ducasse <stephane.ducasse@inria.fr>
James
sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
On Jun 27, 2012, at 9:24 AM, phil@highoctane.be wrote:
Stephane,
Wow, there is a limit to your utter awesomeness... Take care!
On this namespace thing... Well, in fact, I found that nice with Java but at the end of the day, what matters is the modular bit. And we have that with packages and MC. We do no need the namespaces really. Prefixing the classes works and scales. Look at any Obj-C app, there are prefixes everywhere.... and it works well.
No having this additional level makes Pharo much more approachable for new people. And in order to get traction, this is important.
yes this is why we have camille (a master student student that is turning modules around in presence of class extensions and trying to see what would be the best solution) now we should finish what we started. Finishing is more difficult. Stef
Phil
2012/6/27 Stéphane Ducasse <stephane.ducasse@inria.fr> James
sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Yes, finishing things up is the hardest part. It is also the part that makes people and great art remembered. As I wrote yesterday on Twitter: Execution is everything. Ideas are nothing. I should add: and everything gets better with late binding :-p Phil 2012/6/27 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Jun 27, 2012, at 9:24 AM, phil@highoctane.be wrote:
Stephane,
Wow, there is a limit to your utter awesomeness... Take care!
On this namespace thing... Well, in fact, I found that nice with Java but at the end of the day, what matters is the modular bit. And we have that with packages and MC. We do no need the namespaces really. Prefixing the classes works and scales. Look at any Obj-C app, there are prefixes everywhere.... and it works well.
No having this additional level makes Pharo much more approachable for new people. And in order to get traction, this is important.
yes this is why we have camille (a master student student that is turning modules around in presence of class extensions and trying to see what would be the best solution) now we should finish what we started. Finishing is more difficult.
Stef
Phil
2012/6/27 Stéphane Ducasse <stephane.ducasse@inria.fr> James
sorry but I'm at home stopped for 10 days because of a burnout (linked
partly to pharo and the business I want to spawn for the community).
We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
OT: Late binding rocks! On Wed, Jun 27, 2012 at 4:46 AM, phil@highoctane.be <phil@highoctane.be>wrote:
Yes, finishing things up is the hardest part. It is also the part that makes people and great art remembered.
As I wrote yesterday on Twitter: Execution is everything. Ideas are nothing.
I should add: and everything gets better with late binding :-p
Phil
2012/6/27 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Jun 27, 2012, at 9:24 AM, phil@highoctane.be wrote:
Stephane,
Wow, there is a limit to your utter awesomeness... Take care!
On this namespace thing... Well, in fact, I found that nice with Java but at the end of the day, what matters is the modular bit. And we have that with packages and MC. We do no need the namespaces really. Prefixing the classes works and scales. Look at any Obj-C app, there are prefixes everywhere.... and it works well.
No having this additional level makes Pharo much more approachable for new people. And in order to get traction, this is important.
yes this is why we have camille (a master student student that is turning modules around in presence of class extensions and trying to see what would be the best solution) now we should finish what we started. Finishing is more difficult.
Stef
Phil
2012/6/27 Stéphane Ducasse <stephane.ducasse@inria.fr> James
sorry but I'm at home stopped for 10 days because of a burnout (linked
partly to pharo and the business I want to spawn for the community).
We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil@highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be
High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
-- Germán Leiva LeivaGerman@gmail.com
Germán Leiva wrote
OT: Late binding rocks!
Yes, and the latest binding would be to lookup at runtime. I have no idea what the performance hit would be, or if we would use all that power, but the idea is exciting :) -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4636978.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 27/06/12 18:05, Sean P. DeNigris wrote:
Germán Leiva wrote
OT: Late binding rocks!
Yes, and the latest binding would be to lookup at runtime. I have no idea what the performance hit would be, or if we would use all that power, but the idea is exciting :)
With proper caching at VM level, the performance overhead would be negligible. Typically, when a class is accessed, something like PUSH_GLOBAL insn is generated. One may change semantics of this insns to do a proper message send back, effectively doing something like (for instance) self class resolveGlobalByName: globalName This is very flexible and allows for very nice tricks. This can be further performance-optimized. One may use a sort of an inline cache keeping a pair - function pointer to a function that returns desired value and a "cached data". Initially, the function would be initialized to a function that calls back smalltalk code like the one above. However, the smalltalk code __may__ decide that the resolution is "stable" (i.e., next time the code runs, same class should be returned) and fill the cache. The standard smalltalk resolve method then would look like resolveGlobalByName: globalName cache: cache | v | v := Smalltalk at: v cache bindTo: v where the cache is Smalltalk reflection object representing this kind-of-inline cache. When properly JITed, the cost of global access would the same as before (except of the very first one) - ideally just one memory fetch. Cheers, Jan
-- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4636978.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Jan Vrany-3 wrote
With proper caching at VM level, the performance overhead would be negligible.
Good to know. Thanks! -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4637018.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Late binding, yes. But please stop using "Global" word :) The Global word pins you to a little piece of dust floating in gazillion times bigger space. Think about it every time you think you found solution, which requires having some "global" state/functionality in your model. :) On 27 June 2012 19:47, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 27/06/12 18:05, Sean P. DeNigris wrote:
Germán Leiva wrote
OT: Late binding rocks!
Yes, and the latest binding would be to lookup at runtime. I have no idea what the performance hit would be, or if we would use all that power, but the idea is exciting :)
With proper caching at VM level, the performance overhead would be negligible.
Typically, when a class is accessed, something like PUSH_GLOBAL insn is generated. One may change semantics of this insns to do a proper message send back, effectively doing something like (for instance) Â self class resolveGlobalByName: globalName
This is very flexible and allows for very nice tricks.
This can be further performance-optimized. One may use a sort of an inline  cache keeping a pair - function pointer to a function that returns desired value and a "cached data". Initially, the function would be initialized to a function that calls back smalltalk code like the one above. However, the smalltalk code __may__ decide that the resolution is "stable" (i.e., next time the code runs, same class should be returned) and fill the cache. The standard smalltalk resolve method then would look like
resolveGlobalByName: globalName cache: cache  | v |  v := Smalltalk at: v  cache bindTo: v
where the cache is Smalltalk reflection object representing this kind-of-inline cache. When properly JITed, the cost of global access would the same as before (except of the very first one) - ideally just one memory fetch.
Cheers, Jan
-- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4636978.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
I want to second Stef's word. Coming from C++ world with namespaces at some point i felt like i really miss that. But my practice shows that what i miss is not a mere syntactic sugar or tool support of having multiple namespaces. No. What i miss is the true modular system, where modules are first-class components of it and know how to connect and interact between each other. If you look at the problem at this angle, you will see that being able to define own binding of some name(s) local to the module scope is just a tiny bit of a larger picture. -- Best regards, Igor Stasenko.
Stef, I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist. Best wishes, James On Jun 27, 2012, at 12:08 AM, Stéphane Ducasse wrote:
James
sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
On Jun 27, 2012, at 4:44 PM, James Foster wrote:
Stef,
I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist.
yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. Now for 20 we should finish all the open tracks we have. Stef
Best wishes,
James
On Jun 27, 2012, at 12:08 AM, Stéphane Ducasse wrote:
James
sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
On Jun 27, 2012; 4:27pm, Stephane Ducasse wrote:
On Jun 27, 2012, at 4:44 PM, James Foster wrote:
Stef,
I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist.
yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. Now for 20 we should finish all the open tracks we have.
Stef
Hi, A comment from a complete outsider: I've been following pharo on the side for the last year or so and am very impressed by both smalltalk as a language and pharo as an implementation. I am not trying to even voice an opinion of what's right to focus on for pharo project since that's not my place having nothing invested in it (so far, gearing up to add some pharo parts to my world). It did strike me that it could be interesting to hear the view from an outsider on what would draw interest and more users/developers to the project. Be it inspiration for pharo 2.1 or 3.0 or 4.0 :) I'll first state a belief: I believe that the explosive growth of ruby and python communities to some extent depended on good package management systems making it very easy for people to publish/share/collaborate on packages. A killer app to kick it off, but one needs easy collaboration to grow. On the back of that I'm very excited to see the following pharo efforts being close to coming together into something great: 1. Stripped down core kernel and bootstrap project 2. Fuel for fast serialization and deserialization (can be used for binary packages) 3. FileTree 4. Metacello scripting API 5. Metacella Git/Github integration 6. Tools such as Versionner on top of Metacello for ease of use 7. Namespaces/Environments In terms of getting a lot of people much more comfortable diving into the image world I think that list have great promise. If one can easily start with a minimal kernel, have some simple tooling such that one from e.g. the commandline can bootstrap it via Metacello configurations that pulls in both the parts of the base system one needs and project/application dependencies to get a working image for both development and deployment (via metacello groups for example) it has 2 benefits: 1. Reproducible process which means automation and testing a lot easier for projects (jenkins etc for applications), as well as deployment 2. It's a workflow that's quite similar to how one would for example work with ruby, rubygems and bundler (on a high level). Familiarity draws in more people - it shouldn't be at the cost of a good system, but if one can get both it's a definite positive. Once project/appliation bootstrapped like that and one is working in the image tools like Versionner and Metacello with git/github intregration will provide an excellent workflow for collaboration (push/pull/merge/branch/etc). Again I see 2 benefits: 1. Functionally solid (see e.g. the Practical Git for Smalltalk presentation by Dale) 2. It's familiar to outsiders and has a good chance of attracting new people. Even if one has great in image tooling it's very good to be able to be a "lazy" follower of a package/project via e.g. github (RSS feeds for changes, nice diffs accessible from any web browser, pull requests, graphical representation of branches etc etc). I for example would be much more likely to have learnt more on pharo implementation if I could have followed it on github for the last year. When collaboration increases and people share a lot of packages via e.g. git & github one tend to see exponential reuse and number of new packages created (on the back of what exists), and at least the ruby experience is the average number of package dependencies for a project increases. It's in that point of view I'm seeing namespaces/environments as an important addition. Prefixing names is doable and at a non-human level you can accomplish most of the same things, but on a human level I see it as important - and it gets more important the more collaboration and reuse of existing packages one accomplishes. A non-technical consideration is that developers these days kind of expects some form of namespacing to exist and not seeing it available is something to deter some possible adopters (rightly or wrongly, many times they wouldn't need namespaces/environments, but many may not reflect too deeply on that). I know I twigged at first seeing prefixing being used instead of some form of namespaces.
From that this perspective (namespaces/environments more important as more people are, reuse and collaboration happens) it seems quite sensible to put it after the other things on the todo list (as long as it doesn't goes away completely).
Hopefully that's of some interest :) I'll continue my journey towards using pharo more - we shall see how it works out for me! Regards, Patrik -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4639158.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stef, Thanks for taking time at ESUG to listen and learn more about our namespace proposal. I believe that we have cleared up some of the misconceptions surrounding this complex topic. James On Jun 27, 2012, at 8:27 AM, Stéphane Ducasse wrote:
On Jun 27, 2012, at 4:44 PM, James Foster wrote:
Stef,
I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist.
yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. Now for 20 we should finish all the open tracks we have.
Stef
Best wishes,
James
On Jun 27, 2012, at 12:08 AM, Stéphane Ducasse wrote:
James
sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
Great. And what is the conclusion? :) Doru On Mon, Sep 24, 2012 at 5:57 PM, James Foster <Smalltalk@jgfoster.net> wrote:
Stef,
Thanks for taking time at ESUG to listen and learn more about our namespace proposal. I believe that we have cleared up some of the misconceptions surrounding this complex topic.
James
On Jun 27, 2012, at 8:27 AM, Stéphane Ducasse wrote:
On Jun 27, 2012, at 4:44 PM, James Foster wrote:
Stef,
I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist.
yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. Now for 20 we should finish all the open tracks we have.
Stef
Best wishes,
James
On Jun 27, 2012, at 12:08 AM, Stéphane Ducasse wrote:
James
sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. And yes I read the implementation two years ago. Finally did you see the list of topics that I mention? - do you want to help in any of them to make pharo better? because we have to get them first and I need all my energy for them.
Stef
On Jun 27, 2012, at 12:25 AM, James Foster wrote:
On Jun 26, 2012, at 12:51 PM, Stéphane Ducasse wrote:
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 still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods.
Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"?
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:
Is it your impression that Germán's implementation requires this? If so, on what do you base that understanding? Have you looked at the code?
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.
I still don't know what you mean by "class level import" or why you think Germán's implementation fits your definition.
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.
By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime?
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.
Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug.
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.
By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened?
If I want both, at the module import level I write
Import: Point from: core as: CorePoint; import: Point from: dev as: DevPoint;
What object implements #'import:from:as:'?
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.
You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean.
I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required.
If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)?
What I understand from your statements so far is that Germán's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it?
Thanks for engaging in the discussion.
James Foster
-- www.tudorgirba.com "Every thing has its own flow"
BTW we want to finish what we are doing before opening new actions.
Since Colin opened a new thread on Squeak-dev about namespaces together with an implementation for environments:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html
I thought it would be good to ask on Pharo too about the state.
What happened to the project from Germán Leiva http://www.youtube.com/watch?v=n4I7fSVNX2A
I know it is always a time issue - but what is the overall plan?
Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Hi Torsten, I'm not glad to say this but the *current* status of the project is ... dead. The project's intention was to be a space/frame to develop an agreed implementation of namespaces using *Environments* as a starting point; but that never happened. If Collin or anyone wants to share some thoughts about this implementation or just chitchat I'm fully available. Despite this - I share all the questions raised by James - If Stephane wants to share efforts to bring an implementation of namespaces/modules that satisfies his desires but that have some alignment with the fundamental ideas of *Environments* I'm all ears ('really big ones') - Now that I have my engineer's degree (Yeay!) and I have some time to research I want to do some experiments that uses these kind of namespaces regardless his integration with Pharo (stay tuned) - I will check Collin's namespace implementation too Cheers On Tue, Jun 26, 2012 at 3:22 AM, Torsten Bergmann <astares@gmx.de> wrote:
Since Colin opened a new thread on Squeak-dev about namespaces together with an implementation for environments:y
http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html
I thought it would be good to ask on Pharo too about the state.
What happened to the project from Germán Leiva http://www.youtube.com/watch?v=n4I7fSVNX2A
I know it is always a time issue - but what is the overall plan?
Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
-- Germán Leiva LeivaGerman@gmail.com
participants (13)
-
camille teruel -
Frank Shearar -
Germán Leiva -
Igor Stasenko -
James Foster -
Jan Vrany -
Patrik Sundberg -
phil＠highoctane.be -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse -
Torsten Bergmann -
Tudor Girba