I am against the very idea of special syntax. Even python uses special syntax as nothing more than syntactic sugar to make the code more readable from the point of view of not everything looking the same. I agree with the concept of everything being an Object.
I also dont like the idea that we tend to not have a clear cut border between the IDE and the language/library. Of course I think IDE functionality as much as namespaces is concerned (within the borders of my understanding) is essential. But should be seperate and the IDE act mostly as a visualisation tool and automation tool. My problem , is that the Pharo operates on a global space , so lets say i do what I said above I still dont avoid name collisions. Because MyInstance outside MyModule should diffirent from MyInstance inside MyModule. It could become possible by masking the names from the user. So that there is no conflict between MyModule MyInstance and MyModule2 MyInstance unless you introduce of couse similar to python the optional feature of collapsing the scope. We already have Packages which tie in with Metacello, so I was think about Modules or however we want to call them as a layer between. I am fine with metacello personally. Its the name collisions that only concerns me and not forcing me to use unique names. Of course a module can contain other modules. I know how to do this for my projects , I would manipulate the IDE into displaying Modules as a seperate row in System Browswer , Packages will continue being the the up most container. And for name of a class I would add the name of the Module to the class , if I wanted to keep supporting the existing enviroment , but hack it so it appears to the user as 2 seperate things so for user will see MyModule MyInsance myMessage: but it Would be for the system MyModuleMyInstance myMessage: which would make sense from naming persepctive even to an outsider not using the module system and would not require for him to install the modue library and essentially MyModule MyInstance act as you said via Message not understood as a reference to MyModuleMyInstance . A unary message returning a reference to an instance or class or other object. of course you will have a class like ModuleGenerator to handle the technical details for you Version control , dependencies and other technicallities would be handled normally as usually by Metacello with MyModule pointing also to the correct configuration , baseline, whatever. At least thats my general idea of it. On Fri, Oct 13, 2017 at 2:16 PM Thierry Goubier <thierry.goub...@gmail.com> wrote: > Hi Kilon, > > then the discussion is a bit different. As your example points out, the > syntax is already there, but the notion of a module is still open and ties > into the package management. > > I've played a bit with Metacello to have a working "project" concept > synchronized with Metacello, and I could imagine providing module like > objects (the baseline itself?) giving access to more generic names instead > of the internal, prefixed ones. > > One suggestion maybe: what about trying it for yourself with one of your > projects? With a kind of overall class which has the name of the module, > and automatically adding methods to it (or a #doesNotUnderstand: that > handles those) for all the classes in the module, removing from the class > name the prefix? It would allow an experiment, to see how the code looks > like and if it is understandable, or if a special syntax is necessary. > > Thierry > > > 2017-10-13 11:51 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>: > >> to be more specific what I mean because apparently I may know nothing >> about namespaces , I was talking in terms of Python's module and package >> system >> >> even though python uses special syntax "import" to import a module, a >> source file, the real functionality is actually a method but of an object >> dealing with the handling of modules and packages , packages are basically >> file directories containing mutliple modules >> >> as soon as you do the import the syntax is the usual object syntax >> >> so >> >> Dog.bark() >> >> can be anything >> 1) A class method call, Dog being the class >> 2) A instance method call, Dog being the instance >> 3) or a function call, Dog being the function , which is also an object >> (methods in python are basically function object taking the reference to an >> instance as first argument, hence why the weird syntax of adding self as >> first argument when we define instance method) and Dog is the module >> imported. >> >> of course in case (3) you can collapse the module "name" so you can do >> only bark() if you import via "from Dog import *" which means from module >> Dog import every object. >> But from import is frown upon in the python world because obviously it >> makes it easier to have name collision which is what the module system try >> to avoid in the first place. >> >> So the equivelant of pharo would be >> >> MyModule MyInstance myMessage: >> >> or if you include packages as well >> >> MyPackage MyModule MyInstance myMessage: >> >> which follows pharo syntax and OO design. That's my general idea at least. >> >> Please enlighten me :) >> >> On Fri, Oct 13, 2017 at 12:30 PM Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> >>> On Fri, Oct 13, 2017 at 11:31 AM Thierry Goubier < >>> thierry.goub...@gmail.com> wrote: >>> >>>> 2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>: >>>> >>>>> fair enough you think namespaces are not the right solution, what you >>>>> think is the right solution then ? >>>>> >>>> >>>> I told you. Namespaces are a solution, but they come with issues. >>>> >>>> >>> >>> Then I misunderstood you but I am geniouly interested in what those >>> problems are and I think the infromation is something others will find >>> interesting as well. >>> >>> No. In the HPC world, a common held position is that Fortran code is 30% >>>> faster than C++. >>>> >>> >>> Cannot even rememeber the last time a 3d graphics developers mentioned >>> Fortran.I occasional frequent forums and mailing lists plus keeping in >>> contact with Blender developers. >>> >>> I have heard that Fortran can outperform C++ in numeric computation >>> around the percentage you mentioned but first time I heard that its >>> generally faster. >>> >>> Language Benchmark seems to strongly disagree >>> >>> >>> http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ifc&lang2=gpp >>> >>> of its widely criticized but then what benchmark is not >>> >>> >>>> Remember that part of my job is to write compilers. >>>> >>>> >>> I knew that you write compilers (SmaCC) I did not realise you are a pro >>> and especially on ones that generate highly optimised machine code >>> >>> >>>> I'm also consider a guy to talk to when someone has deep issues with >>>> some of the new features of C++... even if I don't do C++, I can often >>>> reframe what the feature means in the overall scheme of programming >>>> languages. >>>> >>> >>> On other hand I have close to zero experience on compilers >>> . >>> >>> >>>> I find it very interesting. I consider that current compilers are very >>>> good optimising code that is written in a language that obscures the >>>> developper intent in the first place. >>>> >>> >>> I lost you there, you mean compilers for other languages than C++ ? >>> >>> As I told you, I work in a world where performance is paramount and C++ >>>> is strongly criticized for the fact its incidental complexity makes it very >>>> very hard to reach or maintain performance levels (compared to Fortran, >>>> say). >>>> >>>> Thierry >>>> >>>> >>> >>> And I "work" in a world that C++ is the undisputed king , that's 3d >>> graphics , though I must admit I try to stick with Python as much as I can. >>> >>> In any case my point was that if namespaces can be done in a badly >>> design language , should be possible in Pharo and easier. Not ease, just >>> easier. >>> >>> Of course that's just a wild assumption but I hope this thread do not >>> only disaprove my assumption but said a light in the real challanges of >>> namespace implementation >>> >>> >
