<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1>Yes, "namespaces" are a slippery slope that very quickly derives in all that... packages with inter-dependencies, simultaneously having different versions of a class or even its methods running in a single system, etc. Those are very hard issues and people have been working on that for a long time. I'm not sure I would want to solve those problems in Cuis anyways, it might be cool, it might also be complex and tedious, I don't know.<o:p></o:p><div><o:p> </o:p></div><div>The only problem I would like to solve is, given a package that defines *new* classes, loading it not globally in Smalltalk but locally in a new "SystemDictionary". Everything else is "out of scope" for me. So far, Environments looks very close to what I want. I'm not sure yet if it would work, or if it would have any side effect I'm not seeing... when I get some free time I'll try to port it as a Cuis package, and I'll see how it feels using it in my projects and maybe get a better understanding of the issues. But I certainly wouldn't want to implement some idea of "namespaces" in a hurry and integrate it in the base image.<o:p></o:p></div><div><o:p> </o:p></div><div>Mist and Newspeak are interesting but... I'm a Smalltalk-80 guy... I guess I'm a traditionalist after all... I'll look at them for ideas, tho.<o:p></o:p></div><div><o:p> </o:p></div><div>I'd like to hear what people like and dislike of other namespace systems. Did anyone ever use namespaces in VW? Is there something bad about them?<o:p></o:p></div><o:p> </o:p>I’m using VW almost exclusively since 1995, and I like the VW namespace implementation. It is not perfect, but life is better with than without it. You can import into a class’s scope all of a namespace (all classes and globals in it), several namespaces, or just those specific classes and global from certain specific namespace using some combination of specific names and asterisks. VW namespaces stay out of the way, and I’m happy with them. I moved to VW from Dolphin permanently around 1998 to get the namespaces and greater speed. (If Dolphin had namespaces and were fast, I would still be using it. I’ve never seen better code quality overall.)<o:p></o:p><o:p> </o:p>I’ve been trying to port to Pharo for about 13 years, and can’t mostly because of the general need to use Hungarian-prefixed class names (not really a big problem for me now because I don’t see any actual name collisions) and the endless problems I have not being able to resize fonts in Pharo and still have labels be readable. I’m not sure what will be done about that. I’ve written detailed descriptions of the font-resizing/string-in-GUI-truncation problems in Fogbugz, a few times, but I don’t see any progress on the issue. There are generally complexity and stability problems still with Pharo. The latest plain vanilla Pharo 3.0.7, for example, causes a file-related walkback on launch. (I tried to post the screenshot, but it was rejected. )<o:p></o:p><o:p> </o:p>Not sure what’s going on there, but don’t really have time to look into it. I installed it in a non-default folder. I suspect that’s the problem, but this should not be happening with an untouched install.<o:p></o:p><o:p> </o:p>I’ve considered a move to Cuis, but recall that there is no ability to use TT fonts, last time I checked. Has that changed?<o:p></o:p><o:p> </o:p>I would like to see a basic VW-style namespace system implemented in Cuis and Pharo as an intermediate solution. We need something better, granted, but we can script conversion of the old system to the new when we decide on a module system. <o:p></o:p> <o:p></o:p><o:p> </o:p>Cheers all,<o:p></o:p><o:p> </o:p>Shaping<o:p></o:p><o:p> </o:p><o:p> </o:p><div><div>On Tue, May 21, 2019 at 7:07 AM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<o:p></o:p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>... I forgot. But you may also want to review how the libc guys deal with backwards compatibility. There are tons of smart people "out there". It's not necessary to make everything from scratch again. On 5/20/19 23:58, Andres Valloud via Cuis-dev wrote: > I would look at Newspeak to get some ideas. I'm not so sure about the > nested class approach and the default message lookup scheme, but that > way of doing things has the benefit of having some serious thought > behind it. > > Before doing anything, however, one would have to think what's going to > happen when inevitably two packages that should be loaded depend on > different versions of a third package. Or what happens when package A > wants to use things from package B that have name collisions with > package A. And how to deal with overrides / redefinitions / > refinements. The etcetera list is longish. Also, one has to consider > how the end result feels, and how people are induced to collaborate as a > result. > > So for that, I'd look at Mist. > > None of these problems are easy, and the easy solutions one can think in > a day or so tend to have serious side effects that are not immediately > visible. Watch out for the temptation to do something before thinking > it through, in the end it causes more problems than it solves. > > On 5/13/19 05:21, Luciano Notarfrancesco via Cuis-dev wrote: >> Hi everybody, >> Every now and then I wish we had namespaces. What's the simplest >> namespace-like thing that could allows us to simultaneously load two >> packages with clashing class names? >> >> I've been thinking that it might be reasonable to make packages have >> independent namespaces. Nothing complex like VW's, just Smalltalk for >> the base image and then a global name in Smalltalk for each package >> namespace, and package classes are accessible via sending a message to >> its namespace. For example, if Morphic was an external package, >> loading it would create a namespace named #Morphic in Smalltalk, and >> the classes in the Morphic package would be compiled using this >> namespace instead of Smalltalk to lookup globals, and it would >> delegate lookups to Smalltalk if it doesn't know the requested keys. >> After loading the package you could use the class HandMorph directly >> within methods compiled in the Morphic package, but outside of it (in >> methods belonging to classes in the base image or in other packages) >> you would have to do >> Morphic at: #HandMorph >> or perhaps for convenience as a message like VW: >> Morphic HandMorph >> >> Has anyone attempted to do anything like this? I just looked around >> for five minutes and the impression I get is that it would be >> non-trivial, there are a lots of references to Smalltalk and probably >> a lot of subtleties to make all the tools work well. What do you think? >> >> Thanks, >> Luciano >> >> -- Cuis-dev mailing list <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><o:p></o:p></blockquote></div></div></body></html>