Smalltalk › Redline Smalltalk

import: scope ....

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

32 messages Options

Benoit St-Jean-4

Re: import: scope ....

On 08/12/2012 10:02 PM, James Ladd wrote:

I think that IS what we have, and that now we are discussing if the message selector is 'fileIn:' or
'import:' - I have chosen import because FileIn has be name 'File' and the thing being imported
may not be a file, and where is it being Filed?

We also have to handle the case where we need to import a class and then alias it as another name
so we can use it - this helps overcome namespace collisions. The selector in question here is:

import: as:

Lets say there is already a Window class and I want to make use of it in my own code. How do
I distinguish between once name and another - given that for compatibility reasons we don't
currently allow fully qualified class names. ie: you cant do this -

w := com.domain.Window new.

The way to get around this is to use 'import:as:'

self import: 'com.domain.Window' as: 'ExternalWindow'.

w := ExternalWindow new.
On Sun, Dec 9, 2012 at 1:55 PM, Benoit St-Jean <[hidden email]> wrote:
On 08/12/2012 9:48 PM, James Ladd wrote:
When Redline compiles the statements in a file it merely turns them into executable
message sends and it doesn't actually know what one message send is doing from
another.

The statement 'self import: package' sends a message to the script (self) - think Transcript
- telling it to import names into the current scope.

Why is this different to something like Squeak or Pharo? Because they include everything
into memory from a single file (the IMAGE). Redline doesn't have an image and will
therefore need to know where to get the files from. These can be over the network or
locally and requested at Runtime. Hence we need to 'import:' functionality.

Why is the 'import:' not part of the class construction? Well it can be and nothing stops anyone from
following a subclass creation message with a ';' cascade that then asks the class to import a class.
However, keep in mind the situation where you need to do this:

SomeClass subclass: #OtherClass

AND SomeClass is not in scope because it has not been imported yet. Who do you send the message
to in that case?

- James.

On Sun, Dec 9, 2012 at 1:40 PM, Benoit St-Jean <[hidden email]> wrote:

Am I missing something ?

So code could come from files, url, anything? Then why don't we just have base classes (locally) and mimic a FileIn operation that would import code (and keep a reference to its location) and keep a copy locally. The files on local hard disk would then constitute the image. Wouldn't that be more "Smalltalkish" ?!?!

-- ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

Perhaps the proper name would be "load", just like you can load parcels from files and even load code from a website (The Cincom Public Repository) in VisualWorks. We'll need namespaces eventually (since code could come from all over the place) but I strongly suggest we make it simple and set as a goal to have the Pharo bases classes "migrated" to Redline first and then deal with namespaces and imports/loads. Let's make redline behave like Smalltalk/Pharo and then we'll have the tools and code to enhance it easily.

Well, that's my way of seing it!

-- 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

James Ladd

Re: import: scope ....

I agree with the Pharo compatibility and we are aiming for that.
Only difference right now is the 'import:' statement.

Please remember that Redline Smalltalk is not just about moving Smalltalk onto the JVM
but also Java developers onto Smalltalk. Therefore, some of the things we think make
perfect sense in the Smalltalk world have to take into account the Java world.

Great to hear your thoughts.

- James.

On Sun, Dec 9, 2012 at 2:10 PM, Benoit St-Jean <[hidden email]> wrote:

On 08/12/2012 10:02 PM, James Ladd wrote:
I think that IS what we have, and that now we are discussing if the message selector is 'fileIn:' or
'import:' - I have chosen import because FileIn has be name 'File' and the thing being imported
may not be a file, and where is it being Filed?

We also have to handle the case where we need to import a class and then alias it as another name
so we can use it - this helps overcome namespace collisions. The selector in question here is:

import: as:

Lets say there is already a Window class and I want to make use of it in my own code. How do
I distinguish between once name and another - given that for compatibility reasons we don't
currently allow fully qualified class names. ie: you cant do this -

