Class visibility ...
Locked
 
|
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. |
|
|
> 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 |
|
|
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:
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? 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.
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, Your welcome. Keep the questions coming. |
|
|
>> 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 |
|
|
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:
|
|
|
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. |
|
|
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:
|
|
|
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:
|
|
|
Thanks for clarifying. Good point.
On Sun, Dec 9, 2012 at 1:21 PM, Pat Maddox <[hidden email]> wrote:
|
|
|
In reply to this post by Les Hazlewood
On Sat, Dec 8, 2012 at 12:48 PM, Les Hazlewood <[hidden email]> wrote:
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 |
|
|
Thanks for this Randy. Can you provide and example of defining a namespace w import? - James Sent from Hyperspace.
|
|
|
On Sun, Dec 9, 2012 at 12:55 PM, James Ladd <[hidden email]> wrote: --
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 |
|
|
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:
|
|
|
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
|
«
Return to Redline Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |