import: scope ....

I'm a little torn on this one.

The notion of needing to import a Smalltalk class seems very unlike Smalltalk to me.  I think of the import should only be necessary for the Java interop, basically just like java_import in JRuby.  Maybe we should do the Java imports like that?

In the case where I did an import at the top level, like the code you mention first, I would expect that import statement to be scoped available to everything else within that file.

On Oct 16, 2012, at 12:56 AM, jamesl <[hidden email]>

 wrote:

Today a Redline developer pointed out that the following code didn't function as he expected:

import: 'st.redline.Greeting'.

Object < #GreetingCaller.

- greet
  Greeting new go.

At first glance I thought that is was odd for the Greeting class to not be found when the 'greet' message was sent.
Then I looked closer and realized that this may not be an error but a question of scope.

You see 'import:' is expanded in the preprocessor to 'self import:' which means it is being sent to the self at
the scope of the call, in the above case the metaclass that represents the GreetingCaller source file and
not the GreetingCaller class itself.

What I have not tried is this:

Object < #GrettingCaller;
                 import: 'st.redline.Gretting'.

Which should/would import Greeting into the proper scope.

Before I go down the track of and changes I wanted to ask your opinion.

Do you want the top level 'import:' to be visible to the rest of the file?
(Note that behind the scenes this may equate to a message to the enclosing
file metaclass to get its imports. ie: its not a special 'hack'.)

What do you think?







 

Pushed to master.

import: 'package'.

not works as you would expect and the bug shown by another Redline developer is no
longer and issue.

On Sunday, 28 October 2012 09:00:32 UTC+11, jamesl wrote:

Later today I will post the implementation for this.
Then the code below will work as expected.

For those wanting technical details - the eigen class that sends the
messages contained within a .st source file also contains the imports
that are done at the outer scope. Now, the eigen class is kept and
during subclass creation the subclass looks up its eigen class to grab
its imports.


On Tuesday, October 16, 2012 6:56:26 PM UTC+11, jamesl wrote:

Today a Redline developer pointed out that the following code didn't function as he expected:

import: 'st.redline.Greeting'.

Object < #GreetingCaller.

- greet
  Greeting new go.

At first glance I thought that is was odd for the Greeting class to not be found when the 'greet' message was sent.
Then I looked closer and realized that this may not be an error but a question of scope.

You see 'import:' is expanded in the preprocessor to 'self import:' which means it is being sent to the self at
the scope of the call, in the above case the metaclass that represents the GreetingCaller source file and
not the GreetingCaller class itself.

What I have not tried is this:

Object < #GrettingCaller;
                 import: 'st.redline.Gretting'.

Which should/would import Greeting into the proper scope.

Before I go down the track of and changes I wanted to ask your opinion.

Do you want the top level 'import:' to be visible to the rest of the file?
(Note that behind the scenes this may equate to a message to the enclosing
file metaclass to get its imports. ie: its not a special 'hack'.)

What do you think?







 

I realize I am late to this thread as I joined the ML after it was posted, but I have some thoughts on this.  

I spent a good chunk of some evenings over the last month or so reading some amazing resources on Smalltalk, its philosophy and origins, and the path of its construction:

Design Principles Behind Smalltalk: http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

Squeak mailing list thread discussing Smalltalk vs Sun's early HotSpot VM, with Alan Kay himself chiming in: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/016743.html

Alan Kay's (often referenced) response to this thread: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

And this precious gem of Alan Kay's summary of Smalltalk's origins: http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

After reading these materials, I believe Redline's independent/floating 'import: 'binary message feels very much out of place in a Smalltalk environment, even, dare I say, violating Smalltalk principles entirely (and this is coming from a Java programmer who has never programmed in Smalltalk professionally)

I saw the usage/syntax months ago when learning about Redline, and as a Java programmer, thought nothing of it.  But now it feels very weird:

As Allan Kay carefully clarified in the ML response, Smalltalk at its heart is about messaging between self-contained building blocks (components).  Messages from one object are sent to another, i.e. there is always clearly a sender and a receiver, and much of the Smalltalk's beauty is that this fundamental principle holds even at the meta programming level: Classes are themselves first-class objects that also support messaging and can be both manipulated and introspected.

To this end, having an 'import:' binary message at the top of a Redline smalltalk file obscures this fundamental concept: who is the receiver of the 'import:' message?  Is it the Class (that hasn't even been defined yet)?  Is it a system table somewhere?  An object message receiver is always clearly known in traditional Smalltalk environments, as this concept is a fundamental building block of the language.

Instead, I think your second example is much more in-line with Smalltalk's principles, especially that of extending behavior and growing the system for particular needs (but while retaining these primitive-and-immutable building block philosophies):

Object < #GrettingCaller;
                 import: 'st.redline.Gretting'.

So while 'import:' at the top of the file is more aligned with Java programmer expectations, I feel it is a detriment: it alleviates the programmer from truly thinking in the 'Smalltalk Way', which can only hurt them.  

It also might hurt Redline over time: where is it ok to (apparently) violate these principles?  Should some other paradigms be invented or fundamental concessions made to make things easier for Java programmers?  I personally believe making special concessions (at the language level only) is a very dangerous road and should be avoided at all costs.  Of course, because Redline runs on the JVM and is not the entire Smalltalk runtime world, runtime/infrastructural concessions and adjustments will need to be made.  But I don't think this should propagate at the _language_ level at all.

Something like the following might work as well:

Object subclass: #MySubclassName

    instanceVariableNames: ''

    classVariableNames: ''

    poolDictionaries: ''

    category: 'com.foo.whatever'

    imports: 'com.foo.Bar, java.io.InputStream, ...'

Having an 'import:' as a binary message on the class itself makes quite a bit of sense too: Classes are themselves first-class mutable objects in Smalltalk, and so adding an 'import:' after Class construction could be allowed (assuming this makes sense for the Redline compiler, depending on how Java interop works).  This is in the spirit of Smalltalk's extensibility principles (keep the primitives immutable, and allow customization beyond that to your heart's content).

Please forgive the long-winded post, and I respectfully submit my intention was to not step on anyones toes or feelings.  I just feel this is extremely important, as it could potentially set precedents for other approaches in Redline.

Best regards,

Les

See my other response where I mention scripts - will also look into changing examples to use 'import:' as part of subclass creation - stand by.

Sent from Hyperspace.

On 09/12/2012, at 10:03 AM, Les Hazlewood <[hidden email]> wrote:

> Additionally, I would argue imports are not relevant to the Eigenclass
> at all - they're only relevant to the Class being defined, and as
> such, should be encapsulated/represented by that Class only.
>
> It's the same reason why instance and class variable names in
> Smalltalk are defined in the Class subclass message selector and not
> above it in source code.  They are only relevant to the implementation
> details to the Class being defined.  Imports are no different IMO.
>
> I hope that helps!
>
> Best,
>
> Les

Am I missing something ?

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)