This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Dotted.Paths.To.Classes.Vs.Imports Feed Title: Travis Griggs - Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml Feed Description: This TAG Line is Extra Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Travis Griggs - Blog

Historically, if I build well subdivided BucketsOfBehavior, I might have package A which builds upon package B. It'll prereq it. I'll put code in A in an A namespace, and code in B in a B namespace. The tools handle the namespace import for you eventually quite nicely. If A really "builds on" B, you're pretty quickly going to reference something from A in something in B. You 'accept', it'll say "what is this", yout tell it to 'correct', it comes up with nothing, you say "search the system", it finds it, you select the one, tell it to import the container namespace into your container namespace and you're pretty much done. Didn't end up using any form of class importing (either importing the class only into namespace B, or namespace A into only the B class). That worked well, coulda been a little simpler.

Recently, I had another experience though. It was working to get the PNGImageReader goodie up to date with the new supported compression facilities of the VM in 7.2. This gets interesting. Originally, it was using a third party port of the Squea compression stuff, a package called Compression. This package, among other things, gives you a Net.Zlib.ZLibReadSteam. The problem with that package, is that it's, well, not supported, and I couldn't get it to load into an RTP image, something about share initialization order (see my thoughts on Lazy or Deferred Share Initializers which woulda made this issue a non).

To get the new VM behavior, we need a different package, Compression-Zlib. So we load that. It creates a OS.Zlib.InflateStream with GZipReadStream class. For PNG files though, we just want the basic inflate algorith, so we need to add a subclass, OS.ZLib.ZLibReadStream. This is really cool, that we can have two ZLibReadStreams in the system, and that they can coexist. But I can't get my new ZLibReadStream to work quite right yet. Comparing it to the other is no help, because it's an all in Smalltalk solution, no hints on how to correctly interoperate with the zlib dll.

John Brant of "refractory" fame to the rescue! JB has already done a parcel which is a DLLCC interface to zlib. I load it. Guess what it defines? Refactory.Zlib.ZLibReadStream. Now I've got THREE of the same named class in the system. That's cool. That's what these namespace things are for anyway. Going back and forth between the latter two, I was able to get the new one fixed and published to the list.

Somewhere in there though, I got tired of the whole "imports" thing. PNGImageReader is its own class, and it references one of the three ZLibReadStream objects. Testing to get the newest one right, was constantly going back and forth. At first, I played the import class or namespace into the class game. But it drove me nuts. I just wanted to change the code. And I wanted the code to tell me what it was doing, not "hide" it somewhere else (like in the class definition). I made numerous mistakes because I lost track of just which ZLibReadStream I was using. Finally, I gave up. I unimported everything. And I just spelled out the reference right there. And things got better. I do not want to edit a either. The fact is, I was trying to create a reference to a particular class, and want to go to one encapsulated place in the code to look at it. This was one case, where I was glad that I was not overly discouraged from using dotted.class.path.names.

Now if the _ thing were just implict. Maybe if we start the path with $. But, that's another subject.