Thanks for the reply and for your explanation and Pharo's position on
this idea and on the subject of namespaces and modules. I was simply
offering a solution that was presented at Smalltalks conference.
My use of Pharo is in the small. I do not in general see or know the
problems associated with namespaces. I may see consequences in other
people's software I use in Pharo because of the naming of classes. But
it is them that dealt with the problem. I am very unqualified to comment
or address either of these issues. I just didn't know who had seen the
video and if it offered a solution or not. Thank you for engaging the
conversation so that we have a position on record regarding a publicly
available video which offers their view on a solution. You addressed one
of the things I do love about Pharo and its expressed goals is that it
seeks to offer real working solutions. I am okay that the hard things
take time, and am happy that they are being addressed even if it takes
some time. Pharo is shaping up very nicely.
Thanks.
Jimmie
On 10/20/2017 04:07 AM, Stephane Ducasse wrote:
For the record at ESUG at Prague there was a really interesting
discussion about namespace and some people working with newspeak
mentioned that the namesapce there was a hell. And I trust these
people. So good luck.
For the record we are working and we are making progress on module
system for Pharo but as I explained at ESUG this year. We do not want
just to have a namespace. We want a system that does not kill the live
programming experience.
Imagine you have two browsers opened:
- in N3 one one you inherit from a class A import from N1
- then in N1 you decide to move that class A to N2
Should the system discard all the subclasses from A n N3 because it
cannot find anymore the class A?
This is why we are working on
- during year we remove harcoded reference to Smalltalk
- Undefined classes (read the IWST 2017 paper)
- new class definition
- model for class definition
- real life programming supporting module system.
So each time I hear about namespace, I think that the best way to get
a namespace system for Pharo is to help doing something else.
This way we can concentrate on building a real working solution for
Pharo. But since we have many other things to do then it takes time.
Stef
On Fri, Oct 20, 2017 at 2:30 AM, Jimmie Houchin <jlhouc...@gmail.com> wrote:
Absolutely. I have contemplated giving it a try. But when I go look at the
mailing list, it looks like such a lonely place. I still might give it a go.
It looks interesting.
Jimmie
On 10/19/2017 05:20 PM, Ben Coman wrote:
btw, are you aware that Newspeak is developed on top of the CogVM that
Pharo, Squeak, Cuis all share?
cheers -ben
On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouc...@gmail.com>
wrote:
I watched this video a year ago and was intrigued. I have not thought
about it deeply and do not know consequences of this model. However, Gilad
is a smart man who has thought deeply about these things and has experienced
consequences as a language designer. But it does sound interesting and I
wonder if it would potentially be a solution to the namespace or modularity
problems.
https://youtu.be/pM0Hz4pFDZM
He is talking about Newspeak in 2016 and what I refer to is its use of
Nested Classes.
No Global Namespace
No Global Variables
No Pool Variables
No Class Variables
No Class Instance Variables
I have no idea if it would work for Pharo or what would be involved in
implementing such. Or even if the community or leaders would even care to
explore that direction. I have not seen it discussed here.
Just wanted to toss his discussion of these ideas into the arena of ideas
for Pharo.
Jimmie
On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote:
2017-10-13 5:55 GMT-03:00 Norbert Hartl <norb...@hartl.name>:
Am 13.10.2017 um 10:24 schrieb stephan <step...@stack.nl>:
On 13-10-17 09:55, Thierry Goubier wrote:
Because namespaces, by essence, come with serious issues. I won't take
someone seriously on namespaces until he can cite those faithfully.
Let's start with the misconception that namespaces are about
modularisation
+1
+1 to this as well.
Having modularization is like having security, very hard to add them
later if you didn't include it in the original design.
I'm using VisualWorks these days, and I find its namespaces something
more of a hassle than a real use.
If we could name Classes with a dot, that could solve most of what
namespaces are used for in practice: avoiding name colissions.
That's why most of the popular frameworks have prefixes like Zn, WA,
RB, and so on and so forth. But now I'm used to prefixes, I don't need
them. :)
Modularity is a different beast, if you look at how some modules work
in JS, like AMD, you see that in practice they avoid collisions by
importin what they need from a module, and assign it to a "namespace"
(it is not, but works as such), so they get modules first, and
namespacing later.
Regards,
Esteban.
