:: Separator in class names
Hi, due to the absence of a namespace solution we today often prefix classes with one, two or three letters. You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid conflicting names. I would like to have a "::" separator within the class name to better distinguish the class name from the prefix and increase readability at the same time. SmalltalkMT had this solution in alignment with C++ and I really liked working with it. So much that I would like to see it in Pharo too - maybe also as a base for future Namespace additions. So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to allow and support the :: notation for classes. After that I can create classes like: Seaside::Component Core::Boolean Model::Person GLM::BrickListModel Tx::FontAttribute so far without any problem. Do you think - there will be places where this conflicts or creates hazzles (tools, metacello, ...) - if it would be a good idea to add this to the default image? Thanks for feedback. Thx T. -------------------------------------------------------------------------------------------------- isValidGlobalName self ifEmpty: [ ^ false ]. "reserverd default names" self = 'NameOfSubclass' ifTrue: [ ^ false ]. self = 'TNameOfTrait' ifTrue: [ ^ false ]. (self occurrencesOf: $:) = 2 ifTrue: [ ^(self splitOn: '::') allSatisfy: [: part | part isValidGlobalName ] ]. ^ Character supportsNonASCII ifTrue: [ (self first isLetter and: [self first isUppercase]) and: [ self allSatisfy: [:character | character isAlphaNumeric or: [ character = $_ ]]]] ifFalse: [ (self first between: $A and: $Z) and: [ self allSatisfy: [:character | (character between: $a and: $z) or: [ (character between: $A and: $Z) or: [ (character between: $0 and: $9) or: [ character = $_]]]]]]
This thread has a huge discussion potential :) *grabs popcorn* On 8 December 2016 at 01:47, Torsten Bergmann <astares@gmx.de> wrote:
Hi,
due to the absence of a namespace solution we today often prefix classes with one, two or three letters. You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid conflicting names.
I would like to have a "::" separator within the class name to better distinguish the class name from the prefix and increase readability at the same time. SmalltalkMT had this solution in alignment with C++ and I really liked working with it. So much that I would like to see it in Pharo too - maybe also as a base for future Namespace additions.
So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to allow and support the :: notation for classes. After that I can create classes like:
Seaside::Component Core::Boolean Model::Person GLM::BrickListModel Tx::FontAttribute
so far without any problem.
Do you think - there will be places where this conflicts or creates hazzles (tools, metacello, ...) - if it would be a good idea to add this to the default image?
Thanks for feedback.
Thx T.
------------------------------------------------------------ -------------------------------------- isValidGlobalName
self ifEmpty: [ ^ false ].
"reserverd default names" self = 'NameOfSubclass' ifTrue: [ ^ false ]. self = 'TNameOfTrait' ifTrue: [ ^ false ].
(self occurrencesOf: $:) = 2 ifTrue: [ ^(self splitOn: '::') allSatisfy: [: part | part isValidGlobalName ] ].
^ Character supportsNonASCII ifTrue: [ (self first isLetter and: [self first isUppercase]) and: [ self allSatisfy: [:character | character isAlphaNumeric or: [ character = $_ ]]]] ifFalse: [ (self first between: $A and: $Z) and: [ self allSatisfy: [:character | (character between: $a and: $z) or: [ (character between: $A and: $Z) or: [ (character between: $0 and: $9) or: [ character = $_]]]]]]
Aliaksei Syrel
This thread has a huge discussion potential :) Â Yes - I know it has :)
And it comes up from time to time ... mostly fading away. Nonetheless I like to trigger it again. So far we have not made much progress on that frontier and - even when we do not have a full, perfect or portable namespace solution changing the current restriction what a "valid global name" means (see method #isValidGlobalName) could help in exploring that area more deeply. Having at a minimum support for a scope like separator (I would suggest to use "::") would allow to experiment with it from Pharo 6.0 onwards.
*grabs popcorn*
Why do you just want to be part of the audience instead of telling us what you think? Thanks T.
Torsten, Because of the obvious portability problems this would introduce, I would think that an attempt should be made to come up with a common namespace solution ... I do believe that some discussion about namespace alternatives has taken place between GemStone and Pharo --- not familiar with details or outcome of discussions, but I would like to think that at least an attempt was made to come up with a common solution before resorting to a unilateral solution that would only introduce more isolation between the various dialects --- something that a small community cannot really afford to do ... Dale On 12/07/2016 04:47 PM, Torsten Bergmann wrote:
Hi,
due to the absence of a namespace solution we today often prefix classes with one, two or three letters. You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid conflicting names.
I would like to have a "::" separator within the class name to better distinguish the class name from the prefix and increase readability at the same time. SmalltalkMT had this solution in alignment with C++ and I really liked working with it. So much that I would like to see it in Pharo too - maybe also as a base for future Namespace additions.
So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to allow and support the :: notation for classes. After that I can create classes like:
Seaside::Component Core::Boolean Model::Person GLM::BrickListModel Tx::FontAttribute
so far without any problem.
Do you think - there will be places where this conflicts or creates hazzles (tools, metacello, ...) - if it would be a good idea to add this to the default image?
Thanks for feedback.
Thx T.
-------------------------------------------------------------------------------------------------- isValidGlobalName
self ifEmpty: [ ^ false ].
"reserverd default names" self = 'NameOfSubclass' ifTrue: [ ^ false ]. self = 'TNameOfTrait' ifTrue: [ ^ false ].
(self occurrencesOf: $:) = 2 ifTrue: [ ^(self splitOn: '::') allSatisfy: [: part | part isValidGlobalName ] ].
^ Character supportsNonASCII ifTrue: [ (self first isLetter and: [self first isUppercase]) and: [ self allSatisfy: [:character | character isAlphaNumeric or: [ character = $_ ]]]] ifFalse: [ (self first between: $A and: $Z) and: [ self allSatisfy: [:character | (character between: $a and: $z) or: [ (character between: $A and: $Z) or: [ (character between: $0 and: $9) or: [ character = $_]]]]]]
Dale wrote:
Because of the obvious portability problems this would introduce, I would think that an attempt should be made to come up with a common namespace solution ...
I'm not sure about the current namespace solutions existing today in vendor driven Smalltalks. You and me were participants in the first CampSmalltalk in San Diego in 2000 with many others trying to get the Smalltalk's closer which was already hard at that time because of the many dialects and differences (VW, VAST, Gemstone, Squeak, ST/MT, Dolphin, ...) Some of this work influenced todays Smalltalk world with frameworks and tools. Today Smalltalks shares not only basic core classes but also a common unit framework and similar test runners, have code exchange and formats, even a framework like Seaside could somehow be managed "portable". But there was not much success in REALLY aligning all the proprietary solutions regarding class libraries, common behavior of methods, tools, UI or even frameworks. You cant file out, file in and just run. Because we have different pragma solutions, different foreign function interfaces, different way of building tools ... even differences on compiler and meta level. So "portability problems" are already a reality for many other reasons. Dont get me wrong. I'm all ears if you see a way to build a "common" or "portable" route for unified namespace solution, but to make this a reality: - commercial vendors would have to see a need for (another) portable solution - would need to invest into this topic with time and resources - would have to jump onto the "open" and MIT licensed bandwagon to share with open source Smalltalks like Squeak and Pharo - would have to adopt their own solutions to a new portable one - you would need to get all the different interests under one umbrella Which I doubt such a thing will happen because vendors already have own proprietary existing namespace solutions. Even when this would be possible they would have to invest in explaining this to their customers who also would need to migrate from existing vendor namespace solutions. This thread is not about Namespaces, just about an optional separator in global names. So independent from the reasons to start this thread I doubt we will ever find a path to a unified namespace solution. You can call me a pessimist in this regard, even in having a short-term common namespace solution for Pharo, Squeak and Cuis.
something that a small community cannot really afford to do
Community is not big ... but growing. At least from what I see in open source Smalltalks like Squeak, Pharo, Cuis, ... with new community members, ideas, frameworks, books, unifying VM, ... We would continue to be a small community if our world would have stopped and kept the things the way they were defined initially in ST. I would not like to imagine the size of the overall ST community without the fresh air of these open source Smalltalks. Maybe I'm mistaken but so far Pharo is already the one who EXPLORES new routes with Traits, Slots, MetaLinks, OpalCompiler, ... often these are already "non-portable". So while you can use them if you are in need of them you should stay away from them if you have portability to other Smalltalks in mind. Right? This does not solve the portability issue but provides freedem: because you can share with other Smalltalks if necessary - but also allows you to follow new paths, use slots and other. But back to the topic: ====================== Please do not misunderstood my orginal post: I DONT want to have or discuss a new and perfect namespace solution now as an outcome here. Usually when similar threads were discussed we only agreed that this never gets reality. ;) I JUST want to change the single method #isValidGlobalName to be MORE FLEXIBLE and to allow for an EXPLICIT and OPTIONAL SEPARATOR IN GLOBAL NAMES. Nothing less but also nothing more. So this is about an optional separator in global names, not about a full namespace solution. By allowing such a separator anyone (including me) who feels the need to experiment or try out new paths can then play with it: - maybe just for readability to write prefixed classes like this "KillerApp::Window" - maybe just to avoid conflicts as with a better separated prefix ("MyKillApp::Person" vs. "YouKillerApp::Person") - maybe to experiment with having two versions of a class inside of the image "OldVersion::MyClass" and "NewVersion::MyClass" - maybe because you want to import/map namespace from other languages like Java/.NET/C++/... to it (like mapping Java to Pharo as org::apache::commons::lang::StringUtils and so on) to experiment with Pharo as a multilanguage engine or experiment in a better JNIPort - maybe because you want to map different platform facilities or libraries ("Common::Window", "Windows::Window", "OSX::Window", "GTK::Window", ...) - maybe to provide useful shadow classes that are not visible by default in regular tools ("Shadows::Object", "Shadows::Boolean", ...) - maybe to be able to import and separate classes from different Smalltalk systems ("VW::Object", "VAST::Object", ...) - and yes: maybe also to do initial experiments towards a future portable or non-portable namespace solution - ... - [ADD YOUR OWN IDEAS HERE] So anything I want is a single and small step forward: the possibility in Pharo 6 for global names to allow a COMPLETELY OPTIONAL separator without having to "dirty patch" the method #isValidGlobalName in the base image. So if one wants to write regular code or even portable code and code that is traditional, working with all tools he could and should stay away from this OPTIONAL separator possibility. Nothing changes on the usual Pharo and Smalltalk side, you can code and share as before. But if one feels the need to use such a possibility for own custom stuff or experiments it is there and one can use it. I feel a very strong need on my side for such experiments because I would like to explore new grounds with it. I can patch/overwrite the method in my custom images - but this is not so clean and nice. Pharo should give this freedom out of the box and I hope that you agree with me. Maybe others have similar ideas and want to experiment as well. Thats why I opened this thread - if the community supports the idea and shares similar visions I will open a bug, provide a slice and we include it. In my opinion it opens new opportunities. If community disagrees and it will not become part of the base image out of the box (or only as part of a full namespace solution) I will continue patching my custom images. I'm fine with that as well - but then at least I tried to get this in. Thanks T.
I like that :: idea for structuring the global space. What I would refrain from is to into the Java style packages/classloaders/Jigsaw/OSGi thing. So, that is not what you are after, so that is good. Having a smaller number of well working libraries that we refine feels superior to a myriad of ad hoc things put together. I'd rather have more advanced access mechanisms (and let go of any compatibility with other Smalltalks) in order to have a poweful environment to develop in. We do have a system, so, the focus should be on mechanisms and on the "Pharo way to solve problems" than on compatibility. For example, I'd better have a way to write code using other syntaxes and getting compiled into Pharo code and then in bytecode in order to express higher order things. Compatibility is only going to glue us to the blue plane. Phil On Thu, Dec 8, 2016 at 12:30 PM, Torsten Bergmann <astares@gmx.de> wrote:
Dale wrote:
Because of the obvious portability problems this would introduce, I would think that an attempt should be made to come up with a common namespace solution ...
I'm not sure about the current namespace solutions existing today in vendor driven Smalltalks. You and me were participants in the first CampSmalltalk in San Diego in 2000 with many others trying to get the Smalltalk's closer which was already hard at that time because of the many dialects and differences (VW, VAST, Gemstone, Squeak, ST/MT, Dolphin, ...)
Some of this work influenced todays Smalltalk world with frameworks and tools. Today Smalltalks shares not only basic core classes but also a common unit framework and similar test runners, have code exchange and formats, even a framework like Seaside could somehow be managed "portable".
But there was not much success in REALLY aligning all the proprietary solutions regarding class libraries, common behavior of methods, tools, UI or even frameworks. You cant file out, file in and just run.
Because we have different pragma solutions, different foreign function interfaces, different way of building tools ... even differences on compiler and meta level. So "portability problems" are already a reality for many other reasons.
Dont get me wrong. I'm all ears if you see a way to build a "common" or "portable" route for unified namespace solution, but to make this a reality:
- commercial vendors would have to see a need for (another) portable solution - would need to invest into this topic with time and resources - would have to jump onto the "open" and MIT licensed bandwagon to share with open source Smalltalks like Squeak and Pharo - would have to adopt their own solutions to a new portable one - you would need to get all the different interests under one umbrella
Which I doubt such a thing will happen because vendors already have own proprietary existing namespace solutions. Even when this would be possible they would have to invest in explaining this to their customers who also would need to migrate from existing vendor namespace solutions.
This thread is not about Namespaces, just about an optional separator in global names. So independent from the reasons to start this thread I doubt we will ever find a path to a unified namespace solution. You can call me a pessimist in this regard, even in having a short-term common namespace solution for Pharo, Squeak and Cuis.
something that a small community cannot really afford to do
Community is not big ... but growing. At least from what I see in open source Smalltalks like Squeak, Pharo, Cuis, ... with new community members, ideas, frameworks, books, unifying VM, ...
We would continue to be a small community if our world would have stopped and kept the things the way they were defined initially in ST. I would not like to imagine the size of the overall ST community without the fresh air of these open source Smalltalks.
Maybe I'm mistaken but so far Pharo is already the one who EXPLORES new routes with Traits, Slots, MetaLinks, OpalCompiler, ... often these are already "non-portable". So while you can use them if you are in need of them you should stay away from them if you have portability to other Smalltalks in mind. Right?
This does not solve the portability issue but provides freedem: because you can share with other Smalltalks if necessary - but also allows you to follow new paths, use slots and other.
But back to the topic: ====================== Please do not misunderstood my orginal post: I DONT want to have or discuss a new and perfect namespace solution now as an outcome here. Usually when similar threads were discussed we only agreed that this never gets reality. ;)
I JUST want to change the single method #isValidGlobalName to be MORE FLEXIBLE and to allow for an EXPLICIT and OPTIONAL SEPARATOR IN GLOBAL NAMES. Nothing less but also nothing more. So this is about an optional separator in global names, not about a full namespace solution.
By allowing such a separator anyone (including me) who feels the need to experiment or try out new paths can then play with it:
- maybe just for readability to write prefixed classes like this "KillerApp::Window" - maybe just to avoid conflicts as with a better separated prefix ("MyKillApp::Person" vs. "YouKillerApp::Person") - maybe to experiment with having two versions of a class inside of the image "OldVersion::MyClass" and "NewVersion::MyClass" - maybe because you want to import/map namespace from other languages like Java/.NET/C++/... to it (like mapping Java to Pharo as org::apache::commons::lang::StringUtils and so on) to experiment with Pharo as a multilanguage engine or experiment in a better JNIPort - maybe because you want to map different platform facilities or libraries ("Common::Window", "Windows::Window", "OSX::Window", "GTK::Window", ...) - maybe to provide useful shadow classes that are not visible by default in regular tools ("Shadows::Object", "Shadows::Boolean", ...) - maybe to be able to import and separate classes from different Smalltalk systems ("VW::Object", "VAST::Object", ...) - and yes: maybe also to do initial experiments towards a future portable or non-portable namespace solution - ... - [ADD YOUR OWN IDEAS HERE]
So anything I want is a single and small step forward: the possibility in Pharo 6 for global names to allow a COMPLETELY OPTIONAL separator without having to "dirty patch" the method #isValidGlobalName in the base image.
So if one wants to write regular code or even portable code and code that is traditional, working with all tools he could and should stay away from this OPTIONAL separator possibility. Nothing changes on the usual Pharo and Smalltalk side, you can code and share as before.
But if one feels the need to use such a possibility for own custom stuff or experiments it is there and one can use it. I feel a very strong need on my side for such experiments because I would like to explore new grounds with it. I can patch/overwrite the method in my custom images - but this is not so clean and nice. Pharo should give this freedom out of the box and I hope that you agree with me.
Maybe others have similar ideas and want to experiment as well. Thats why I opened this thread - if the community supports the idea and shares similar visions I will open a bug, provide a slice and we include it. In my opinion it opens new opportunities.
If community disagrees and it will not become part of the base image out of the box (or only as part of a full namespace solution) I will continue patching my custom images. I'm fine with that as well - but then at least I tried to get this in.
Thanks T.
On 12/08/2016 03:30 AM, Torsten Bergmann wrote:
Dale wrote:
Because of the obvious portability problems this would introduce, I would think that an attempt should be made to come up with a common namespace solution ... I'm not sure about the current namespace solutions existing today in vendor driven Smalltalks. You and me were participants in the first CampSmalltalk in San Diego in 2000 with many others trying to get the Smalltalk's closer which was already hard at that time because of the many dialects and differences (VW, VAST, Gemstone, Squeak, ST/MT, Dolphin, ...)
Some of this work influenced todays Smalltalk world with frameworks and tools. Today Smalltalks shares not only basic core classes but also a common unit framework and similar test runners, have code exchange and formats, even a framework like Seaside could somehow be managed "portable".
But there was not much success in REALLY aligning all the proprietary solutions regarding class libraries, common behavior of methods, tools, UI or even frameworks. You cant file out, file in and just run.
Because we have different pragma solutions, different foreign function interfaces, different way of building tools ... even differences on compiler and meta level. So "portability problems" are already a reality for many other reasons.
Dont get me wrong. I'm all ears if you see a way to build a "common" or "portable" route for unified namespace solution, but to make this a reality:
- commercial vendors would have to see a need for (another) portable solution - would need to invest into this topic with time and resources - would have to jump onto the "open" and MIT licensed bandwagon to share with open source Smalltalks like Squeak and Pharo - would have to adopt their own solutions to a new portable one - you would need to get all the different interests under one umbrella
Which I doubt such a thing will happen because vendors already have own proprietary existing namespace solutions. Even when this would be possible they would have to invest in explaining this to their customers who also would need to migrate from existing vendor namespace solutions. Well I believe that GemStone is open to discussing and possibly implementing alternate non-proprietary namespace solutions and I can't speak for other vendors ... This thread is not about Namespaces, just about an optional separator in global names. So independent from the reasons to start this thread I doubt we will ever find a path to a unified namespace solution. You can call me a pessimist in this regard, even in having a short-term common namespace solution for Pharo, Squeak and Cuis. ... the question is not whether or not you are or are not a pessimist, but do you care about portability ... if you care then don't go off implementing language features that create portability headaches without giving other platforms a chance to participate in the solution
something that a small community cannot really afford to do Community is not big ... but growing. At least from what I see in open source Smalltalks like Squeak, Pharo, Cuis, ... with new community members, ideas, frameworks, books, unifying VM, ... And the problem that Smalltalk has had from almost the beginning of time and one that costs a lot of effort for all community members is that we do not have a common source code format and we do not have a "standard library definition". Developers in the ruby community do not spend any time at all porting frameworks from one ruby platform to another ruby platform and we Smalltalkers spend a significant amount of time porting packages between platforms and platform versions ...
Introducing additional incompatibilities without attempting to coordinate between platforms just creates a bigger burden.
We would continue to be a small community if our world would have stopped and kept the things the way they were defined initially in ST. I would not like to imagine the size of the overall ST community without the fresh air of these open source Smalltalks.
I don't believe that I'm saying "don't do this"...
Maybe I'm mistaken but so far Pharo is already the one who EXPLORES new routes with Traits, Slots, MetaLinks, OpalCompiler, ... often these are already "non-portable". So while you can use them if you are in need of them you should stay away from them if you have portability to other Smalltalks in mind. Right?
Wrong ... I am not saying anything like that .. Traits are something that we at GemStone have considered adding to our product ... but recently I recall Steph saying something to the effect of "Traits aren't worth doing" or something ... Now this could have been Steph just sounding off, but until that comment we were seriously considering adding Traits to GemStone 3.4 ... sadly it will not make it into 3.4 now ... I have always been in favor of Pharo pushing the language forward, but when it comes to something fundamental like adding "namespace like features" to global names --- because it is easy to do --- I pipe up and ask that a little bit more thought and cross platform discussion be put into th problm
This does not solve the portability issue but provides freedem: because you can share with other Smalltalks if necessary - but also allows you to follow new paths, use slots and other.
and in the spirit of sharing I think it is worth a discussion ...
But back to the topic: ====================== Please do not misunderstood my orginal post: I DONT want to have or discuss a new and perfect namespace solution now as an outcome here. Usually when similar threads were discussed we only agreed that this never gets reality. ;)
I JUST want to change the single method #isValidGlobalName to be MORE FLEXIBLE and to allow for an EXPLICIT and OPTIONAL SEPARATOR IN GLOBAL NAMES. Nothing less but also nothing more. So this is about an optional separator in global names, not about a full namespace solution.
If these option features are not used, then we don't have a portability problem :) I am not the namespace expert --- I do know that if Pharo introduces this option unilaterally and it is used, it will cause portability issues ....
By allowing such a separator anyone (including me) who feels the need to experiment or try out new paths can then play with it:
- maybe just for readability to write prefixed classes like this "KillerApp::Window" - maybe just to avoid conflicts as with a better separated prefix ("MyKillApp::Person" vs. "YouKillerApp::Person") - maybe to experiment with having two versions of a class inside of the image "OldVersion::MyClass" and "NewVersion::MyClass" - maybe because you want to import/map namespace from other languages like Java/.NET/C++/... to it (like mapping Java to Pharo as org::apache::commons::lang::StringUtils and so on) to experiment with Pharo as a multilanguage engine or experiment in a better JNIPort - maybe because you want to map different platform facilities or libraries ("Common::Window", "Windows::Window", "OSX::Window", "GTK::Window", ...) - maybe to provide useful shadow classes that are not visible by default in regular tools ("Shadows::Object", "Shadows::Boolean", ...) - maybe to be able to import and separate classes from different Smalltalk systems ("VW::Object", "VAST::Object", ...) - and yes: maybe also to do initial experiments towards a future portable or non-portable namespace solution - ... - [ADD YOUR OWN IDEAS HERE]
Frankly I am interested in hearing the opinions of the namespace experts on these ideas ...
So anything I want is a single and small step forward: the possibility in Pharo 6 for global names to allow a COMPLETELY OPTIONAL separator without having to "dirty patch" the method #isValidGlobalName in the base image.
So if one wants to write regular code or even portable code and code that is traditional, working with all tools he could and should stay away from this OPTIONAL separator possibility. Nothing changes on the usual Pharo and Smalltalk side, you can code and share as before.
But if one feels the need to use such a possibility for own custom stuff or experiments it is there and one can use it. I feel a very strong need on my side for such experiments because I would like to explore new grounds with it. I can patch/overwrite the method in my custom images - but this is not so clean and nice. Pharo should give this freedom out of the box and I hope that you agree with me.
Maybe others have similar ideas and want to experiment as well. Thats why I opened this thread - if the community supports the idea and shares similar visions I will open a bug, provide a slice and we include it. In my opinion it opens new opportunities.
If community disagrees and it will not become part of the base image out of the box (or only as part of a full namespace solution) I will continue patching my custom images. I'm fine with that as well - but then at least I tried to get this in. Dale
First of all: happy new year to all Pharo supporters! Not many of you answered this thread in 2016. Maybe I have more luck in 2017 ;) So please tell me about the requested change of #isValidGlobalName to allow an optional separator in class names. I already communicated possible usages and still do not share the fears of Dale that we easily get unportable code with that. I guess it will allow us to experiment much easier. Thanks for taking the time to response and share your own thoughts! Bye Torsten
Am 02.01.2017 um 12:57 schrieb Torsten Bergmann <astares@gmx.de>:
First of all: happy new year to all Pharo supporters!
Not many of you answered this thread in 2016. Maybe I have more luck in 2017 ;)
So please tell me about the requested change of #isValidGlobalName to allow an optional separator in class names. I already communicated possible usages and still do not share the fears of Dale that we easily get unportable code with that. I guess it will allow us to experiment much easier.
If we allow it now what would be the scenario rolling that back? Taking it away again seems to be much harder. My gut feeling tells me this would be a change we will regret later. Norbert
Thanks for taking the time to response and share your own thoughts!
Bye Torsten
+100 I do not think that there should be restrictions on the number of :: separators. Modified to allow #A::B::Object etc.. ------------------------------- isValidGlobalName self ifEmpty: [ ^ false ]. "reserverd default names" self = #NameOfSubclass ifTrue: [ ^ false ]. self = #TNameOfTrait ifTrue: [ ^ false ]. (self splitOn: '::') allSatisfy: [: part | Character supportsNonASCII ifTrue: [ (part first isLetter and: [ part first isUppercase]) and: [ part allSatisfy: [:character | character isAlphaNumeric or: [ character = $_ ]]] ] ifFalse: [ (part first between: $A and: $Z) and: [ part allSatisfy: [:character | (character between: $a and: $z) or: [ (character between: $A and: $Z) or: [ (character between: $0 and: $9) or: [ character = $_]]]]] ] ] ------------------------------------- As long as the :: only serve as a visual separator between "namespace(s)" and class name then it should not be harder much more harder than to do a #copyReplaceAll: '::' with: '' when filing in|out the class to use in a system that do not allow :: in class names. Best regards, Henrik -----Opprinnelig melding----- Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Torsten Bergmann Sendt: 02 January 2017 12:57 Til: Pharo Development List <pharo-dev@lists.pharo.org> Emne: Re: [Pharo-dev] :: Separator in class names First of all: happy new year to all Pharo supporters! Not many of you answered this thread in 2016. Maybe I have more luck in 2017 ;) So please tell me about the requested change of #isValidGlobalName to allow an optional separator in class names. I already communicated possible usages and still do not share the fears of Dale that we easily get unportable code with that. I guess it will allow us to experiment much easier. Thanks for taking the time to response and share your own thoughts! Bye Torsten
Hi all! On 01/02/2017 02:16 PM, Henrik Nergaard wrote:
+100
I do not think that there should be restrictions on the number of :: separators. Modified to allow #A::B::Object etc..
Just wanted to mention that ... I am amused! :) My Namespace implementation in Squeak from a bunch of years back used this notation. And I am also using it in Spry, but as syntactic sugar for Dictionary access so that: aDict at: #x ...can be expressed as: aDict::x regards, Göran
We are working on a module system. When it will be ready we will mention it. Stef On Thu, 08 Dec 2016 02:39:36 +0100, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Torsten,
Because of the obvious portability problems this would introduce, I would think that an attempt should be made to come up with a common namespace solution ...
I do believe that some discussion about namespace alternatives has taken place between GemStone and Pharo --- not familiar with details or outcome of discussions, but I would like to think that at least an attempt was made to come up with a common solution before resorting to a unilateral solution that would only introduce more isolation between the various dialects --- something that a small community cannot really afford to do ...
Dale
On 12/07/2016 04:47 PM, Torsten Bergmann wrote:
Hi,
due to the absence of a namespace solution we today often prefix classes with one, two or three letters. You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid conflicting names.
I would like to have a "::" separator within the class name to better distinguish the class name from the prefix and increase readability at the same time. SmalltalkMT had this solution in alignment with C++ and I really liked working with it. So much that I would like to see it in Pharo too - maybe also as a base for future Namespace additions.
So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to allow and support the :: notation for classes. After that I can create classes like:
Seaside::Component Core::Boolean Model::Person GLM::BrickListModel Tx::FontAttribute
so far without any problem.
Do you think - there will be places where this conflicts or creates hazzles (tools, metacello, ...) - if it would be a good idea to add this to the default image?
Thanks for feedback.
Thx T.
-------------------------------------------------------------------------------------------------- isValidGlobalName
self ifEmpty: [ ^ false ].
"reserverd default names" self = 'NameOfSubclass' ifTrue: [ ^ false ]. self = 'TNameOfTrait' ifTrue: [ ^ false ].
(self occurrencesOf: $:) = 2 ifTrue: [ ^(self splitOn: '::') allSatisfy: [: part | part isValidGlobalName ] ].
^ Character supportsNonASCII ifTrue: [ (self first isLetter and: [self first isUppercase]) and: [ self allSatisfy: [:character | character isAlphaNumeric or: [ character = $_ ]]]] ifFalse: [ (self first between: $A and: $Z) and: [ self allSatisfy: [:character | (character between: $a and: $z) or: [ (character between: $A and: $Z) or: [ (character between: $0 and: $9) or: [ character = $_]]]]]]
-- Using Opera's mail client: http://www.opera.com/mail/
participants (8)
-
Aliaksei Syrel -
Dale Henrichs -
Göran Krampe -
Henrik Nergaard -
Norbert Hartl -
phil＠highoctane.be -
stepharong -
Torsten Bergmann