headers
Ramon Leon | 1 Dec 01:15

RE: Squeak and Namespaces

> Hi Ramon!
> 
> I just have to say: Thank you, thank you, thank you. :)
> 
> Really. I mean it. You seem to understand my solution perfectly.
> Sometimes I get the feeling I am insane. :)

No problem, it seems a simple elegant solution that solves 99% of my
frustrations without changing the feel of Smalltalk.

Ramon Leon
http://onsmalltalk.com
Permalink | Reply | 0 comments |
headers
Brian Rice | 1 Dec 07:19
Favicon

Re: [ANN] SqueakMap Package Loader new release

Release 1.13 (consider the previous as 1.10) is out which fixes  
backwards compatibility with older Squeaks, at least back to 3.6,  
incorporates an alternative UI, and presents in the "open..." menu  
some shorter entries:

SqueakMap Catalog -> the package loader
SqueakMap Categories -> the alternative UI

The alternative UI is based on Bijan Parsia's older "Categorical SM  
Package Loader" which has been available on SqueakMap since 2002 and  
has been broken for some time. I have left a relevant note on that  
package's description.

Known Issues:
- The ToolBuilder-based package loader still has the bug that the  
search pane does not update the package list selection.

On Nov 26, 2006, at 2:55 PM, Brian Rice wrote:

> This release (1.1) puts together a number of small improvements to  
> the SqueakMap package loader UI and is available now on SqueakMap.
>
> Improvements:
> - Installed packages and releases are now marked in bold.
> - Searching now also uses the description field.
> - All of the main features of the app are now in a visible button bar.
> - ToolBuilder support is used if available. This means two mostly- 
> identical UIs, but that it will retain compatibility with Squeak  
> versions pre-3.9.
> - The search bar is more obviously labeled.
(Continue reading)

Permalink | Reply | 2 comments |
headers
J J | 1 Dec 07:28
Picon

Re: Squeak and Namespaces


>From: Göran Krampe <goran <at> krampe.se>
>Reply-To: goran <at> krampe.se, The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev <at> lists.squeakfoundation.org>
>Subject: Re: Squeak and Namespaces
>Date: Thu, 30 Nov 2006 09:45:56 +0100 (CET)
>
>Hi!
>
>Yes, and let me here note that in my solution ALL references to globals
>are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in
>the SOURCE. Sorry for the caps, but this is VERY important to realize.
>

I think I understand your solution pretty well.  Unless I am missing 
something it is pretty simple:  You allow :: in the class name.  If it's 
there it is used.  If the Class at the end (e.g. NS::OtherNS::Class) is 
unique on it's own in the system then that is all that shows up in your 
source.  If not, then every place that is ambiguous gets explicitly written 
out by the compiler.  Right?

I appreciate all that you have went through to do something about this, and 
I'm sure you have fought this battle many times.

But here is what I see personally:
- The way it works today seems good enough.  I know we are all prefixing our 
stuff, but that doesn't seem that bad.  Maybe it's because I have only done 
smaller projects so far so I am not strong on this point, I will take the
(Continue reading)

Permalink | Reply | 4 comments |
headers
J J | 1 Dec 07:32
Picon

Re: Squeak and Namespaces


+1.  Good points.

>From: brad fowlow <fowlow <at> pacbell.net>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>Subject: Re: Squeak and Namespaces
>Date: Thu, 30 Nov 2006 02:56:22 -0800
>
>
>On Nov 30, 2006, at 1:52 AM, Göran Krampe wrote:
>
>>Note that you don't get penalized in my solution - BUT if you  spread your
>>package as open source (to lots of other users) then you will  inevitably
>>"pullute" our shared namespace of common short names. We want to be  very
>>careful about that pollution - because it muddles our brains.
>
>But that -is- a penalization, especially since it works both ways;  you 
>pollute me also.
>The overall point of the exercise is to facilitate wide sharing and  reuse 
>of code,
>so that's the basis of evaluation...  one measure of success is how  
>thoroughly
>protected we are from everyone else's naming choices.
>
>Those short names are pollution only because of the nature of the  
>solution.
>If I have to consider carefully whether or not to use a short name  for
(Continue reading)

