Class visibility ...

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

Class visibility ...

James Ladd
Please read this whole post as it is important.

Currently when a class refers to another it is required to import it.
For example:

Object < #ClassA.
- makeThing
  ^ Thing new.

In the code above the Thing class will not be found because the compiler doesn't know where
to find it (unless it is in one of the default look up paths).

To get around this limitation / annoyance right now you need to import that class with the
import selector like so:

import: 'com.domain.Thing'.
Object < #ClassA.
- makeThing
  ^ Thing new.

This is pretty crappy and I will fix it a.s.a.p.

Classes in the same packages will automatically be found. Those above or below will not
and will require importing.
For example:

com/domain/foo/Bar
com/domain/foo/Baz
com/domain/foo/thing/Fred
com/domain/App

In the above example the class Bar will be able to reference Baz without requiring an import.
However, to reference Fred or App is will.
Likewise, for App to reference any other class it will need an import.

I'll get this fix out a.s.a.p

- James.
Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

Les Hazlewood
> To get around this limitation / annoyance right now you need to import that
> class with the
> import selector like so:
>
> import: 'com.domain.Thing'.
> Object < #ClassA.
> - makeThing
>   ^ Thing new.
>
> This is pretty crappy and I will fix it a.s.a.p.

I have 2 questions.

1.  Why is this 'pretty crappy'?

This is expected in most (all?) JVM-hosted languages, so I'm not
surprised by it, nor would I be offended if it was required.  What is
the proposed solution?

Or are you saying that even referencing classes in the same package
require an import today? (If so, then yes, I see your point and this
burden should be removed).

2.  How do existing Smalltalk environments do this?

I admit that I've only played with things like Squeak and Pharo in the
academic sense (haven't built an app in them yet, and hopefully that
will change soon enough), but there is no concept of imports.

How do these environments provide access to classes without imports?
You could use a system classSimpleName-to-Class dictionary available
to all classes so imports wouldn't be required.  I _assume_ this is
how existing Smalltalk environments work today.

But in these existing Smalltalk runtimes, what do they do when there
are two classes named exactly the same?

Regards,

Les
Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

James Ladd
Hi Les,

Answers inline - BTW - Im working on the changes now - right now :)

- James.

On Sun, Dec 9, 2012 at 7:48 AM, Les Hazlewood <[hidden email]> wrote:
> To get around this limitation / annoyance right now you need to import that
> class with the
> import selector like so:
>
> import: 'com.domain.Thing'.
> Object < #ClassA.
> - makeThing
>   ^ Thing new.
>
> This is pretty crappy and I will fix it a.s.a.p.

I have 2 questions.

1.  Why is this 'pretty crappy'?

This is expected in most (all?) JVM-hosted languages, so I'm not
surprised by it, nor would I be offended if it was required.  What is
the proposed solution?

Or are you saying that even referencing classes in the same package
require an import today? (If so, then yes, I see your point and this
burden should be removed).

Yes - even referencing classes in the same package require an import today?
Removing this need now. Classes in same package should be visible automatically.
 
2.  How do existing Smalltalk environments do this?

I admit that I've only played with things like Squeak and Pharo in the
academic sense (haven't built an app in them yet, and hopefully that
will change soon enough), but there is no concept of imports.
 
Existing Smalltalk implementations see every class because they are all in
the same Image and therefore the same package/namespace.
Pharo doesn't have a concept of namespaces or packages. Redline believes
these are necessary. See answer to your question below.
 

How do these environments provide access to classes without imports?
You could use a system classSimpleName-to-Class dictionary available
to all classes so imports wouldn't be required.  I _assume_ this is
how existing Smalltalk environments work today.

But in these existing Smalltalk runtimes, what do they do when there
are two classes named exactly the same?
 
Existing Smalltalk implementations like Pharo require you to change your class names
so they don't class. Not satisfactory in my view. We need meaningful names not mangled
names to fit in with a limitation.
 
Regards,

Les

Your welcome. Keep the questions coming.

Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

Les Hazlewood
>> But in these existing Smalltalk runtimes, what do they do when there
>> are two classes named exactly the same?
>
>
> Existing Smalltalk implementations like Pharo require you to change your
> class names so they don't clash.

Fascinating!

With the advent of Metacello/Monticello providing a way for the
Smalltalk community to easily share packages ('categories'), I'd be
amazed if modern Smalltalk environments didn't find regular conflicts:

i.e. package developer A creates a Foo class and package developer B
creates a Foo class and my project includes A and B and BAM.
Implosion.

So yes, it makes sense to support packages (categories).  You pretty
much _have_ to support this if you want to integrate with the
thousands of existing Java projects, which I'm sure is a large part of
the appeal of using Redline.