w := com.domain.Window new.

The way to get around this is to use 'import:as:'

self import: 'com.domain.Window' as: 'ExternalWindow'.

w := ExternalWindow new.
On Sun, Dec 9, 2012 at 1:55 PM, Benoit St-Jean <[hidden email]> wrote:
On 08/12/2012 9:48 PM, James Ladd wrote:
When Redline compiles the statements in a file it merely turns them into executable
message sends and it doesn't actually know what one message send is doing from
another.

The statement 'self import: package' sends a message to the script (self) - think Transcript
- telling it to import names into the current scope.

Why is this different to something like Squeak or Pharo? Because they include everything
into memory from a single file (the IMAGE). Redline doesn't have an image and will
therefore need to know where to get the files from. These can be over the network or
locally and requested at Runtime. Hence we need to 'import:' functionality.

Why is the 'import:' not part of the class construction? Well it can be and nothing stops anyone from
following a subclass creation message with a ';' cascade that then asks the class to import a class.
However, keep in mind the situation where you need to do this:

SomeClass subclass: #OtherClass

AND SomeClass is not in scope because it has not been imported yet. Who do you send the message
to in that case?

- James.

On Sun, Dec 9, 2012 at 1:40 PM, Benoit St-Jean <[hidden email]> wrote:

Am I missing something ?

So code could come from files, url, anything? Then why don't we just have base classes (locally) and mimic a FileIn operation that would import code (and keep a reference to its location) and keep a copy locally. The files on local hard disk would then constitute the image. Wouldn't that be more "Smalltalkish" ?!?!

-- ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
Perhaps the proper name would be "load", just like you can load parcels from files and even load code from a website (The Cincom Public Repository) in VisualWorks. We'll need namespaces eventually (since code could come from all over the place) but I strongly suggest we make it simple and set as a goal to have the Pharo bases classes "migrated" to Redline first and then deal with namespaces and imports/loads. Let's make redline behave like Smalltalk/Pharo and then we'll have the tools and code to enhance it easily.

Well, that's my way of seing it!
-- 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

James Ladd

Re: import: scope ....

To keep you all informed, the fix for automatically importing the classes at the same scope as
current class should be available tomorrow.

On Sun, Dec 9, 2012 at 2:12 PM, James Ladd <[hidden email]> wrote:

I agree with the Pharo compatibility and we are aiming for that.
Only difference right now is the 'import:' statement.

Please remember that Redline Smalltalk is not just about moving Smalltalk onto the JVM
but also Java developers onto Smalltalk. Therefore, some of the things we think make
perfect sense in the Smalltalk world have to take into account the Java world.

Great to hear your thoughts.

- James.
On Sun, Dec 9, 2012 at 2:10 PM, Benoit St-Jean <[hidden email]> wrote:
On 08/12/2012 10:02 PM, James Ladd wrote:
I think that IS what we have, and that now we are discussing if the message selector is 'fileIn:' or
'import:' - I have chosen import because FileIn has be name 'File' and the thing being imported
may not be a file, and where is it being Filed?

We also have to handle the case where we need to import a class and then alias it as another name
so we can use it - this helps overcome namespace collisions. The selector in question here is:

import: as:

Lets say there is already a Window class and I want to make use of it in my own code. How do
I distinguish between once name and another - given that for compatibility reasons we don't
currently allow fully qualified class names. ie: you cant do this -

w := com.domain.Window new.

The way to get around this is to use 'import:as:'

self import: 'com.domain.Window' as: 'ExternalWindow'.

w := ExternalWindow new.
On Sun, Dec 9, 2012 at 1:55 PM, Benoit St-Jean <[hidden email]> wrote:
On 08/12/2012 9:48 PM, James Ladd wrote:
When Redline compiles the statements in a file it merely turns them into executable
message sends and it doesn't actually know what one message send is doing from
another.

The statement 'self import: package' sends a message to the script (self) - think Transcript
- telling it to import names into the current scope.