Permalink | Reply | 6 comments |
headers
J J | 1 Dec 07:53
Picon

Re: Squeak and Namespaces

>From: Göran Krampe <goran <at> krampe.se>
>Reply-To: goran <at> krampe.se, The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev <at> lists.squeakfoundation.org>
>Subject: Re: Squeak and Namespaces
>Date: Thu, 30 Nov 2006 13:04:00 +0100 (CET)
>
>In some sense yes. :) But I tried getting the subtle differences across -
>like that the name of MCDictionary is not its short name with my solution
>being in - it is the fully qualified name.
>
>So there is AFAICT no difference from the current state - when we have
>MCDictionary.

Yes, but here is the difference I see:  Right now we have MCDictionary (ok 
we probably don't, but as an example) and Dictionary.  When I see 
MCDictionary, no problem, I know its for MC.  And when I see Dictionary I 
know it's a pure dictionary.  But with your solution, yes it stays like now 
*for the moment*.  But you made this to get used.  Which means the MC people 
will want to change MCDictionary to MC::Dictionary.  What happens then?  
MC::Dictionary gets only slightly (to my eyes) uglier, but now all my uses 
of Dictionary become Kernel::Dictionary.  Right?  That's what I don't want.  
I realize I don't have to *type* it, but I don't want to *see* it.  It is 
line noise for me.

>I agree. And yes, there is a cost. But people seem to think that we have
>these choices:
>
>2. Adding my solution now that gives us Namespaces that don't seem so
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michel Bany | 1 Dec 08:28
Picon

Re: Squeak and Namespaces


>> PS: I have been working with VW recently and I really found 
>> namespaces getting in my way all the time. Also the integration of 
>> namespaces
>> in VW is badly supported at the refactoring level and other tools. So 
>> this is often a pain.
>
> I agree with Andreas and Stef.
> Working with Seaside in VW right now, I can find 3 (three!) "versions" 
> of Date in VW (Core.Date, Squeak.Date and Seaside.Date)!
> It kind of sucks to have to extend Seaside.Date with date method 
> extensions already existing for Core.Date for this local shop.
>
> Maybe namespaces of VW helped to get seaside ported to VW at all, but 
> I'd prefer to have an ongoing desire to unify classes, which _are_ 
> intended to work the same.
These 3 Date classes are the result of difficult design decisions.

1) Seaside uses Duration, DateAndTime, Year, Month, Week, and maybe a 
few other that are part of so-called Chronology.
These classes are not available in VW.
2) I was lazy and rather than re-implementing Chronology in VW, I ported 
the Chronology package to VW.
3) Porting Chronology from Squeak to VW created name clashes for Date 
and Time classes. VW namespaces
helped here with Core.Date and Squeak.Date, Core.Time and Squeak.Time. 
Note that there is no clash for
Timestamp (TimeStamp in Squeak) and for Timezone (TimeZone in Squeak).
4) Now that I had two different classes for Date and two different 
classes for Time, I had to decide which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Göran Krampe | 1 Dec 08:49
Picon
Gravatar

Re: Squeak and Namespaces

Hi!

>>From: Göran Krampe <goran <at> krampe.se>
>>Yes, and let me here note that in my solution ALL references to globals
>>are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in
>>the SOURCE. Sorry for the caps, but this is VERY important to realize.
>>
>
> I think I understand your solution pretty well.  Unless I am missing
> something it is pretty simple:  You allow :: in the class name.  If it's
> there it is used.  If the Class at the end (e.g. NS::OtherNS::Class) is

No - I don't allow nested spaces. Only one level.

> unique on it's own in the system then that is all that shows up in your
> source.  If not, then every place that is ambiguous gets explicitly
> written
> out by the compiler.  Right?

Yes - but note that the SOURCE always contains the full name. Only the
*rendering* of that source in the browser decides whether to show the
prefixes or not.

I hooked into a low level spot for that and I think it works in all
browsers except the method version browser - need a special fix for that
one.

