Environment's #classNamed:
Locked
 
|
I started playing around with Environments. I thought I could do
something like this: | either | either := Environment named: 'EitherEnv'. [(MCCacheRepository default loadVersionFromFileNamed: 'Either-fbs.9.mcz') load] on: EnvironmentRequest do: [:e | e resume: either]. either Turns out that MCClassDefinition >> #createClass fails because it looks for a superclass' name in Smalltalk, rather than the current Environment. No problem, just hack it for now. OK, carry on. Nope, now EitherEnv doesn't know about a class called #Object. OK, that's because (quite rightly) Environments don't import Smalltalk globals. OK, but then Smalltalk globals must first #exportSelf, or importing it like this: either import: Smalltalk globals. doesn't do anything (because you can only import public declarations). But _still_ EitherEnv can't find the class called #Object. #hasClassNamed: only looks in an Environment's declarations, not its imports. #bindingOf: and #bindingOf:ifAbsent: will look up the imports. Is this intentional? I'd thought that #hasClassNamed: would simply say "yep, I know about a class with that name. Others might call it #XTReadStream, but since I have a prefix-removing import, you know it as #ReadStream." frank |
Re: Environment's #classNamed:
|
|
On 20 December 2013 16:48, Frank Shearar <[hidden email]> wrote:
> I started playing around with Environments. I thought I could do > something like this: > > | either | > either := Environment named: 'EitherEnv'. > [(MCCacheRepository default loadVersionFromFileNamed: > 'Either-fbs.9.mcz') load] on: EnvironmentRequest do: [:e | e resume: > either]. > either It's possible that the above example is simply bogus - #named: takes a _Symbol_ parameter, not a String. (Important, because Environment tracks all its instances in an IdentityDictionary, and of source 'this' == 'this' is false. Anyway, my original question stands - should #classNamed: search through an Environment's references or not? frank |
Re: Environment's #classNamed:
|
|
On Fri, Dec 20, 2013 at 1:33 PM, Frank Shearar <[hidden email]> wrote:
> On 20 December 2013 16:48, Frank Shearar <[hidden email]> wrote: >> I started playing around with Environments. I thought I could do >> something like this: >> >> | either | >> either := Environment named: 'EitherEnv'. >> [(MCCacheRepository default loadVersionFromFileNamed: >> 'Either-fbs.9.mcz') load] on: EnvironmentRequest do: [:e | e resume: >> either]. >> either > > It's possible that the above example is simply bogus - #named: takes a > _Symbol_ parameter, not a String. (Important, because Environment > tracks all its instances in an IdentityDictionary, and of source > 'this' == 'this' is false. > > Anyway, my original question stands - should #classNamed: search > through an Environment's references or not? hasClassNamed: is tangential to bindingOf:; a similar type of access. So, yes, I think it should. And, also, let me pose an additional question: Why do we need 'exports' at all? The use-case we're solving is name-disambiguation, period. Exports seems to be about making certain classes "unimportable", e.g., "private". Why are exports needed at all? |
Re: Environment's #classNamed:
|
|
In reply to this post by Frank Shearar-3
On Fri, Dec 20, 2013 at 2:33 PM, Frank Shearar <[hidden email]> wrote:
Yes, I think so, since it's mostly used for asking "can I use this class?" |
Re: Environment's #classNamed:
|
|
In reply to this post by Chris Muller-3
On Fri, Dec 20, 2013 at 3:04 PM, Chris Muller <[hidden email]> wrote:
And, also, let me pose an additional question: Why do we need Name disambiguation is *one* of the use cases. Private classes is another one. I'd really like to be able to set up an Xtreams environment properly.
See the discussion on Xtreams here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html |
Re: Environment's #classNamed:
|
|
Yes, I had already gone back and read that several days ago when I
made the decision to finally get into Environments. That thread is a gem for getting started understanding Environments. Colin, Environments is exactly how I think the namespace problem should be solved -- I see it as dynamic renames during loading time (vs. a grand global namespace like Java). Kudos for bringing this to life. What still remains a mystery (for me) is why we need this extra complication -- e.g., why can't I simply _import_ from other Environments. Instead, I can only import from other Environments what I've declared as their _exports_. This does not seem to be in the spirit of Smalltalk -- having to "declare" the class-API's before I can use them. I have to keep these two things "in-sync" with each other: An Environments exports with the other environments imports. It reminds me somewhat of static-typing in that it's simply a "chore" I have to do for the satisfaction of the computer but no real benefit (that I can identify) for the developer... On Sat, Dec 21, 2013 at 6:53 PM, Colin Putney <[hidden email]> wrote: > > > > On Fri, Dec 20, 2013 at 3:04 PM, Chris Muller <[hidden email]> wrote: > >> >> And, also, let me pose an additional question: Why do we need >> 'exports' at all? The use-case we're solving is name-disambiguation, >> period. Exports seems to be about making certain classes >> "unimportable", e.g., "private". >> >> Why are exports needed at all? > > > Name disambiguation is *one* of the use cases. Private classes is another > one. I'd really like to be able to set up an Xtreams environment properly. > See the discussion on Xtreams here: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html > > > |
Re: Environment's #classNamed:
|
|
On 22 December 2013 18:16, Chris Muller <[hidden email]> wrote:
> Yes, I had already gone back and read that several days ago when I > made the decision to finally get into Environments. That thread is a > gem for getting started understanding Environments. > > Colin, Environments is exactly how I think the namespace problem > should be solved -- I see it as dynamic renames during loading time > (vs. a grand global namespace like Java). Kudos for bringing this to > life. > > What still remains a mystery (for me) is why we need this extra > complication -- e.g., why can't I simply _import_ from other > Environments. Instead, I can only import from other Environments what > I've declared as their _exports_. > > This does not seem to be in the spirit of Smalltalk -- having to > "declare" the class-API's before I can use them. I have to keep these > two things "in-sync" with each other: An Environments exports with > the other environments imports. > > It reminds me somewhat of static-typing in that it's simply a "chore" > I have to do for the satisfaction of the computer but no real benefit > (that I can identify) for the developer... This is way off topic for the thread. You need to try out Haskell or OCaml, because it sounds like you've not used a language with a decent static type system. A static type system provides you with axioms, letting you prove certain properties of your system. Or: programming in the type system is proof writing. Static typing is an extraordinarily powerful tool. C++ and Java's type systems are a joke, so if that's all you've used, I can understand why you might not see much benefit to a static type system. frank > On Sat, Dec 21, 2013 at 6:53 PM, Colin Putney <[hidden email]> wrote: >> >> >> >> On Fri, Dec 20, 2013 at 3:04 PM, Chris Muller <[hidden email]> wrote: >> >>> >>> And, also, let me pose an additional question: Why do we need >>> 'exports' at all? The use-case we're solving is name-disambiguation, >>> period. Exports seems to be about making certain classes >>> "unimportable", e.g., "private". >>> >>> Why are exports needed at all? >> >> >> Name disambiguation is *one* of the use cases. Private classes is another >> one. I'd really like to be able to set up an Xtreams environment properly. >> See the discussion on Xtreams here: >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html >> >> >> > |
Re: Environment's #classNamed:
|
|
On Sun, Dec 22, 2013 at 1:09 PM, Frank Shearar <[hidden email]> wrote:
> On 22 December 2013 18:16, Chris Muller <[hidden email]> wrote: >> Yes, I had already gone back and read that several days ago when I >> made the decision to finally get into Environments. That thread is a >> gem for getting started understanding Environments. >> >> Colin, Environments is exactly how I think the namespace problem >> should be solved -- I see it as dynamic renames during loading time >> (vs. a grand global namespace like Java). Kudos for bringing this to >> life. >> >> What still remains a mystery (for me) is why we need this extra >> complication -- e.g., why can't I simply _import_ from other >> Environments. Instead, I can only import from other Environments what >> I've declared as their _exports_. >> >> This does not seem to be in the spirit of Smalltalk -- having to >> "declare" the class-API's before I can use them. I have to keep these >> two things "in-sync" with each other: An Environments exports with >> the other environments imports. >> >> It reminds me somewhat of static-typing in that it's simply a "chore" >> I have to do for the satisfaction of the computer but no real benefit >> (that I can identify) for the developer... > > This is way off topic for the thread. You need to try out Haskell or > OCaml, because it sounds like you've not used a language with a decent > static type system. A static type system provides you with axioms, > letting you prove certain properties of your system. Or: programming > in the type system is proof writing. Static typing is an > extraordinarily powerful tool. C++ and Java's type systems are a joke, > so if that's all you've used, I can understand why you might not see > much benefit to a static type system. Indeed, Java is the only statically typed system I've used in at least a decade. But the proof-writing property you mentioned about good static typing systems sounds very interesting and a great benefit. In the context of the Xtreams paragraph here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html ================ "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." ================== The last sentence enumerates how Xtreams would be made to co-exist with Squeak, and says its only declared class, Incomplete, should be exported. I was just trying to understand whether the export requirement/capability is actually enabling some use-case that wouldn't otherwise be enabled. Obviously, I don't fully grok Environments yet.. |
Re: Environment's #classNamed:
|
|
In reply to this post by Chris Muller-3
On Sun, Dec 22, 2013 at 1:16 PM, Chris Muller <[hidden email]> wrote: What still remains a mystery (for me) is why we need this extra Think of exports as a kind of encapsulation for environments. If you just want the simple case of "expose everything" you can do that very simply. But if you want to do something a little more explicit, as with Xtreams, you can do that too.
You are right that it's not strictly necessary to have exports, since you can define any policy you want at the import side. But exports allow us to remove duplication in setting policies. Imagine that I have several other environments that use Xtreams. There's two ways I could hook them up.
If I use imports to set the policy, I'd do something like this:
If I use exports to set the policy, it looks like this:
They have the same end result, but notice the duplication in the first version. If a new version of Xtreams comes out that includes another public exception, consider the changes I have to make. With imports, I'd do this:
With exports I only have to make the change in one place:
So the problem of "keeping things in-sync" is actually made easier with exports. For simple cases, sure, just #exportSelf and move on, but for more complex setups it's valuable.
Colin |
|
|
On 23-12-2013, at 8:34 AM, Colin Putney <[hidden email]> wrote: > Think of exports as a kind of encapsulation for environments. I thought that was the entire point of them! You add an environment to your system and get an API to allow you to use it and the rest is private. Obviously, being Smalltalk, you can ‘move into the environment’ and develop it further at any point, but from the point of view of an importer/user it should be opaque. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CWB: Carry With Borrow |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |