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.