> I appreciate all that you have went through to do something about this,
> and
> I'm sure you have fought this battle many times.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Göran Krampe | 1 Dec 08:59
Picon
Gravatar

Re: Squeak and Namespaces

Hi!

>>From: Göran Krampe <goran <at> krampe.se>
>>In some sense yes. :) But I tried getting the subtle differences across -
>>like that the name of MCDictionary is not its short name with my solution
>>being in - it is the fully qualified name.
>>
>>So there is AFAICT no difference from the current state - when we have
>>MCDictionary.
>
> Yes, but here is the difference I see:  Right now we have MCDictionary (ok
> we probably don't, but as an example) and Dictionary.  When I see
> MCDictionary, no problem, I know its for MC.  And when I see Dictionary I
> know it's a pure dictionary.  But with your solution, yes it stays like
> now
> *for the moment*.  But you made this to get used.  Which means the MC
> people
> will want to change MCDictionary to MC::Dictionary.  What happens then?
> MC::Dictionary gets only slightly (to my eyes) uglier, but now all my uses
> of Dictionary become Kernel::Dictionary.  Right?  That's what I don't
> want.

As I posted a minute ago - no, it would stay Dictionary.

>>I agree. And yes, there is a cost. But people seem to think that we have
>>these choices:
>>
>>2. Adding my solution now that gives us Namespaces that don't seem so
>>impressive to all the language scientists (hey, no imports? It must
>> suck).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Göran Krampe | 1 Dec 09:24
Picon
Gravatar

Re: Squeak and Namespaces

Hi!

(should have replied to Brad, but for technical reasons I don't have the
original posting available)

>>From: brad fowlow <fowlow <at> pacbell.net>
>>On Nov 30, 2006, at 1:52 AM, Göran Krampe wrote:
>>
>>>Note that you don't get penalized in my solution - BUT if you  spread
>>> your
>>>package as open source (to lots of other users) then you will
>>> inevitably
>>>"pullute" our shared namespace of common short names. We want to be
>>> very
>>>careful about that pollution - because it muddles our brains.
>>
>>But that -is- a penalization, especially since it works both ways;  you
>>pollute me also.
>>The overall point of the exercise is to facilitate wide sharing and
>> reuse
>>of code,
>>so that's the basis of evaluation...  one measure of success is how
>>thoroughly
>>protected we are from everyone else's naming choices.
>>
>>Those short names are pollution only because of the nature of the
>>solution.
>>If I have to consider carefully whether or not to use a short name  for
>>something
>>because it's a pain in the ass when someone else does too,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Klaus D. Witzel | 1 Dec 09:37

Why I like to see Squeak namespaces on Swiki pages

Hi folks,

I think that now can be the time for attacking the namespace thread from  
the opposite direction :)

Let's assume now and here that syntax and semantics of the given proposal  
is adopted. Then we still face the implication of possible name clash (and  
of course, as always, lack of not-bytecoded documentation).

Somewhere in the namespaces thread it was mentioned that root (?) names  
are maintained on a Wiki (in VW? anyone any hyperlink?). Now, because I  
very much like exposing the symbolic (all global names and their  
components' names in namespace) interface of Squeak to search engines, I  
suggest we make structured Swiki pages for Squeak namespaces, so that the  
next Squeak convert is able to find such manifests (from google, krugle,  
etc) and click the presented hyperlinks to arrive at the respective  
project (download) page.

I hereby volunteer to create and maintain Squeak's namespaces Swiki pages.  
I do so because at around 3.6 I rediscovered Squeak and was really  
disappointed when I didn't find any class names and system category names  
organized and served for www consumption.

I do not anticipate much work for me, because nothing much namespaceable  
exists today in Squeak. And if system categories where decided to be part  
of the then official namespaces, then a very small number of statements in  
a workspace will just kick them in.

Since it cannot be expected that everybody rewrites her/his source code  
just because it can now reference namespaces, the amount of organizational
(Continue reading)

Permalink | Reply | 2 comments |

Gmane