Thanks for clarifying!

Best,

Les
Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

James Ladd
It is boggling that Smalltalk (Pharo) doesn't have namespaces.
We have not used the term 'category:' to be the namespace as
it isn't clear to all that a 'category:' is a package. Personally this IS
how I see it.

You can call Redline Smalltalk classes from Java so making the
package/category fit the JVM model make things just work.
(Note it is the JVM that has the package model which is reflected in
the Java language.)

BTW - Keep the questions coming as they help draw out details for
all.

- James.

On Sun, Dec 9, 2012 at 9:18 AM, Les Hazlewood <[hidden email]> wrote:
>> But in these existing Smalltalk runtimes, what do they do when there
>> are two classes named exactly the same?
>
>
> Existing Smalltalk implementations like Pharo require you to change your
> class names so they don't clash.

Fascinating!

With the advent of Metacello/Monticello providing a way for the
Smalltalk community to easily share packages ('categories'), I'd be
amazed if modern Smalltalk environments didn't find regular conflicts:

i.e. package developer A creates a Foo class and package developer B
creates a Foo class and my project includes A and B and BAM.
Implosion.

So yes, it makes sense to support packages (categories).  You pretty
much _have_ to support this if you want to integrate with the
thousands of existing Java projects, which I'm sure is a large part of
the appeal of using Redline.

Thanks for clarifying!

Best,

Les

Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

patmaddox
Ruby & Pharo have done just fine without namespaces for a long time. -Pat

On Dec 8, 2012, at 2:23 PM, James Ladd wrote:
It is boggling that Smalltalk (Pharo) doesn't have namespaces.
We have not used the term 'category:' to be the namespace as
it isn't clear to all that a 'category:' is a package. Personally this IS
how I see it.

You can call Redline Smalltalk classes from Java so making the
package/category fit the JVM model make things just work.
(Note it is the JVM that has the package model which is reflected in
the Java language.)

BTW - Keep the questions coming as they help draw out details for
all.

- James.

On Sun, Dec 9, 2012 at 9:18 AM, Les Hazlewood <[hidden email]> wrote:
>> But in these existing Smalltalk runtimes, what do they do when there
>> are two classes named exactly the same?
>
>
> Existing Smalltalk implementations like Pharo require you to change your
> class names so they don't clash.

Fascinating!

With the advent of Metacello/Monticello providing a way for the
Smalltalk community to easily share packages ('categories'), I'd be
amazed if modern Smalltalk environments didn't find regular conflicts:

i.e. package developer A creates a Foo class and package developer B
creates a Foo class and my project includes A and B and BAM.
Implosion.

So yes, it makes sense to support packages (categories).  You pretty
much _have_ to support this if you want to integrate with the
thousands of existing Java projects, which I'm sure is a large part of
the appeal of using Redline.

Thanks for clarifying!

Best,

Les



Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

James Ladd
Doesn't ruby use a module to define a namespace?

module C5
  class Searcher
  end
end

Then use the class like C5::Searcher.new

I know that namespaces are not essential but very useful.



On Sun, Dec 9, 2012 at 1:16 PM, Pat Maddox <[hidden email]> wrote:
Ruby & Pharo have done just fine without namespaces for a long time. -Pat

On Dec 8, 2012, at 2:23 PM, James Ladd wrote:
It is boggling that Smalltalk (Pharo) doesn't have namespaces.
We have not used the term 'category:' to be the namespace as
it isn't clear to all that a 'category:' is a package. Personally this IS
how I see it.

You can call Redline Smalltalk classes from Java so making the
package/category fit the JVM model make things just work.
(Note it is the JVM that has the package model which is reflected in
the Java language.)

BTW - Keep the questions coming as they help draw out details for
all.

- James.

On Sun, Dec 9, 2012 at 9:18 AM, Les Hazlewood <[hidden email]> wrote:
>> But in these existing Smalltalk runtimes, what do they do when there
>> are two classes named exactly the same?
>
>
> Existing Smalltalk implementations like Pharo require you to change your
> class names so they don't clash.

Fascinating!

With the advent of Metacello/Monticello providing a way for the
Smalltalk community to easily share packages ('categories'), I'd be
amazed if modern Smalltalk environments didn't find regular conflicts:

i.e. package developer A creates a Foo class and package developer B
creates a Foo class and my project includes A and B and BAM.
Implosion.

So yes, it makes sense to support packages (categories).  You pretty
much _have_ to support this if you want to integrate with the
thousands of existing Java projects, which I'm sure is a large part of
the appeal of using Redline.

