Namespaces (was Re: [squeak-dev] re: Modularity)

Hey Craig,

On 2011/05/08 22:45, Casey Ransberger wrote:
> Hey Craig,
>
> Sounds really interesting. FWIW I like "named" namespaces because they
> make searching a codebase for dependencies easier. At the end of the
> day, one ends up with far less namespaces than one has classes, and in
> my own experience, that's a lot more manageable than what we have now.

I think Craig's point is that that name doesn't matter: what you call a
Foo in your image I might call a Foozle, even though it's the same
class/method/whatever.

> That said, I'll try anything once. I've seen a *wealth* of *great* ideas
> about how to do namespaces in Squeak... but I've only seen one working
> implementation, which is at present irksomely dependent on OmniBrowser
> -- something I don't see in a kernel image. Is the approach suggested in
> your paper something I can currently download and install? It looks like
> Naiad means I'd have to give up my .sources and .changes files, is this
> correct? I might do that if I got namespaces back in exchange. I will
> spend some time reading your paper tonight:)

Craig, while you're explaining that, could you expand a bit on the
modularity aspects of Spoon? I get the versioning, and the
lack-of-name-prevents-name-clash, but I don't see yet how it addresses
controlling dependencies between large chunks of code.

It's my firmly held opinion that it's better to open your mouth only to
change feet - as long as you learn something each time - than to never
open your mouth.

So, by analogy, I think it's better to implement things, even brain-dead
things that you have to rip out/apart - as long as you learn something
each time - than to sit and talk about what the perfect system might
look like, that would please everybody all the time.

frank

Hi Frank--

> I think Craig's point is that that name doesn't matter: what you call
> a Foo in your image I might call a Foozle, even though it's the same
> class/method/whatever.

     That's not what I was going for, but yes, you could do that. :)
The more likely scenario is, for example, what you and I both call a
Socket now are different things, or what you call a Socket in 2011 is
different than what you called a Socket in 1996.

> ...could you expand a bit on the modularity aspects of Spoon? I get
> the versioning, and the lack-of-name-prevents-name-clash, but I don't
> see yet how it addresses controlling dependencies between large
> chunks of code.

     What questions would you like to be able to ask of the system? In
the meantime, I'll try to illustrate what's possible.

     First, some background. Every method in the system has a
corresponding method edition. The method edition has a collection of
markers for each literal in the method. For a literal which is a
reference to a class, the literal marker can get the ID of the class.
The class ID uniquely identifies the precise class object that the
method is expecting to use, as well as the author of the definition of
that class. Method editions are similarly identified by method IDs.
Modules are essentially collections of method IDs, and may have other
modules as prerequisites. Every method in the system is described by a
module. Every module is described by an ID, and has a
search-engine-indexable URI describing how to get it.

     Now, some possibilities. For any set of modules, you can enumerate
the IDs of all the classes used by all the methods in those modules. For
any live class object, you can find the known modules refer to it (or
any earlier or later version). For any author, you can find the known
modules that use their work. You might use that information to decide
the component methods of a module, and its prerequisite relationships
with other modules.

> It's my firmly held opinion that it's better to open your mouth only
> to change feet - as long as you learn something each time - than to
> never open your mouth.

     :)

> So, by analogy, I think it's better to implement things, even
> brain-dead things that you have to rip out/apart - as long as you
> learn something each time - than to sit and talk about what the
> perfect system might look like, that would please everybody all the
> time.

     Just to be clear, I am implementing this, although I have to do it
in precious little stretches of so-far-unpaid time. And I'm not trying
to please everyone all the time, although I would like design feedback.
Finally, I've implemented and thrown away a bunch of other things to get
here. A few folks have tried them out and commented, too, and I'm very
thankful for that.


     thanks again,

-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547

Hi Casey--

> I've seen a *wealth* of *great* ideas about how to do namespaces in
> Squeak... but I've only seen one working implementation... Is the
> approach suggested in your paper something I can currently download
> and install?

     Yes: http://netjam.org/spoon/releases/current/.

     It's not finished, particularly with regard to what "download and
install" means. :)

> It looks like Naiad means I'd have to give up my .sources and
> .changes files, is this correct?

     No, you don't have to give them up (you could use them for the sake
of redundancy, for example), but it does give you something better, I think.

> I might do that if I got namespaces back in exchange.

     Well, you do get the freedom to name any class anything you want,
the ability to distinguish between different versions of each class, and
a means of organizing, discovering, and sharing code.

> I will spend some time reading your paper tonight :)

     Thanks!

> I guess I should just out and say it: I don't see a shortage of
> proposals around here, I see a shortage of consensus and a shortage of
> implementation.

     Indeed. As with most people, for me that follows directly from a
lack of resources (having to spend time on paid work). It's also an
ambitious project. I understand that most people will only be interested
in evaluating the ideas after I have managed to put the time into
implementing them, but I still think it's valuable to seek feedback from
the few who are interested before then, so I'm less likely to go off in
some completely ridiculous direction. At this point, I know very well
what I want from the system, but I'd like constant calibration with
others' desires through dialogue.

> I care less about what the approach is than I care about whether or
> not I can use it now, which I believe puts me in the minority on
> squeak-dev!

     Actually, that seems like the majority view to me. :)


     thanks again,

-C

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547

On 05/08/2011 11:45 PM, Casey Ransberger wrote:
Well, then you haven't seen mine that was implemented way back in... 2004:

        http://map.squeak.org/packagebyname/namespaces

...and I presume you didn't search SM for "Namespaces" or google it?

Read more here:

        http://swiki.krampe.se/gohu/27

...especially the "Prefixes Improved" article.

regards, Göran

PS. IMHO my solution is still really elegant compared to other proposals
I have seen. And with a bit more work it could easily do thing like
remappings of Namespaces etc - although since it is based on static
bindings (just like now) that would require "recompilation" but that
doesn't feel like such a big deal given those usecases.

You already cited Craig.
You could also explore http://gulik.pbwiki.com/Namespaces
You could see how other dialects did (VW, gst, stx, ...)
You could read about Newspeak proposals.

Nicolas

2011/5/9 Göran Krampe <[hidden email]>:

On 2011/05/09 22:47, Nicolas Cellier wrote:
> You already cited Craig.
> You could also explore http://gulik.pbwiki.com/Namespaces
> You could see how other dialects did (VW, gst, stx, ...)
> You could read about Newspeak proposals.

Especially http://lambda-the-ultimate.org/node/3544 which references
http://bracha.org/newspeak-modules.pdf

frank

Göran, I saw that it was there, but didn't know it was maintained. I will check it out. Thank you for making me aware of your work -- I'm like a kid in a candy store here!




--
Casey Ransberger