Environments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Environments

Colin Putney-3
Hi all,

There's an old joke in the Squeak community about how we have a flame
war about namespaces every few years and only newbies bring up the
topic casually. Well, it seems we're overdue, so I'd like to do my bit
for the community by keeping up the tradition.

I propose that Squeak 4.4, or perhaps 4.5, include support for more
than one class with the same name. This will be a modest proposal,
based on extending Dan's work on environments. The basic idea is this:
an Environment is an object that implements a policy for binding names
to objects during compilation.

This is in direct contrast to the Namespace implementation that
VisualWorks uses. In VW the global namespace is divided up into a
dot-delimited hierarchy, and there are mechanisms for resolving
unqualified names. Environments, in contrast, are more like Newspeak
modules. There's no universal mapping of names to objects, but rather
different "points of view," where names resolve differently depending
on which environment you're in.

The simplest and most common use for environments is to allow two
classes with the same name to peacefully co-exist. We currently work
around this problem with classname prefixes - MC in Monticello or WA
in Seaside. With environments, we can do away with prefixes by
creating a separate environment for each prefix that we're currently
using.

An interesting example of this case that I've run across lately is
Xtreams. In the original VW version, there's only one class that's
publicly visible: the Incomplete exception that gets raised when a
stream operation fails. The rest of the public API to the library is
provided as extensions to classes in the base system. There's actually
no need for code that uses Xtreams to refer to any of the stream
classes. That leaves a lot of room for the implementation of Xtreams
to change while keeping the API stable, and I'd like to be able to
take advantage of this design in Squeak. With Environments, that's
possible: we just create an environment to hold the Xtreams classes,
import the base system, compile Xtreams, export Incomplete, and import
Xtreams into our application's environment.

I've done a preliminary implementation, which lets me create an empty
environment, file code into it and then browse and modify it with a
standard browser. There's still lots of work to do, but I want to get
a consensus among the core developers before tackling it. That way the
changes can happen in the trunk and we don't have to worry about a
difficult integration later.

I've attached a couple of screenshots. The first shows two browsers,
one browsing the base image, the other browsing an environment with
Seaside 3.0 loaded. The second is an explorer on the Seaside
environment. The image where they were taken is available for download
here:

   http://www.wiresong.ca/downloads/Environments.zip


Flame away!

Colin



Browsers.png (70K) Download Attachment
Explorer.png (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Environments

Andreas.Raab
Wow. Best approach I've seen so far. Ever. Simple, direct, to the point.
In particular after looking at the code - it is complete enough to be practically
useful, yet simple enough so that things can be changed if they don't work
out in the way expected. People who don't like it can completely ignore it,
people who want to use it have something to work with. It's just like having
your cake and eating it, too :-)

I would use it.

Cheers,
  - Andreas


Colin Putney-3 wrote
Hi all,

There's an old joke in the Squeak community about how we have a flame
war about namespaces every few years and only newbies bring up the
topic casually. Well, it seems we're overdue, so I'd like to do my bit
for the community by keeping up the tradition.

I propose that Squeak 4.4, or perhaps 4.5, include support for more
than one class with the same name. This will be a modest proposal,
based on extending Dan's work on environments. The basic idea is this:
an Environment is an object that implements a policy for binding names
to objects during compilation.

This is in direct contrast to the Namespace implementation that
VisualWorks uses. In VW the global namespace is divided up into a
dot-delimited hierarchy, and there are mechanisms for resolving
unqualified names. Environments, in contrast, are more like Newspeak
modules. There's no universal mapping of names to objects, but rather
different "points of view," where names resolve differently depending
on which environment you're in.

The simplest and most common use for environments is to allow two
classes with the same name to peacefully co-exist. We currently work
around this problem with classname prefixes - MC in Monticello or WA
in Seaside. With environments, we can do away with prefixes by
creating a separate environment for each prefix that we're currently
using.

An interesting example of this case that I've run across lately is
Xtreams. In the original VW version, there's only one class that's
publicly visible: the Incomplete exception that gets raised when a
stream operation fails. The rest of the public API to the library is
provided as extensions to classes in the base system. There's actually
no need for code that uses Xtreams to refer to any of the stream
classes. That leaves a lot of room for the implementation of Xtreams
to change while keeping the API stable, and I'd like to be able to
take advantage of this design in Squeak. With Environments, that's
possible: we just create an environment to hold the Xtreams classes,
import the base system, compile Xtreams, export Incomplete, and import
Xtreams into our application's environment.

I've done a preliminary implementation, which lets me create an empty
environment, file code into it and then browse and modify it with a
standard browser. There's still lots of work to do, but I want to get
a consensus among the core developers before tackling it. That way the
changes can happen in the trunk and we don't have to worry about a
difficult integration later.

I've attached a couple of screenshots. The first shows two browsers,
one browsing the base image, the other browsing an environment with
Seaside 3.0 loaded. The second is an explorer on the Seaside
environment. The image where they were taken is available for download
here:

   http://www.wiresong.ca/downloads/Environments.zip


Flame away!

Colin
Reply | Threaded
Open this post in threaded view
|

Re: Environments

Frank Shearar-3
In reply to this post by Colin Putney-3
On 26 June 2012 03:11, Colin Putney <[hidden email]> wrote:

> Hi all,
>
> There's an old joke in the Squeak community about how we have a flame
> war about namespaces every few years and only newbies bring up the
> topic casually. Well, it seems we're overdue, so I'd like to do my bit
> for the community by keeping up the tradition.
>
> I propose that Squeak 4.4, or perhaps 4.5, include support for more
> than one class with the same name. This will be a modest proposal,
> based on extending Dan's work on environments. The basic idea is this:
> an Environment is an object that implements a policy for binding names
> to objects during compilation.
>
> This is in direct contrast to the Namespace implementation that
> VisualWorks uses. In VW the global namespace is divided up into a
> dot-delimited hierarchy, and there are mechanisms for resolving
> unqualified names. Environments, in contrast, are more like Newspeak
> modules. There's no universal mapping of names to objects, but rather
> different "points of view," where names resolve differently depending
> on which environment you're in.
>
> The simplest and most common use for environments is to allow two
> classes with the same name to peacefully co-exist. We currently work
> around this problem with classname prefixes - MC in Monticello or WA
> in Seaside. With environments, we can do away with prefixes by
> creating a separate environment for each prefix that we're currently
> using.
>
> An interesting example of this case that I've run across lately is
> Xtreams. In the original VW version, there's only one class that's
> publicly visible: the Incomplete exception that gets raised when a
> stream operation fails. The rest of the public API to the library is
> provided as extensions to classes in the base system. There's actually
> no need for code that uses Xtreams to refer to any of the stream
> classes. That leaves a lot of room for the implementation of Xtreams
> to change while keeping the API stable, and I'd like to be able to
> take advantage of this design in Squeak. With Environments, that's
> possible: we just create an environment to hold the Xtreams classes,
> import the base system, compile Xtreams, export Incomplete, and import
> Xtreams into our application's environment.
>
> I've done a preliminary implementation, which lets me create an empty
> environment, file code into it and then browse and modify it with a
> standard browser. There's still lots of work to do, but I want to get
> a consensus among the core developers before tackling it. That way the
> changes can happen in the trunk and we don't have to worry about a
> difficult integration later.

I hate to disappoint the invitation for flaming, but I'm very happy
for this to go into trunk.

(As an aside, Environments also shows that resumable exceptions
express _delimited_ dynamic variables, exemplified by
EnvironmentRequest. (These are dynamic variables that play nicely with
delimited continuations; they close over _part_ of the dynamic
environment.) I'll follow up with a longer mail hopefully today or
tomorrow)

frank

> I've attached a couple of screenshots. The first shows two browsers,
> one browsing the base image, the other browsing an environment with
> Seaside 3.0 loaded. The second is an explorer on the Seaside
> environment. The image where they were taken is available for download
> here:
>
>   http://www.wiresong.ca/downloads/Environments.zip
>
>
> Flame away!

> Colin
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Chris Muller-3
In reply to this post by Colin Putney-3
It sounds like a simple solution -- I do appreciate it's a pure OO
solution rather introducing new syntax.

However, things tend to "sound" simple when I barely understand them.
Perhaps a concrete example would help me -- the basic use-case:
pretend I have an application called "Application" that wants to use
both Magma and Seaside in the same image and each wants to define a
"Session" class.  They are developed by different developers.  In this
context, could you clarify some questions?

  - Somewhere, the Application would need to define the "order" of the
Environments it depends on so it can sometimes use unqualified names,
is this correct?  What would that code look like?

  - What would the loading/initialization code look like that would
put Magma's Session into its own environment?

  - What would the code to access Magma's Session (instead of
Seasides) look like from within one of Magma's methods?

  - What would the code to access Magma's Session (instead of
Seasides) look like from within one of Application's methods?

  - What would the code to access Magma's Session (instead of
Seasides) look like from a workspace (Global environment?)

It sounds like you're on to something to give Squeak a new a kung-fu
move, thanks for pushing on this!



On Mon, Jun 25, 2012 at 9:11 PM, Colin Putney <[hidden email]> wrote:

> Hi all,
>
> There's an old joke in the Squeak community about how we have a flame
> war about namespaces every few years and only newbies bring up the
> topic casually. Well, it seems we're overdue, so I'd like to do my bit
> for the community by keeping up the tradition.
>
> I propose that Squeak 4.4, or perhaps 4.5, include support for more
> than one class with the same name. This will be a modest proposal,
> based on extending Dan's work on environments. The basic idea is this:
> an Environment is an object that implements a policy for binding names
> to objects during compilation.
>
> This is in direct contrast to the Namespace implementation that
> VisualWorks uses. In VW the global namespace is divided up into a
> dot-delimited hierarchy, and there are mechanisms for resolving
> unqualified names. Environments, in contrast, are more like Newspeak
> modules. There's no universal mapping of names to objects, but rather
> different "points of view," where names resolve differently depending
> on which environment you're in.
>
> The simplest and most common use for environments is to allow two
> classes with the same name to peacefully co-exist. We currently work
> around this problem with classname prefixes - MC in Monticello or WA
> in Seaside. With environments, we can do away with prefixes by
> creating a separate environment for each prefix that we're currently
> using.
>
> An interesting example of this case that I've run across lately is
> Xtreams. In the original VW version, there's only one class that's
> publicly visible: the Incomplete exception that gets raised when a
> stream operation fails. The rest of the public API to the library is
> provided as extensions to classes in the base system. There's actually
> no need for code that uses Xtreams to refer to any of the stream
> classes. That leaves a lot of room for the implementation of Xtreams
> to change while keeping the API stable, and I'd like to be able to
> take advantage of this design in Squeak. With Environments, that's
> possible: we just create an environment to hold the Xtreams classes,
> import the base system, compile Xtreams, export Incomplete, and import
> Xtreams into our application's environment.
>
> I've done a preliminary implementation, which lets me create an empty
> environment, file code into it and then browse and modify it with a
> standard browser. There's still lots of work to do, but I want to get
> a consensus among the core developers before tackling it. That way the
> changes can happen in the trunk and we don't have to worry about a
> difficult integration later.
>
> I've attached a couple of screenshots. The first shows two browsers,
> one browsing the base image, the other browsing an environment with
> Seaside 3.0 loaded. The second is an explorer on the Seaside
> environment. The image where they were taken is available for download
> here:
>
>   http://www.wiresong.ca/downloads/Environments.zip
>
>
> Flame away!
>
> Colin
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Chris Muller-3
In reply to this post by Colin Putney-3
This namespace solution is just for globals/class names correct?
There could still potentially be method-name conflicts for extensions
to classes in the Smalltalk environment, right?


On Mon, Jun 25, 2012 at 9:11 PM, Colin Putney <[hidden email]> wrote:

> Hi all,
>
> There's an old joke in the Squeak community about how we have a flame
> war about namespaces every few years and only newbies bring up the
> topic casually. Well, it seems we're overdue, so I'd like to do my bit
> for the community by keeping up the tradition.
>
> I propose that Squeak 4.4, or perhaps 4.5, include support for more
> than one class with the same name. This will be a modest proposal,
> based on extending Dan's work on environments. The basic idea is this:
> an Environment is an object that implements a policy for binding names
> to objects during compilation.
>
> This is in direct contrast to the Namespace implementation that
> VisualWorks uses. In VW the global namespace is divided up into a
> dot-delimited hierarchy, and there are mechanisms for resolving
> unqualified names. Environments, in contrast, are more like Newspeak
> modules. There's no universal mapping of names to objects, but rather
> different "points of view," where names resolve differently depending
> on which environment you're in.
>
> The simplest and most common use for environments is to allow two
> classes with the same name to peacefully co-exist. We currently work
> around this problem with classname prefixes - MC in Monticello or WA
> in Seaside. With environments, we can do away with prefixes by
> creating a separate environment for each prefix that we're currently
> using.
>
> An interesting example of this case that I've run across lately is
> Xtreams. In the original VW version, there's only one class that's
> publicly visible: the Incomplete exception that gets raised when a
> stream operation fails. The rest of the public API to the library is
> provided as extensions to classes in the base system. There's actually
> no need for code that uses Xtreams to refer to any of the stream
> classes. That leaves a lot of room for the implementation of Xtreams
> to change while keeping the API stable, and I'd like to be able to
> take advantage of this design in Squeak. With Environments, that's
> possible: we just create an environment to hold the Xtreams classes,
> import the base system, compile Xtreams, export Incomplete, and import
> Xtreams into our application's environment.
>
> I've done a preliminary implementation, which lets me create an empty
> environment, file code into it and then browse and modify it with a
> standard browser. There's still lots of work to do, but I want to get
> a consensus among the core developers before tackling it. That way the
> changes can happen in the trunk and we don't have to worry about a
> difficult integration later.
>
> I've attached a couple of screenshots. The first shows two browsers,
> one browsing the base image, the other browsing an environment with
> Seaside 3.0 loaded. The second is an explorer on the Seaside
> environment. The image where they were taken is available for download
> here:
>
>   http://www.wiresong.ca/downloads/Environments.zip
>
>
> Flame away!
>
> Colin
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Dale Henrichs
In reply to this post by Colin Putney-3
Colin,

Be aware that code written to run in namespaces will be much more difficult to port to platforms with different or no namespace implementations. A portable solution 9not to be confused with a portable implementation) would be preferable and without looking at details, I'd guess that you are going down the portable route, especially since you are not leaning on syntax...

Dale

----- Original Message -----
| From: "Colin Putney" <[hidden email]>
| To: "Squeak-Dev developers list" <[hidden email]>
| Sent: Monday, June 25, 2012 7:11:18 PM
| Subject: [squeak-dev] Environments
|
| Hi all,
|
| There's an old joke in the Squeak community about how we have a flame
| war about namespaces every few years and only newbies bring up the
| topic casually. Well, it seems we're overdue, so I'd like to do my
| bit
| for the community by keeping up the tradition.
|
| I propose that Squeak 4.4, or perhaps 4.5, include support for more
| than one class with the same name. This will be a modest proposal,
| based on extending Dan's work on environments. The basic idea is
| this:
| an Environment is an object that implements a policy for binding
| names
| to objects during compilation.
|
| This is in direct contrast to the Namespace implementation that
| VisualWorks uses. In VW the global namespace is divided up into a
| dot-delimited hierarchy, and there are mechanisms for resolving
| unqualified names. Environments, in contrast, are more like Newspeak
| modules. There's no universal mapping of names to objects, but rather
| different "points of view," where names resolve differently depending
| on which environment you're in.
|
| The simplest and most common use for environments is to allow two
| classes with the same name to peacefully co-exist. We currently work
| around this problem with classname prefixes - MC in Monticello or WA
| in Seaside. With environments, we can do away with prefixes by
| creating a separate environment for each prefix that we're currently
| using.
|
| An interesting example of this case that I've run across lately is
| Xtreams. In the original VW version, there's only one class that's
| publicly visible: the Incomplete exception that gets raised when a
| stream operation fails. The rest of the public API to the library is
| provided as extensions to classes in the base system. There's
| actually
| no need for code that uses Xtreams to refer to any of the stream
| classes. That leaves a lot of room for the implementation of Xtreams
| to change while keeping the API stable, and I'd like to be able to
| take advantage of this design in Squeak. With Environments, that's
| possible: we just create an environment to hold the Xtreams classes,
| import the base system, compile Xtreams, export Incomplete, and
| import
| Xtreams into our application's environment.
|
| I've done a preliminary implementation, which lets me create an empty
| environment, file code into it and then browse and modify it with a
| standard browser. There's still lots of work to do, but I want to get
| a consensus among the core developers before tackling it. That way
| the
| changes can happen in the trunk and we don't have to worry about a
| difficult integration later.
|
| I've attached a couple of screenshots. The first shows two browsers,
| one browsing the base image, the other browsing an environment with
| Seaside 3.0 loaded. The second is an explorer on the Seaside
| environment. The image where they were taken is available for
| download
| here:
|
|    http://www.wiresong.ca/downloads/Environments.zip
|
|
| Flame away!
|
| Colin
|
|
|

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Frank Shearar-3
On 26 June 2012 17:26, Dale Henrichs <[hidden email]> wrote:
> Colin,
>
> Be aware that code written to run in namespaces will be much more difficult to port to platforms with different or no namespace implementations. A portable solution 9not to be confused with a portable implementation) would be preferable and without looking at details, I'd guess that you are going down the portable route, especially since you are not leaning on syntax...

One non-portable part would be the ClassBuilder extensions! That lets
you plug a new class into an Environment. I'm not sure how you'd coax
an external compiler (Gemstone) into installing a new class into your
new, isolated, environment.

frank

> Dale
>
> ----- Original Message -----
> | From: "Colin Putney" <[hidden email]>
> | To: "Squeak-Dev developers list" <[hidden email]>
> | Sent: Monday, June 25, 2012 7:11:18 PM
> | Subject: [squeak-dev] Environments
> |
> | Hi all,
> |
> | There's an old joke in the Squeak community about how we have a flame
> | war about namespaces every few years and only newbies bring up the
> | topic casually. Well, it seems we're overdue, so I'd like to do my
> | bit
> | for the community by keeping up the tradition.
> |
> | I propose that Squeak 4.4, or perhaps 4.5, include support for more
> | than one class with the same name. This will be a modest proposal,
> | based on extending Dan's work on environments. The basic idea is
> | this:
> | an Environment is an object that implements a policy for binding
> | names
> | to objects during compilation.
> |
> | This is in direct contrast to the Namespace implementation that
> | VisualWorks uses. In VW the global namespace is divided up into a
> | dot-delimited hierarchy, and there are mechanisms for resolving
> | unqualified names. Environments, in contrast, are more like Newspeak
> | modules. There's no universal mapping of names to objects, but rather
> | different "points of view," where names resolve differently depending
> | on which environment you're in.
> |
> | The simplest and most common use for environments is to allow two
> | classes with the same name to peacefully co-exist. We currently work
> | around this problem with classname prefixes - MC in Monticello or WA
> | in Seaside. With environments, we can do away with prefixes by
> | creating a separate environment for each prefix that we're currently
> | using.
> |
> | An interesting example of this case that I've run across lately is
> | Xtreams. In the original VW version, there's only one class that's
> | publicly visible: the Incomplete exception that gets raised when a
> | stream operation fails. The rest of the public API to the library is
> | provided as extensions to classes in the base system. There's
> | actually
> | no need for code that uses Xtreams to refer to any of the stream
> | classes. That leaves a lot of room for the implementation of Xtreams
> | to change while keeping the API stable, and I'd like to be able to
> | take advantage of this design in Squeak. With Environments, that's
> | possible: we just create an environment to hold the Xtreams classes,
> | import the base system, compile Xtreams, export Incomplete, and
> | import
> | Xtreams into our application's environment.
> |
> | I've done a preliminary implementation, which lets me create an empty
> | environment, file code into it and then browse and modify it with a
> | standard browser. There's still lots of work to do, but I want to get
> | a consensus among the core developers before tackling it. That way
> | the
> | changes can happen in the trunk and we don't have to worry about a
> | difficult integration later.
> |
> | I've attached a couple of screenshots. The first shows two browsers,
> | one browsing the base image, the other browsing an environment with
> | Seaside 3.0 loaded. The second is an explorer on the Seaside
> | environment. The image where they were taken is available for
> | download
> | here:
> |
> |    http://www.wiresong.ca/downloads/Environments.zip
> |
> |
> | Flame away!
> |
> | Colin
> |
> |
> |
>

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Frank Shearar-3
In reply to this post by Chris Muller-3
On 26 June 2012 17:05, Chris Muller <[hidden email]> wrote:
> This namespace solution is just for globals/class names correct?
> There could still potentially be method-name conflicts for extensions
> to classes in the Smalltalk environment, right?

Preventing method conflicts is a whole other kettle of fish.
Environments doesn't address this. (There are some interesting things
in the avoid-monkey-patch-clashing area, like "selector namespaces",
and classboxes, and probably some other things I don't know of.)

frank

> On Mon, Jun 25, 2012 at 9:11 PM, Colin Putney <[hidden email]> wrote:
>> Hi all,
>>
>> There's an old joke in the Squeak community about how we have a flame
>> war about namespaces every few years and only newbies bring up the
>> topic casually. Well, it seems we're overdue, so I'd like to do my bit
>> for the community by keeping up the tradition.
>>
>> I propose that Squeak 4.4, or perhaps 4.5, include support for more
>> than one class with the same name. This will be a modest proposal,
>> based on extending Dan's work on environments. The basic idea is this:
>> an Environment is an object that implements a policy for binding names
>> to objects during compilation.
>>
>> This is in direct contrast to the Namespace implementation that
>> VisualWorks uses. In VW the global namespace is divided up into a
>> dot-delimited hierarchy, and there are mechanisms for resolving
>> unqualified names. Environments, in contrast, are more like Newspeak
>> modules. There's no universal mapping of names to objects, but rather
>> different "points of view," where names resolve differently depending
>> on which environment you're in.
>>
>> The simplest and most common use for environments is to allow two
>> classes with the same name to peacefully co-exist. We currently work
>> around this problem with classname prefixes - MC in Monticello or WA
>> in Seaside. With environments, we can do away with prefixes by
>> creating a separate environment for each prefix that we're currently
>> using.
>>
>> An interesting example of this case that I've run across lately is
>> Xtreams. In the original VW version, there's only one class that's
>> publicly visible: the Incomplete exception that gets raised when a
>> stream operation fails. The rest of the public API to the library is
>> provided as extensions to classes in the base system. There's actually
>> no need for code that uses Xtreams to refer to any of the stream
>> classes. That leaves a lot of room for the implementation of Xtreams
>> to change while keeping the API stable, and I'd like to be able to
>> take advantage of this design in Squeak. With Environments, that's
>> possible: we just create an environment to hold the Xtreams classes,
>> import the base system, compile Xtreams, export Incomplete, and import
>> Xtreams into our application's environment.
>>
>> I've done a preliminary implementation, which lets me create an empty
>> environment, file code into it and then browse and modify it with a
>> standard browser. There's still lots of work to do, but I want to get
>> a consensus among the core developers before tackling it. That way the
>> changes can happen in the trunk and we don't have to worry about a
>> difficult integration later.
>>
>> I've attached a couple of screenshots. The first shows two browsers,
>> one browsing the base image, the other browsing an environment with
>> Seaside 3.0 loaded. The second is an explorer on the Seaside
>> environment. The image where they were taken is available for download
>> here:
>>
>>   http://www.wiresong.ca/downloads/Environments.zip
>>
>>
>> Flame away!
>>
>> Colin
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Dale Henrichs
In reply to this post by Frank Shearar-3
Frank,

As far as GemStone is concerned we've had separate environments for classes for a very long time. Instead of a Smalltalk dictionary, GemStone does global lookups using a list of dictionaries (SymbolList) and this list can be dynamically adjusted by the user. So in the end, I'd think that it would be straightforward to add this type of namespace to GemStone.

We've also got dynamic lookups for methods as well ... it's what we've used make it possible to run Ruby in a Smalltalk environment and it's what we use in GLASS for the Squeak/Pharo compatibility later ... I haven't looked at what it would take to isolate the method look up to an environment (i.e., environment-specific extension methods to shared classes), but it's something that we'd eventually like to do.

