[Squeakland] Alternate realities, anyone?

Bert Freudenberg bert at impara.de
Wed Nov 2 02:24:36 PST 2005


Hi Joshua,

what you propose is known in Computer Science as "Name Spaces", which  
allows you to call several things by the same name depending on  
context. In fact, there exists at least one implementation of name  
spaces for Squeak. It's actually not even that complex because of  
Smalltalk's powerful programming model, its late-bound nature makes  
those things much simpler than in other systems. A similar experiment  
was done with "isolated projects", where you could redefine classes  
in the system from inside a project, and when leaving that project,  
the changes were undone.

However, the best place to dicuss those ideas would be the Squeak  
developers mailing list (see http://squeak.org/Community/). That is  
where he Squeak "programmers" hang out. On this list we rather  
discuss Squeak as a Media Authoring Tool, mostly using the Etoys  
environment rather than Smalltalk, to, as Alan puts it, “Making the  
invisible a little more visible” via helping children learn powerful  
ideas by building them [*].

See you there!

- Bert -

[*] http://squeakland.org/pdf/etoys_n_learning.pdf

Am 02.11.2005 um 09:27 schrieb Joshua Fein:

> ALTERNATE reality
>
> Doing this right would be extremely technical, in
> terms of abilities required to implement.  I myself do
> not yet possess that ability, and in truth have only a
> limited desire to discuss the pro & cons of the idea.
>
> Successful implementation would involve re-thinking
> what happens when a class gets re-defined, a very
> complex, system-level task. "Categories" would have to
> be viewed as more fundamental units, perhaps.  Another
> tier, "Alternates" above "Category" might resolve the
> problem.  Have to think about this more.  Having it
> mesh with the current "world" "project" scheme would
> be a plus, only that is so complicated!
>
> ALTERNATE worldS
>
> --->right now the categories are only place-holders,
> 'comments' they do not have any effect on the system
> itself.
> --->right now, when a class with an existing name is
> reentered under a new category,
>     it is removed, and it's unique methods added to
> the class entered under the new category.
>
> --->I was proposing that a change be made so that:
>
> --->Classes may have the same names but be in
> different categories.
> 	depending on what 'world' or 'project' ('alternate'
> flagged world) you are in, the class
> 	being referred to may be in one category or another.
> ---> only complex when 'active' i.e. there are two
> worlds which use the same class name but defined
>     under different categories.  Otherwise the Squeak
> environment would look just like it does now.
> ---> idea similar to versioning but applicable to the
> application environment.
>
>
> start with this example:
>
> You have a class SlideShowMorph under the
> classification SlideAuditor.
> You have another, differently defined SlideShowMorph
> under the classification SlideShow.
>
> When smalltalk reads the second classification,
> SlideShow, it creates a 'project' or 'world' for which
> that definition of SlideShowMorph is valid (and ...
>
> 	a) an entry "SlideShow" in another level above
> 'category'
> 	('Alternates'... unless 'Universe' behavior could be
> modified?) or
> 	b) maybe as another kind of category?  ("SlideShow"
> the 'Alternate' flagged category) or
> 	c) a special flag on the the class itself?  (the
> 'Alternate' flagged SlideShowMorph) or
> 	d) All of the above?
>
> At the 'top' level, only the minimal set (In this
> case, all classes in the current version of smalltalk,
> since none of them conflict) , of the non-conflicting
> classes are accessible.
>
> to access the conflicting classes, one has to be in
> one 'world' or another. (i.e. the "SlideAuditor"
> world if SlideShowMorph was included as part of the
> minimal set)
>
>
> ALTERNATE programming environments, ALTERNATE
> careers...
>
> The bottom line may be that smalltalk as it is defined
> in Squeak simply is not flexible enough to allow this
> sort of construct, that one would end up with a system
> that is a mere bastardization of itself, like the
> "objective" C environment I am currently trying to use
> on the Mac... which is still successful, because in
> Xcode/macland, it's still the only game in town (If ya
> wanna be a programmer, that is).
>
> the taxi drivers grumble, but hey,no mac programmers
> are complaining.
>
> So it COULD be done...
>
>
> IN A FUTURE LETTER: Why the taxi-drivers grumble, how
> to make squeak more consistent with itself.





More information about the Squeakland mailing list