Why is this different to something like Squeak or Pharo? Because they include everything
into memory from a single file (the IMAGE). Redline doesn't have an image and will
therefore need to know where to get the files from. These can be over the network or
locally and requested at Runtime. Hence we need to 'import:' functionality.

Why is the 'import:' not part of the class construction? Well it can be and nothing stops anyone from
following a subclass creation message with a ';' cascade that then asks the class to import a class.
However, keep in mind the situation where you need to do this:

SomeClass subclass: #OtherClass

AND SomeClass is not in scope because it has not been imported yet. Who do you send the message
to in that case?

- James.

On Sun, Dec 9, 2012 at 1:40 PM, Benoit St-Jean <[hidden email]> wrote:

Am I missing something ?

So code could come from files, url, anything? Then why don't we just have base classes (locally) and mimic a FileIn operation that would import code (and keep a reference to its location) and keep a copy locally. The files on local hard disk would then constitute the image. Wouldn't that be more "Smalltalkish" ?!?!

-- ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
Perhaps the proper name would be "load", just like you can load parcels from files and even load code from a website (The Cincom Public Repository) in VisualWorks. We'll need namespaces eventually (since code could come from all over the place) but I strongly suggest we make it simple and set as a goal to have the Pharo bases classes "migrated" to Redline first and then deal with namespaces and imports/loads. Let's make redline behave like Smalltalk/Pharo and then we'll have the tools and code to enhance it easily.

Well, that's my way of seing it!
-- 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

picoVerse

Re: import: scope ....

In reply to this post by James Ladd

I agree too many shorthand notations can be a burden as Les says.

Every time you make a short hand notation then you have to tell everybody how it works.

It becomes an effort to have to remember all the shortcuts and jim jams.

But if the short cut can be looked up in the source browser then I'm okay with that.

The thing I like about Smalltalk is that you can find things out for yourself in the source repository using all the tools.

But it is true that if you tell one person they can tell another and so on. And that's how the mailing lists work.

But it would be nice to be able to say it once. And not have to keep repeating it. Which is what happens if there is no short cut defined. So I agree that import: should be changed to self import: .

Or how about

SelfThisFile import:

You may think this is too blunt or too long or not created here but it is self documenting.

self thisFile import:

Maybe there could be several ways of varying self documenting.

-Kjell E Godo

@kegodo

On Saturday, December 8, 2012 7:12:57 PM UTC-8, jamesl wrote:

I agree with the Pharo compatibility and we are aiming for that.
Only difference right now is the 'import:' statement.

Please remember that Redline Smalltalk is not just about moving Smalltalk onto the JVM
but also Java developers onto Smalltalk. Therefore, some of the things we think make
perfect sense in the Smalltalk world have to take into account the Java world.

Great to hear your thoughts.

- James.
On Sun, Dec 9, 2012 at 2:10 PM, Benoit St-Jean <<A href="javascript:" target=_blank gdf-obfuscated-mailto="39YjnZIzrLwJ">benoit...@...> wrote:
On 08/12/2012 10:02 PM, James Ladd wrote:
I think that IS what we have, and that now we are discussing if the message selector is 'fileIn:' or
'import:' - I have chosen import because FileIn has be name 'File' and the thing being imported
may not be a file, and where is it being Filed?

We also have to handle the case where we need to import a class and then alias it as another name
so we can use it - this helps overcome namespace collisions. The selector in question here is:

import: as:

Lets say there is already a Window class and I want to make use of it in my own code. How do
I distinguish between once name and another - given that for compatibility reasons we don't
currently allow fully qualified class names. ie: you cant do this -

w := com.domain.Window new.

The way to get around this is to use 'import:as:'

self import: 'com.domain.Window' as: 'ExternalWindow'.