Dale

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Sent: Tuesday, June 26, 2012 9:30:28 AM
| Subject: Re: [squeak-dev] Environments
|
| On 26 June 2012 17:26, Dale Henrichs <[hidden email]> wrote:
| > Colin,
| >
| > Be aware that code written to run in namespaces will be much more
| > difficult to port to platforms with different or no namespace
| > implementations. A portable solution 9not to be confused with a
| > portable implementation) would be preferable and without looking
| > at details, I'd guess that you are going down the portable route,
| > especially since you are not leaning on syntax...
|
| One non-portable part would be the ClassBuilder extensions! That lets
| you plug a new class into an Environment. I'm not sure how you'd coax
| an external compiler (Gemstone) into installing a new class into your
| new, isolated, environment.
|
| frank
|
| > Dale
| >
| > ----- Original Message -----
| > | From: "Colin Putney" <[hidden email]>
| > | To: "Squeak-Dev developers list"
| > | <[hidden email]>
| > | Sent: Monday, June 25, 2012 7:11:18 PM
| > | Subject: [squeak-dev] Environments
| > |
| > | Hi all,
| > |
| > | There's an old joke in the Squeak community about how we have a
| > | flame
| > | war about namespaces every few years and only newbies bring up
| > | the
| > | topic casually. Well, it seems we're overdue, so I'd like to do
| > | my
| > | bit
| > | for the community by keeping up the tradition.
| > |
| > | I propose that Squeak 4.4, or perhaps 4.5, include support for
| > | more
| > | than one class with the same name. This will be a modest
| > | proposal,
| > | based on extending Dan's work on environments. The basic idea is
| > | this:
| > | an Environment is an object that implements a policy for binding
| > | names
| > | to objects during compilation.
| > |
| > | This is in direct contrast to the Namespace implementation that
| > | VisualWorks uses. In VW the global namespace is divided up into a
| > | dot-delimited hierarchy, and there are mechanisms for resolving
| > | unqualified names. Environments, in contrast, are more like
| > | Newspeak
| > | modules. There's no universal mapping of names to objects, but
| > | rather
| > | different "points of view," where names resolve differently
| > | depending
| > | on which environment you're in.
| > |
| > | The simplest and most common use for environments is to allow two
| > | classes with the same name to peacefully co-exist. We currently
| > | work
| > | around this problem with classname prefixes - MC in Monticello or
| > | WA
| > | in Seaside. With environments, we can do away with prefixes by
| > | creating a separate environment for each prefix that we're
| > | currently
| > | using.
| > |
| > | An interesting example of this case that I've run across lately
| > | is
| > | Xtreams. In the original VW version, there's only one class
| > | that's
| > | publicly visible: the Incomplete exception that gets raised when
| > | a
| > | stream operation fails. The rest of the public API to the library
| > | is
| > | provided as extensions to classes in the base system. There's
| > | actually
| > | no need for code that uses Xtreams to refer to any of the stream
| > | classes. That leaves a lot of room for the implementation of
| > | Xtreams
| > | to change while keeping the API stable, and I'd like to be able
| > | to
| > | take advantage of this design in Squeak. With Environments,
| > | that's
| > | possible: we just create an environment to hold the Xtreams
| > | classes,
| > | import the base system, compile Xtreams, export Incomplete, and
| > | import
| > | Xtreams into our application's environment.
| > |
| > | I've done a preliminary implementation, which lets me create an
| > | empty
| > | environment, file code into it and then browse and modify it with
| > | a
| > | standard browser. There's still lots of work to do, but I want to
| > | get
| > | a consensus among the core developers before tackling it. That
| > | way
| > | the
| > | changes can happen in the trunk and we don't have to worry about
| > | a
| > | difficult integration later.
| > |
| > | I've attached a couple of screenshots. The first shows two
| > | browsers,
| > | one browsing the base image, the other browsing an environment
| > | with
| > | Seaside 3.0 loaded. The second is an explorer on the Seaside
| > | environment. The image where they were taken is available for
| > | download
| > | here:
| > |
| > |    http://www.wiresong.ca/downloads/Environments.zip
| > |
| > |
| > | Flame away!
| > |
| > | Colin
| > |
| > |
| > |
| >
|
|

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Frank Shearar-3
On 26 June 2012 17:44, Dale Henrichs <[hidden email]> wrote:
> Frank,
>
> As far as GemStone is concerned we've had separate environments for classes for a very long time. Instead of a Smalltalk dictionary, GemStone does global lookups using a list of dictionaries (SymbolList) and this list can be dynamically adjusted by the user. So in the end, I'd think that it would be straightforward to add this type of namespace to GemStone.

Ah, excellent! I'd imagined (in my ignorance) that since GemStone has
the (to my mind) unusual C-based compiler, that it might have issues
in this regard.

frank

> We've also got dynamic lookups for methods as well ... it's what we've used make it possible to run Ruby in a Smalltalk environment and it's what we use in GLASS for the Squeak/Pharo compatibility later ... I haven't looked at what it would take to isolate the method look up to an environment (i.e., environment-specific extension methods to shared classes), but it's something that we'd eventually like to do.
>
> Dale
>
> ----- Original Message -----
> | From: "Frank Shearar" <[hidden email]>
> | To: "The general-purpose Squeak developers list" <[hidden email]>
> | Sent: Tuesday, June 26, 2012 9:30:28 AM
> | Subject: Re: [squeak-dev] Environments
> |
> | On 26 June 2012 17:26, Dale Henrichs <[hidden email]> wrote:
> | > Colin,
> | >
> | > Be aware that code written to run in namespaces will be much more
> | > difficult to port to platforms with different or no namespace
> | > implementations. A portable solution 9not to be confused with a
> | > portable implementation) would be preferable and without looking
> | > at details, I'd guess that you are going down the portable route,
> | > especially since you are not leaning on syntax...
> |
> | One non-portable part would be the ClassBuilder extensions! That lets
> | you plug a new class into an Environment. I'm not sure how you'd coax
> | an external compiler (Gemstone) into installing a new class into your
> | new, isolated, environment.
> |
> | frank
> |
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Colin Putney" <[hidden email]>
> | > | To: "Squeak-Dev developers list"
> | > | <[hidden email]>
> | > | Sent: Monday, June 25, 2012 7:11:18 PM
> | > | Subject: [squeak-dev] Environments
> | > |
> | > | Hi all,
> | > |
> | > | There's an old joke in the Squeak community about how we have a
> | > | flame
> | > | war about namespaces every few years and only newbies bring up
> | > | the
> | > | topic casually. Well, it seems we're overdue, so I'd like to do
> | > | my
> | > | bit
> | > | for the community by keeping up the tradition.
> | > |
> | > | I propose that Squeak 4.4, or perhaps 4.5, include support for
> | > | more
> | > | than one class with the same name. This will be a modest
> | > | proposal,
> | > | based on extending Dan's work on environments. The basic idea is
> | > | this:
> | > | an Environment is an object that implements a policy for binding
> | > | names
> | > | to objects during compilation.
> | > |
> | > | This is in direct contrast to the Namespace implementation that
> | > | VisualWorks uses. In VW the global namespace is divided up into a
> | > | dot-delimited hierarchy, and there are mechanisms for resolving
> | > | unqualified names. Environments, in contrast, are more like
> | > | Newspeak
> | > | modules. There's no universal mapping of names to objects, but
> | > | rather
> | > | different "points of view," where names resolve differently
> | > | depending
> | > | on which environment you're in.
> | > |
> | > | The simplest and most common use for environments is to allow two
> | > | classes with the same name to peacefully co-exist. We currently
> | > | work
> | > | around this problem with classname prefixes - MC in Monticello or
> | > | WA
> | > | in Seaside. With environments, we can do away with prefixes by
> | > | creating a separate environment for each prefix that we're
> | > | currently
> | > | using.
> | > |
> | > | An interesting example of this case that I've run across lately
> | > | is
> | > | Xtreams. In the original VW version, there's only one class
> | > | that's
> | > | publicly visible: the Incomplete exception that gets raised when
> | > | a
> | > | stream operation fails. The rest of the public API to the library
> | > | is
> | > | provided as extensions to classes in the base system. There's
> | > | actually
> | > | no need for code that uses Xtreams to refer to any of the stream
> | > | classes. That leaves a lot of room for the implementation of
> | > | Xtreams
> | > | to change while keeping the API stable, and I'd like to be able
> | > | to
> | > | take advantage of this design in Squeak. With Environments,
> | > | that's
> | > | possible: we just create an environment to hold the Xtreams
> | > | classes,
> | > | import the base system, compile Xtreams, export Incomplete, and
> | > | import
> | > | Xtreams into our application's environment.
> | > |
> | > | I've done a preliminary implementation, which lets me create an
> | > | empty
> | > | environment, file code into it and then browse and modify it with
> | > | a
> | > | standard browser. There's still lots of work to do, but I want to
> | > | get
> | > | a consensus among the core developers before tackling it. That
> | > | way
> | > | the
> | > | changes can happen in the trunk and we don't have to worry about
> | > | a
> | > | difficult integration later.
> | > |
> | > | I've attached a couple of screenshots. The first shows two
> | > | browsers,
> | > | one browsing the base image, the other browsing an environment
> | > | with
> | > | Seaside 3.0 loaded. The second is an explorer on the Seaside
> | > | environment. The image where they were taken is available for
> | > | download
> | > | here:
> | > |
> | > |    http://www.wiresong.ca/downloads/Environments.zip
> | > |
> | > |
> | > | Flame away!
> | > |
> | > | Colin
> | > |
> | > |
> | > |
> | >
> |
> |
>

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Dale Henrichs
Frank,