Thanks for clarifying!

Best,

Les




Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

patmaddox
In reply to this post by patmaddox
That's not true namespacing. It doesn't prevent anyone from mistakenly creating another class called C5::Searcher.

Of course, you can do something similar in Smalltalk, just using class methods.

Pat

On Dec 8, 2012, at 6:16 PM, Pat Maddox wrote:
Ruby & Pharo have done just fine without namespaces for a long time. -Pat

On Dec 8, 2012, at 2:23 PM, James Ladd wrote:
It is boggling that Smalltalk (Pharo) doesn't have namespaces.
We have not used the term 'category:' to be the namespace as
it isn't clear to all that a 'category:' is a package. Personally this IS
how I see it.

You can call Redline Smalltalk classes from Java so making the
package/category fit the JVM model make things just work.
(Note it is the JVM that has the package model which is reflected in
the Java language.)

BTW - Keep the questions coming as they help draw out details for
all.

- James.

On Sun, Dec 9, 2012 at 9:18 AM, Les Hazlewood <[hidden email]> wrote:
>> But in these existing Smalltalk runtimes, what do they do when there
>> are two classes named exactly the same?
>
>
> Existing Smalltalk implementations like Pharo require you to change your
> class names so they don't clash.

Fascinating!

With the advent of Metacello/Monticello providing a way for the
Smalltalk community to easily share packages ('categories'), I'd be
amazed if modern Smalltalk environments didn't find regular conflicts:

i.e. package developer A creates a Foo class and package developer B
creates a Foo class and my project includes A and B and BAM.
Implosion.

So yes, it makes sense to support packages (categories).  You pretty
much _have_ to support this if you want to integrate with the
thousands of existing Java projects, which I'm sure is a large part of
the appeal of using Redline.

Thanks for clarifying!

Best,

Les





Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

James Ladd
Thanks for clarifying. Good point.

On Sun, Dec 9, 2012 at 1:21 PM, Pat Maddox <[hidden email]> wrote:
That's not true namespacing. It doesn't prevent anyone from mistakenly creating another class called C5::Searcher.

Of course, you can do something similar in Smalltalk, just using class methods.

Pat

On Dec 8, 2012, at 6:16 PM, Pat Maddox wrote:
Ruby & Pharo have done just fine without namespaces for a long time. -Pat

On Dec 8, 2012, at 2:23 PM, James Ladd wrote:
It is boggling that Smalltalk (Pharo) doesn't have namespaces.
We have not used the term 'category:' to be the namespace as
it isn't clear to all that a 'category:' is a package. Personally this IS
how I see it.

You can call Redline Smalltalk classes from Java so making the
package/category fit the JVM model make things just work.
(Note it is the JVM that has the package model which is reflected in
the Java language.)

BTW - Keep the questions coming as they help draw out details for
all.

- James.

On Sun, Dec 9, 2012 at 9:18 AM, Les Hazlewood <[hidden email]> wrote:
>> But in these existing Smalltalk runtimes, what do they do when there
>> are two classes named exactly the same?
>
>
> Existing Smalltalk implementations like Pharo require you to change your
> class names so they don't clash.

Fascinating!

With the advent of Metacello/Monticello providing a way for the
Smalltalk community to easily share packages ('categories'), I'd be
amazed if modern Smalltalk environments didn't find regular conflicts:

i.e. package developer A creates a Foo class and package developer B
creates a Foo class and my project includes A and B and BAM.
Implosion.

So yes, it makes sense to support packages (categories).  You pretty
much _have_ to support this if you want to integrate with the
thousands of existing Java projects, which I'm sure is a large part of
the appeal of using Redline.

Thanks for clarifying!

Best,

Les






Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

Randy Coulman
In reply to this post by Les Hazlewood

On Sat, Dec 8, 2012 at 12:48 PM, Les Hazlewood <[hidden email]> wrote:

2.  How do existing Smalltalk environments do this?

How do these environments provide access to classes without imports?
You could use a system classSimpleName-to-Class dictionary available
to all classes so imports wouldn't be required.  I _assume_ this is
how existing Smalltalk environments work today.


VisualWorks Smalltalk has namespaces, unlike Pharo and Squeak.  

In VW, you have access to any names in your current namespace automatically.  

Both namespaces and classes can import other names (either class/SharedVariable names, or entire namespaces using a wildcard syntax).  

The imports are part of the class or namespace definition.

These imports can either be private (so only code within the importing namespace can see them) or public (so that the imported names appear to be a direct part of the importing namespace).

You can use absolute references to names (MyNamespace.Nested.MyClass), and that is the only way to resolve conflicts among imported names.  There is no obvious aliasing facility (though you can fake it pretty easily - namespaces just act like dictionaries, so you could add a key to a namespace that points at the same value as another key).

There are also facilities for determining if a name exists or not: #{Namespace.Name} ifDefinedDo: [:binding } ...] and friends.

I'm not sure how relevant this is to the current discussion, but hopefully it provides some backgrround.  VW's namespace implementation has been criticized at times, so it may not be the best model to follow.  From what I understand, Newspeak has a much nicer way of doing namespaces, but I haven't looked into it in any great detail.  Might be worth looking into, though.

Randy
--
Randy Coulman
[hidden email]
Twitter: @randycoulman

Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

James Ladd
Thanks for this Randy.
Can you provide and example of defining a namespace w import?
- James

Sent from Hyperspace.

On 10/12/2012, at 4:16 AM, Randy Coulman <[hidden email]> wrote:


On Sat, Dec 8, 2012 at 12:48 PM, Les Hazlewood <[hidden email]> wrote:

2.  How do existing Smalltalk environments do this?

How do these environments provide access to classes without imports?
You could use a system classSimpleName-to-Class dictionary available
to all classes so imports wouldn't be required.  I _assume_ this is
how existing Smalltalk environments work today.


VisualWorks Smalltalk has namespaces, unlike Pharo and Squeak.  

In VW, you have access to any names in your current namespace automatically.  

Both namespaces and classes can import other names (either class/SharedVariable names, or entire namespaces using a wildcard syntax).  

The imports are part of the class or namespace definition.

These imports can either be private (so only code within the importing namespace can see them) or public (so that the imported names appear to be a direct part of the importing namespace).

You can use absolute references to names (MyNamespace.Nested.MyClass), and that is the only way to resolve conflicts among imported names.  There is no obvious aliasing facility (though you can fake it pretty easily - namespaces just act like dictionaries, so you could add a key to a namespace that points at the same value as another key).

There are also facilities for determining if a name exists or not: #{Namespace.Name} ifDefinedDo: [:binding } ...] and friends.

I'm not sure how relevant this is to the current discussion, but hopefully it provides some backgrround.  VW's namespace implementation has been criticized at times, so it may not be the best model to follow.  From what I understand, Newspeak has a much nicer way of doing namespaces, but I haven't looked into it in any great detail.  Might be worth looking into, though.

Randy
--
Randy Coulman
[hidden email]
Twitter: @randycoulman

Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

Randy Coulman

On Sun, Dec 9, 2012 at 12:55 PM, James Ladd <[hidden email]> wrote:
Can you provide and example of defining a namespace w import?


Smalltalk defineNameSpace: #MyNameSpace
    private: false
    imports: '
                  private Smalltalk.*
                  '
    category: ''

Note that Smalltalk is a namespace as well.  Classes and namespaces in VW are created by sending messages to namespaces, which is not the same as in non-namespaced Smalltalks.

The imports argument is just a string that is then parsed.  I think this is one of the things that people complain about with VW's implementation.

Class imports are similar; you send #defineClass:superclass:indexedType:private:instanceVariableNames:classInstanceVariableNames:imports:category: to a namespace.

Randy 
--
Randy Coulman
[hidden email]
Twitter: @randycoulman

Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

James Ladd
That is interesting.

Redline namespaces or 'packages' are implicit from the location of the source file.
This follows on from the Java compilers approach.

We both use the 'imports:' selector.

 

On Mon, Dec 10, 2012 at 11:24 AM, Randy Coulman <[hidden email]> wrote:

On Sun, Dec 9, 2012 at 12:55 PM, James Ladd <[hidden email]> wrote:
Can you provide and example of defining a namespace w import?


Smalltalk defineNameSpace: #MyNameSpace
    private: false
    imports: '
                  private Smalltalk.*
                  '
    category: ''

Note that Smalltalk is a namespace as well.  Classes and namespaces in VW are created by sending messages to namespaces, which is not the same as in non-namespaced Smalltalks.

The imports argument is just a string that is then parsed.  I think this is one of the things that people complain about with VW's implementation.

Class imports are similar; you send #defineClass:superclass:indexedType:private:instanceVariableNames:classInstanceVariableNames:imports:category: to a namespace.

Randy 
--
Randy Coulman
[hidden email]
Twitter: @randycoulman


Reply | Threaded
Open this post in threaded view
|

Re: Class visibility ...

Les Hazlewood
In reply to this post by patmaddox
This is actually true in Java too: I can create two entirely different com.foo.Whatever classes in two different .jars.  The classloader usually just uses the first one discovered in the classpath.

Cheers,

Les