w := ExternalWindow new.
On Sun, Dec 9, 2012 at 1:55 PM, Benoit St-Jean <<A href="javascript:" target=_blank gdf-obfuscated-mailto="39YjnZIzrLwJ">benoit...@...> wrote:
On 08/12/2012 9:48 PM, James Ladd wrote:
When Redline compiles the statements in a file it merely turns them into executable
message sends and it doesn't actually know what one message send is doing from
another.

The statement 'self import: package' sends a message to the script (self) - think Transcript
- telling it to import names into the current scope.

Why is this different to something like Squeak or Pharo? Because they include everything
into memory from a single file (the IMAGE). Redline doesn't have an image and will
therefore need to know where to get the files from. These can be over the network or
locally and requested at Runtime. Hence we need to 'import:' functionality.

Why is the 'import:' not part of the class construction? Well it can be and nothing stops anyone from
following a subclass creation message with a ';' cascade that then asks the class to import a class.
However, keep in mind the situation where you need to do this:

SomeClass subclass: #OtherClass

AND SomeClass is not in scope because it has not been imported yet. Who do you send the message
to in that case?

- James.

On Sun, Dec 9, 2012 at 1:40 PM, Benoit St-Jean <<A href="javascript:" target=_blank gdf-obfuscated-mailto="39YjnZIzrLwJ">benoit...@...> wrote:

Am I missing something ?

So code could come from files, url, anything? Then why don't we just have base classes (locally) and mimic a FileIn operation that would import code (and keep a reference to its location) and keep a copy locally. The files on local hard disk would then constitute the image. Wouldn't that be more "Smalltalkish" ?!?!

-- ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
Perhaps the proper name would be "load", just like you can load parcels from files and even load code from a website (The Cincom Public Repository) in VisualWorks. We'll need namespaces eventually (since code could come from all over the place) but I strongly suggest we make it simple and set as a goal to have the Pharo bases classes "migrated" to Redline first and then deal with namespaces and imports/loads. Let's make redline behave like Smalltalk/Pharo and then we'll have the tools and code to enhance it easily.

Well, that's my way of seing it!
-- 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

picoVerse

Re: import: scope ....

In reply to this post by James Ladd

I agree with Les that too many shortcuts can be a burden.

You have to tell everybody what they are.

How about

SelfThisFile import:

self thisFile import:

-Kjell E Godo

On Sunday, December 9, 2012 9:56:33 PM UTC-8, jamesl wrote:

To keep you all informed, the fix for automatically importing the classes at the same scope as
current class should be available tomorrow.
On Sun, Dec 9, 2012 at 2:12 PM, James Ladd <<A href="javascript:" target=_blank gdf-obfuscated-mailto="wn1-VvZ8jwQJ">ladd....@...> wrote:
I agree with the Pharo compatibility and we are aiming for that.
Only difference right now is the 'import:' statement.

Please remember that Redline Smalltalk is not just about moving Smalltalk onto the JVM
but also Java developers onto Smalltalk. Therefore, some of the things we think make
perfect sense in the Smalltalk world have to take into account the Java world.

Great to hear your thoughts.

- James.
On Sun, Dec 9, 2012 at 2:10 PM, Benoit St-Jean <<A href="javascript:" target=_blank gdf-obfuscated-mailto="wn1-VvZ8jwQJ">benoit...@...> wrote:
On 08/12/2012 10:02 PM, James Ladd wrote:
I think that IS what we have, and that now we are discussing if the message selector is 'fileIn:' or
'import:' - I have chosen import because FileIn has be name 'File' and the thing being imported
may not be a file, and where is it being Filed?

We also have to handle the case where we need to import a class and then alias it as another name
so we can use it - this helps overcome namespace collisions. The selector in question here is:

import: as:

Lets say there is already a Window class and I want to make use of it in my own code. How do
I distinguish between once name and another - given that for compatibility reasons we don't
currently allow fully qualified class names. ie: you cant do this -

w := com.domain.Window new.

The way to get around this is to use 'import:as:'

self import: 'com.domain.Window' as: 'ExternalWindow'.

w := ExternalWindow new.
On Sun, Dec 9, 2012 at 1:55 PM, Benoit St-Jean <<A href="javascript:" target=_blank gdf-obfuscated-mailto="wn1-VvZ8jwQJ">benoit...@...> wrote:
On 08/12/2012 9:48 PM, James Ladd wrote:
When Redline compiles the statements in a file it merely turns them into executable
message sends and it doesn't actually know what one message send is doing from
another.

The statement 'self import: package' sends a message to the script (self) - think Transcript
- telling it to import names into the current scope.

Why is this different to something like Squeak or Pharo? Because they include everything
into memory from a single file (the IMAGE). Redline doesn't have an image and will
therefore need to know where to get the files from. These can be over the network or
locally and requested at Runtime. Hence we need to 'import:' functionality.

Why is the 'import:' not part of the class construction? Well it can be and nothing stops anyone from
following a subclass creation message with a ';' cascade that then asks the class to import a class.
However, keep in mind the situation where you need to do this:

SomeClass subclass: #OtherClass

AND SomeClass is not in scope because it has not been imported yet. Who do you send the message
to in that case?

- James.

On Sun, Dec 9, 2012 at 1:40 PM, Benoit St-Jean <<A href="javascript:" target=_blank gdf-obfuscated-mailto="wn1-VvZ8jwQJ">benoit...@...> wrote:

Am I missing something ?

So code could come from files, url, anything? Then why don't we just have base classes (locally) and mimic a FileIn operation that would import code (and keep a reference to its location) and keep a copy locally. The files on local hard disk would then constitute the image. Wouldn't that be more "Smalltalkish" ?!?!

-- ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
Perhaps the proper name would be "load", just like you can load parcels from files and even load code from a website (The Cincom Public Repository) in VisualWorks. We'll need namespaces eventually (since code could come from all over the place) but I strongly suggest we make it simple and set as a goal to have the Pharo bases classes "migrated" to Redline first and then deal with namespaces and imports/loads. Let's make redline behave like Smalltalk/Pharo and then we'll have the tools and code to enhance it easily.

Well, that's my way of seing it!
-- 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

Les Hazlewood

Re: import: scope ....

In reply to this post by James Ladd

SomeClass subclass: #OtherClass

AND SomeClass is not in scope because it has not been imported yet. Who do you send the message
to in that case?

I think your example (and the scripting scenario, which I wasn't thinking of) make a strong argument in favor of supporting the self import: message selector at the script/file/Eigenclass level. If I'm not mistaken, traditional Smalltalk environments can't be used for scripting (e.g. shell scripts, etc), and so they don't have to worry about this issue.

And with the adjustments you made (to include a 'self' receiver of the import message), you can chain messages:

self

import: 'com.foo.Whatever';

...

import: 'org.bar.SomeClass'.

SomeClass subclass: #OtherClass ...

This has the effect of still being (very nearly) as succinct as before, looks (very nearly) like what a JVM developer expects to see at the top of a file, but it doesn't appear to violate any Smalltalk messaging semantics.

If Redline goes with this approach, I just think it needs to be very clearly documented what 'self' is in this case. Seeing it is still weird if you've used traditional Smalltalk environments, but once you understand what is going on, you can get over it pretty quickly and move on IMO.

My .02,

Les

James Ladd

Re: import: scope ....

Hi Les,

Bingo!

I toyed with the idea of making it

Smalltalk import: ....

but the scope was the file/script and the classes defined within it, not every class in memory.

AND YES - Redline enables Smalltalk to be used as a scripting language, although I typically
only write enough script to start talking to objects.

(I'm getting to your other post)

- James.

On Tue, Dec 11, 2012 at 3:23 PM, Les Hazlewood <[hidden email]> wrote:

This has the effect of still being (very nearly) as succinct as before, looks (very nearly) like what a JVM developer expects to see at the top of a file, but it doesn't appear to violate any Smalltalk messaging semantics.

Les Hazlewood

Re: import: scope ....

In reply to this post by James Ladd

Lets say there is already a Window class and I want to make use of it in my own code. How do
I distinguish between once name and another - given that for compatibility reasons we don't
currently allow fully qualified class names. ie: you cant do this -

w := com.domain.Window new.

The way to get around this is to use 'import:as:'

self import: 'com.domain.Window' as: 'ExternalWindow'.

w := ExternalWindow new.

By 'compatibility reasons', you mean Smalltalk grammar compatibility?

This is a bit weird to Java developers, but I think I'd still vote in favor of valid Smalltalk grammar.

To alleviate this concern for those that prefer (stylistically) a more Java-like approach, I suppose something like the following could be provided:

Class named: 'com.domain.Window' new.

or even cooler:

'com.domain.Window' asClass new.

I couldn't speak to what performance difference this might have vs. the self import:as: approach however.

Les

P.S. I think 'import' as a name is as good as 'load' or similar 'bring stuff into scope' names. It's also what JVM devs are familiar with.

James Ladd

Re: import: scope ....

>>By 'compatibility reasons', you mean Smalltalk grammar compatibility?
Yes, the grammar for Smalltalk is actually really hard because of the nuanced cases.
When is a '.' an expression terminator, a decimal point or a package separator?
Given the lack of other punctuation in Smalltalk disambiguation is hard.

On Tue, Dec 11, 2012 at 3:45 PM, Les Hazlewood <[hidden email]> wrote:

Lets say there is already a Window class and I want to make use of it in my own code. How do
I distinguish between once name and another - given that for compatibility reasons we don't
currently allow fully qualified class names. ie: you cant do this -

w := com.domain.Window new.

The way to get around this is to use 'import:as:'

self import: 'com.domain.Window' as: 'ExternalWindow'.

w := ExternalWindow new.

By 'compatibility reasons', you mean Smalltalk grammar compatibility?

This is a bit weird to Java developers, but I think I'd still vote in favor of valid Smalltalk grammar.

To alleviate this concern for those that prefer (stylistically) a more Java-like approach, I suppose something like the following could be provided:

Class named: 'com.domain.Window' new.

or even cooler:

'com.domain.Window' asClass new.

I couldn't speak to what performance difference this might have vs. the self import:as: approach however.

Les

P.S. I think 'import' as a name is as good as 'load' or similar 'bring stuff into scope' names. It's also what JVM devs are familiar with.

Brian Brown-5

Re: import: scope ....

One of the main things I like about the current approach Redline is taking over what we traditionally have with mainstream Smalltalk implementations is the "explicit include" vs. "explicit exclude". VisualWorks and Dolphin, for example, have whole subsystems for deploying your Smalltalk application that primarily:

Figure out what classes you are actually using
Strip out everything you don't use for this particular application
Build a bootstrap that loads your shrunken image

I can recall several efforts in the Squeak/Pharo world of "minimal" images, to the extreme of the Spoon project (which monitors message sends and loads the absolute minimum code into a slave image). Also, there have been large debate of name spacing - which VisualWorks has, but all efforts to include in Squeak/Pharo have been killed due to lack of consensus (at least when I was paying attention).

Redline has a very succinct solution to both issues - import:as: gives enough name spacing to be practical, and importing in general takes care of pairing your app to what it needs as opposed to having the kitchen sink.

I do understand and appreciate how this deviates from traditional Smalltalk and is more Pythonic or Javaesque in terms of namespace management, but (arguably, of course), namespaces are needed and I sort of expect them to be available to me from a code management perspective; The closest thing they have in Squeak/Pharo are PackageInfo instances, but those do not affect visibility of classes, they are more focused on the loading and unloading of code, as well as giving one more level of code organization in the class browser.

This issue is also a problem in current Javascript implementations - it's much easier to write code in CoffeeScript and have nodejs compile it all into and "image" like state to use in the global browser namespace.

My .00002 cents.

- Brian

James Ladd

Re: import: scope ....

Thank you for the post.
This sort of feedback will help 'shape' Redline into a very productive
environment. :)
- James.

On Sat, Dec 29, 2012 at 5:29 AM, Brian Brown <[hidden email]> wrote:

One of the main things I like about the current approach Redline is taking over what we traditionally have with mainstream Smalltalk implementations is the "explicit include" vs. "explicit exclude". VisualWorks and Dolphin, for example, have whole subsystems for deploying your Smalltalk application that primarily:

Figure out what classes you are actually using
Strip out everything you don't use for this particular application

Build a bootstrap that loads your shrunken image
I can recall several efforts in the Squeak/Pharo world of "minimal" images, to the extreme of the Spoon project (which monitors message sends and loads the absolute minimum code into a slave image). Also, there have been large debate of name spacing - which VisualWorks has, but all efforts to include in Squeak/Pharo have been killed due to lack of consensus (at least when I was paying attention).

Redline has a very succinct solution to both issues - import:as: gives enough name spacing to be practical, and importing in general takes care of pairing your app to what it needs as opposed to having the kitchen sink.

I do understand and appreciate how this deviates from traditional Smalltalk and is more Pythonic or Javaesque in terms of namespace management, but (arguably, of course), namespaces are needed and I sort of expect them to be available to me from a code management perspective; The closest thing they have in Squeak/Pharo are PackageInfo instances, but those do not affect visibility of classes, they are more focused on the loading and unloading of code, as well as giving one more level of code organization in the class browser.

This issue is also a problem in current Javascript implementations - it's much easier to write code in CoffeeScript and have nodejs compile it all into and "image" like state to use in the global browser namespace.

My .00002 cents.

- Brian

Benoit St-Jean-4

Re: import: scope ....

In reply to this post by Brian Brown-5

On 28/12/2012 1:29 PM, Brian Brown wrote:

One of the main things I like about the current approach Redline is taking over what we traditionally have with mainstream Smalltalk implementations is the "explicit include" vs. "explicit exclude". VisualWorks and Dolphin, for example, have whole subsystems for deploying your Smalltalk application that primarily:

Figure out what classes you are actually using

Strip out everything you don't use for this particular application

Build a bootstrap that loads your shrunken image

I can recall several efforts in the Squeak/Pharo world of "minimal" images, to the extreme of the Spoon project (which monitors message sends and loads the absolute minimum code into a slave image). Also, there have been large debate of name spacing - which VisualWorks has, but all efforts to include in Squeak/Pharo have been killed due to lack of consensus (at least when I was paying attention).

Redline has a very succinct solution to both issues - import:as: gives enough name spacing to be practical, and importing in general takes care of pairing your app to what it needs as opposed to having the kitchen sink.

I do understand and appreciate how this deviates from traditional Smalltalk and is more Pythonic or Javaesque in terms of namespace management, but (arguably, of course), namespaces are needed and I sort of expect them to be available to me from a code management perspective; The closest thing they have in Squeak/Pharo are PackageInfo instances, but those do not affect visibility of classes, they are more focused on the loading and unloading of code, as well as giving one more level of code organization in the class browser.

This issue is also a problem in current Javascript implementations - it's much easier to write code in CoffeeScript and have nodejs compile it all into and "image" like state to use in the global browser namespace.

My .00002 cents.

- Brian

VisualWorks and Dolphin do a decent job when it comes to stripping and packaging. In this regard, I've always thought that VAST was better at packaging. I have never encountered a packaging problem with VAST as opposed to Dolphin or VW. I tend to be on the side of "automating" the process rather than rely on humans to do the job. In fairly complex systems with 5000+ classes, I'm more inclined to think that a program/algorithm/tool will do a better job than developers when it comes to stripping/packaging !

-- 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)