You were right to make that assumption, since the C-based compiler often does get in the way:)

Dale

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Sent: Tuesday, June 26, 2012 9:47:12 AM
| Subject: Re: [squeak-dev] Environments
|
| On 26 June 2012 17:44, Dale Henrichs <[hidden email]> wrote:
| > Frank,
| >
| > As far as GemStone is concerned we've had separate environments for
| > classes for a very long time. Instead of a Smalltalk dictionary,
| > GemStone does global lookups using a list of dictionaries
| > (SymbolList) and this list can be dynamically adjusted by the
| > user. So in the end, I'd think that it would be straightforward to
| > add this type of namespace to GemStone.
|
| Ah, excellent! I'd imagined (in my ignorance) that since GemStone has
| the (to my mind) unusual C-based compiler, that it might have issues
| in this regard.
|
| frank
|
| > We've also got dynamic lookups for methods as well ... it's what
| > we've used make it possible to run Ruby in a Smalltalk environment
| > and it's what we use in GLASS for the Squeak/Pharo compatibility
| > later ... I haven't looked at what it would take to isolate the
| > method look up to an environment (i.e., environment-specific
| > extension methods to shared classes), but it's something that we'd
| > eventually like to do.
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Frank Shearar" <[hidden email]>
| > | To: "The general-purpose Squeak developers list"
| > | <[hidden email]>
| > | Sent: Tuesday, June 26, 2012 9:30:28 AM
| > | Subject: Re: [squeak-dev] Environments
| > |
| > | On 26 June 2012 17:26, Dale Henrichs <[hidden email]> wrote:
| > | > Colin,
| > | >
| > | > Be aware that code written to run in namespaces will be much
| > | > more
| > | > difficult to port to platforms with different or no namespace
| > | > implementations. A portable solution 9not to be confused with a
| > | > portable implementation) would be preferable and without
| > | > looking
| > | > at details, I'd guess that you are going down the portable
| > | > route,
| > | > especially since you are not leaning on syntax...
| > |
| > | One non-portable part would be the ClassBuilder extensions! That
| > | lets
| > | you plug a new class into an Environment. I'm not sure how you'd
| > | coax
| > | an external compiler (Gemstone) into installing a new class into
| > | your
| > | new, isolated, environment.
| > |
| > | frank
| > |
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Colin Putney" <[hidden email]>
| > | > | To: "Squeak-Dev developers list"
| > | > | <[hidden email]>
| > | > | Sent: Monday, June 25, 2012 7:11:18 PM
| > | > | Subject: [squeak-dev] Environments
| > | > |
| > | > | Hi all,
| > | > |
| > | > | There's an old joke in the Squeak community about how we have
| > | > | a
| > | > | flame
| > | > | war about namespaces every few years and only newbies bring
| > | > | up
| > | > | the
| > | > | topic casually. Well, it seems we're overdue, so I'd like to
| > | > | do
| > | > | my
| > | > | bit
| > | > | for the community by keeping up the tradition.
| > | > |
| > | > | I propose that Squeak 4.4, or perhaps 4.5, include support
| > | > | for
| > | > | more
| > | > | than one class with the same name. This will be a modest
| > | > | proposal,
| > | > | based on extending Dan's work on environments. The basic idea
| > | > | is
| > | > | this:
| > | > | an Environment is an object that implements a policy for
| > | > | binding
| > | > | names
| > | > | to objects during compilation.
| > | > |
| > | > | This is in direct contrast to the Namespace implementation
| > | > | that
| > | > | VisualWorks uses. In VW the global namespace is divided up
| > | > | into a
| > | > | dot-delimited hierarchy, and there are mechanisms for
| > | > | resolving
| > | > | unqualified names. Environments, in contrast, are more like
| > | > | Newspeak
| > | > | modules. There's no universal mapping of names to objects,
| > | > | but
| > | > | rather
| > | > | different "points of view," where names resolve differently
| > | > | depending
| > | > | on which environment you're in.
| > | > |
| > | > | The simplest and most common use for environments is to allow
| > | > | two
| > | > | classes with the same name to peacefully co-exist. We
| > | > | currently
| > | > | work
| > | > | around this problem with classname prefixes - MC in
| > | > | Monticello or
| > | > | WA
| > | > | in Seaside. With environments, we can do away with prefixes
| > | > | by
| > | > | creating a separate environment for each prefix that we're
| > | > | currently
| > | > | using.
| > | > |
| > | > | An interesting example of this case that I've run across
| > | > | lately
| > | > | is
| > | > | Xtreams. In the original VW version, there's only one class
| > | > | that's
| > | > | publicly visible: the Incomplete exception that gets raised
| > | > | when
| > | > | a
| > | > | stream operation fails. The rest of the public API to the
| > | > | library
| > | > | is
| > | > | provided as extensions to classes in the base system. There's
| > | > | actually
| > | > | no need for code that uses Xtreams to refer to any of the
| > | > | stream
| > | > | classes. That leaves a lot of room for the implementation of
| > | > | Xtreams
| > | > | to change while keeping the API stable, and I'd like to be
| > | > | able
| > | > | to
| > | > | take advantage of this design in Squeak. With Environments,
| > | > | that's
| > | > | possible: we just create an environment to hold the Xtreams
| > | > | classes,
| > | > | import the base system, compile Xtreams, export Incomplete,
| > | > | and
| > | > | import
| > | > | Xtreams into our application's environment.
| > | > |
| > | > | I've done a preliminary implementation, which lets me create
| > | > | an
| > | > | empty
| > | > | environment, file code into it and then browse and modify it
| > | > | with
| > | > | a
| > | > | standard browser. There's still lots of work to do, but I
| > | > | want to
| > | > | get
| > | > | a consensus among the core developers before tackling it.
| > | > | That
| > | > | way
| > | > | the
| > | > | changes can happen in the trunk and we don't have to worry
| > | > | about
| > | > | a
| > | > | difficult integration later.
| > | > |
| > | > | I've attached a couple of screenshots. The first shows two
| > | > | browsers,
| > | > | one browsing the base image, the other browsing an
| > | > | environment
| > | > | with
| > | > | Seaside 3.0 loaded. The second is an explorer on the Seaside
| > | > | environment. The image where they were taken is available for
| > | > | download
| > | > | here:
| > | > |
| > | > |    http://www.wiresong.ca/downloads/Environments.zip
| > | > |
| > | > |
| > | > | Flame away!
| > | > |
| > | > | Colin
| > | > |
| > | > |
| > | > |
| > | >
| > |
| > |
| >
|
|

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Colin Putney-3
In reply to this post by Dale Henrichs
On Tue, Jun 26, 2012 at 9:26 AM, Dale Henrichs <[hidden email]> wrote:

> Be aware that code written to run in namespaces will be much more
> difficult to port to platforms with different or no namespace
> implementations. A portable solution 9not to be confused with a
> portable implementation) would be preferable and without looking at
> details, I'd guess that you are going down the portable route,
> especially since you are not leaning on syntax...

Yes. Portability is important. I hope to end up with a solution where
application/framework code just assumes a flat namespace, and only the
tools need to be environment-aware. The only difference for
application code should be that class-name prefixes are no longer
necessary. Without having looked into it, I'd guess that porting such
code to Gemstone, VisualWorks and GST would be pretty easy. I don't
think VA has namespaces, (somebody correct me if I'm wrong) so that
might be a bit trickier.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Colin Putney-3
In reply to this post by Chris Muller-3


On Tue, Jun 26, 2012 at 8:38 AM, Chris Muller <[hidden email]> wrote:
> It sounds like a simple solution -- I do appreciate it's a pure OO
> solution rather introducing new syntax.
>
> However, things tend to "sound" simple when I barely understand them.
> Perhaps a concrete example would help me -- the basic use-case:
> pretend I have an application called "Application" that wants to use
> both Magma and Seaside in the same image and each wants to define a
> "Session" class.  They are developed by different developers.  In this
> context, could you clarify some questions?

Sure, that sounds like a great use-case for Environments.

>  - Somewhere, the Application would need to define the "order" of the
> Environments it depends on so it can sometimes use unqualified names,
> is this correct?  What would that code look like?

Yes, that does need to be defined, but that definition shouldn't be part of Application. Application should just refer to the classes it needs and leave it up the environment to know where they are. That means that environment management is done in your development tools, and when building images. To set up the environments for Application you might do something like this:

  (Environment name: 'Seaside')
    importSmalltalk;
    fileIn: 'Seaside.st'.

  (Environment name: 'Magma')
    importSmalltalk;
    fileIn: 'Magma.st'.

  (Environment name: 'Application')
    importSmalltalk;
    import: #Seaside;
    import: #Magma;
    fileIn: 'Application.st'.

>  - What would the loading/initialization code look like that would
> put Magma's Session into its own environment?

You'd load all of Magma into the it's own environment, as above.

>  - What would the code to access Magma's Session (instead of
> Seasides) look like from within one of Magma's methods?

From a design perspective, we don't want Seaside or Magma to depend on each other. (Note that the Seaside and Magma environments don't import each other.) So within the Seaside and Magma environments, Session is unambiguous, and can just be referred to directly:

  Session new

>  - What would the code to access Magma's Session (instead of
> Seasides) look like from within one of Application's methods?

Ok, this is the bit that's slightly tricky. Application needs to use both Seaside sessions and Magma sessions, so we need to disambiguate. Application code should just use arbitrary names, like WASession and MaSession, or SeasideSession and MagmaSession if that's more aesthetically pleasing. Then it's up to the environment to sort them out. We'd do something like this:

  (Environment name: 'Application')
    importSmalltalk;
    import: #Seaside aliases: {#Session -> #SeasideSession};
    import: #Magma aliases: {#Session -> #MagmaSession};
    fileIn: 'Application.st'.

Note that I haven't implemented imports (except for Smalltalk) or aliasing yet, so the protocol might end up being different.

>  - What would the code to access Magma's Session (instead of
> Seasides) look like from a workspace (Global environment?)

The workspace would have an environment as well, and there's be some UI for manipulating it. So Magma's session might be called Session or MagmaSession, or whatever is convenient for that workspace. We might even do some kind of automatic importing similar to the way undeclared variables work are handled.

Great questions Chris, thanks.

Colin


Reply | Threaded
Open this post in threaded view
|

Re: Environments

Göran Krampe
In reply to this post by Colin Putney-3
Hi Colin and all!

First of all - you are brave :)

Anyway, a few thoughts of mine, although I am no longer "invested" in
this area, I was earlier but have given up waaaay back.

1. AFAICT this will (in contrary to my solution) remove the
"modelessness" we have today. Or in other words, a code snippet will
behave differently depending on which environment you are in. One can
argue that this also holds true today (class variables shadowing globals
for example) but still. It reminds me of VA for Java where you had to
tell the "Workspace" in which class it was being run (in order to get
all the imports right). I am not sure I like where this is leading.
NOTE: My proposal meant that all class refs were actually in full, never
short. They just "rendered" short when it was reasonable.

2. Reading code will force me to always be aware of which environments
are imported into the package I am reading. Otherwise I will not know
which class is referred to when I read "Manager". NOTE: My proposal
would always expand names into full names if there were more than two in
the image.

3. And finally, this is AFAICT the same "pessimistic" approach that Java
etc use - in other words, each developer/project will create his/her own
little sandbox (=environment) and will start creating duplicate names
for things (knowingly or unknowingly) and will never really "notice"
this because this solution will never make it apparent that it has been
done. NOTE: My proposal would lead to ambiguous names being rendered
with full path and also asking the developer if he meant Color::Orange
of Fruit::Orange whenever he tried to type just "Orange" - thus making
him (and all others) aware of the slightly unfortunate name clash.

I am merely contrasting this with my own proposal from years back in
order to hear people's views on the above aspects.

Personally I am *happy* that this stone is finally turned.

On the other hand I am *unhappy* that you aren't facing any opposition
because unfortunately it may just indicate that our community have
shrunk considerably and people are instead flaming each other over on
Pharo-dev. ;)

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Bert Freudenberg
On 27.06.2012, at 10:35, Göran Krampe wrote:

> Personally I am *happy* that this stone is finally turned.
>
> On the other hand I am *unhappy* that you aren't facing any opposition because unfortunately it may just indicate that our community have shrunk considerably and people are instead flaming each other over on Pharo-dev. ;)
>
> regards, Göran


It just means that Squeak is a happier and friendlier place now.

Taking tension out of the community was the only good outcome of the fork.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Environments

Göran Krampe
Hey!

On 06/27/2012 11:29 AM, Bert Freudenberg wrote:

> On 27.06.2012, at 10:35, Göran Krampe wrote:
>
>> Personally I am *happy* that this stone is finally turned.
>>
>> On the other hand I am *unhappy* that you aren't facing any opposition because unfortunately it may just indicate that our community have shrunk considerably and people are instead flaming each other over on Pharo-dev. ;)
>>
>> regards, Göran
>
>
> It just means that Squeak is a happier and friendlier place now.
>
> Taking tension out of the community was the only good outcome of the fork.

Sure, but if it means we are slowly starving to death, it doesn't matter
how friendly it is. ;)

Anyway, at this point I applaud ANY initiatives, so go Colin, go.

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: Environments

Bert Freudenberg
On 27.06.2012, at 11:53, Göran Krampe wrote:

> Hey!
>
> On 06/27/2012 11:29 AM, Bert Freudenberg wrote:
>> On 27.06.2012, at 10:35, Göran Krampe wrote:
>>
>>> Personally I am *happy* that this stone is finally turned.
>>>
>>> On the other hand I am *unhappy* that you aren't facing any opposition because unfortunately it may just indicate that our community have shrunk considerably and people are instead flaming each other over on Pharo-dev. ;)
>>>
>>> regards, Göran
>>
>>
>> It just means that Squeak is a happier and friendlier place now.
>>
>> Taking tension out of the community was the only good outcome of the fork.
>
> Sure, but if it means we are slowly starving to death, it doesn't matter how friendly it is. ;)

Being not as loud as others is hardly the same as starving. And being friendly does matter a lot. To us anyway ;)

- Bert -



Reply | Threaded
Open this post in threaded view
|

Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)

Göran Krampe
On 06/27/2012 12:10 PM, Bert Freudenberg wrote:

> On 27.06.2012, at 11:53, Göran Krampe wrote:
>> Hey!
>>
>> On 06/27/2012 11:29 AM, Bert Freudenberg wrote:
>>> On 27.06.2012, at 10:35, Göran Krampe wrote:
>>>
>>>> Personally I am *happy* that this stone is finally turned.
>>>>
>>>> On the other hand I am *unhappy* that you aren't facing any opposition because unfortunately it may just indicate that our community have shrunk considerably and people are instead flaming each other over on Pharo-dev. ;)
>>>>
>>>> regards, Göran
>>>
>>>
>>> It just means that Squeak is a happier and friendlier place now.
>>>
>>> Taking tension out of the community was the only good outcome of the fork.
>>
>> Sure, but if it means we are slowly starving to death, it doesn't matter how friendly it is. ;)
>
> Being not as loud as others is hardly the same as starving. And being friendly does matter a lot. To us anyway ;)

I definitely agree with the friendly part. That is something I have
always been proud of - the friendliness of our community.

Nevertheless I am still worried that Squeak.org is being starved. It
would be interesting to hear views/ideas from the board (and others) on
this, and possible ways to adapt to it.

Earlier Seaside and web development has been a "driver" behind the
community - the fact that if you build web apps, it doesn't matter how
the backend "looks" (thus the UI of Squeak was of no importance).

These days I am unsure of Squeak's "place" in the world.

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)

dcorking
A few minute ago , Göran Krampe  wrote:

> These days I am unsure of Squeak's "place" in the world.

I think this deserves personal answers. No two Squeakers have the same
world. For me Squeak occupies two important places:

(1) Home of Etoys  (I hope one day that Etoys will be able to move to
a version 4.x Squeak, if it hasn't already.)

(2) Home of an amazing and unique VM. (Pharo doesn't have a VM.)

There other things that count, such as being the platform for
FONC/STEPS at VPRI, and being an integrated image, rather than a
modular one whose source code is harder to search (my unpopular
opinion which I voiced before.)

To all: where is Squeak in your world?

David

Reply | Threaded
Open this post in threaded view
|

Re: Squeak.org starving... and what to do about it - if so. (was Re: [squeak-dev] Environments)

Stéphane Rollandin
In reply to this post by Göran Krampe
> These days I am unsure of Squeak's "place" in the world.

It is the *only* development environment where I can do what I do
(namely, muO).

Squeak may not be precious to many people, but precious it is nonetheless.

Stef


123