SystemDictionary>>imageImports -> XXX>>imageImports

Andreas Raab andreas.raab at gmx.de
Wed May 14 01:29:37 UTC 2003


Russel,

Having thought about this problem more often than I'd like to admit let me
point out a very common problem:

> The file names without extensions become the keys to my dictionary and
> each recognised filetype gets instanced as the appropriate class.

This sounds good in theory and screws up in practice. Consider this:
	'Holidays.mp3'
	'Holydays.gif'
	'Holidays.mov'
So which one do you get if you ask your imports?

> The main thing is that Imports not be limited to images but 
> to all media types including Mpeg, MP3, wav, images, fonts, etc.

In this case you need a much more elaborate resource management than just
some 'imports' thingy. Remember that you will want to find out which of
these are part of your current project, that you will want to find out which
of them you've already loaded (to avoid having the same 50MB movie loaded
three times), that you will want to know where this stuff came from etc.

There are a lot of things that you really want to know once you start
treating the imports more along the lines of a media library.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Russell Penney
> Sent: Wednesday, May 14, 2003 3:17 AM
> To: 'The general-purpose Squeak developers list'
> Subject: RE: SystemDictionary>>imageImports -> XXX>>imageImports
> 
> 
> I think that for people new to the system an Import class would be
> easier than the existing system. I remember spending WAY too much time
> trying to track down where the images lived.
> I, personally, would rather have a single class "Imports" which is a
> dictionary of dictionaries. So I can say:
> 
> image := ( Imports bundle: 'RussellsImports' ) at: 'MyImage'.
> movie := ( Imports bundle: 'RussellsImports' ) at: 'MyMovie'.
> font := ( Imports bundle: 'RussellsImports' ) at: 'MyFont' 
> ifAbsent: [ (
> Imports bundle: 'SystemDefaults' ) at: 'DefaultFont' ].
> 
> Where my particular bundle (or package or whatever it gets called) is
> loaded by:
> 
> Imports loadBundle: 'RussellsImports' from: 'c:\russells_media\*.*'
> 
> The file names without extensions become the keys to my dictionary and
> each recognised filetype gets instanced as the appropriate class.
> 
> The main thing is that Imports not be limited to images but 
> to all media
> types including Mpeg, MP3, wav, images, fonts, etc.
> 
> There would be system objects loaded in the base image and modules can
> load their own bundle so they are not/less dependent on the minimal
> image.
> 
> And for something like a headless system, just empty (most of) it to
> save space!
> 
> Russell
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
> Martin Wirblat
> Sent: Wednesday, 14 May 2003 3:11 AM
> To: Squeak
> Subject: Re: SystemDictionary>>imageImports -> XXX>>imageImports
> 
> Hi Julian,
> the specific method I had in mind is #imageImports. It is a method, 
> but it is about data, it looks up images. I can't think of the 
> existence of this method, without first thinking about this data. 
> 
> Classes and methods are nicely i.e. hierarchial ordered in 
> Squeak. But 
> if I want to see e.g. what icons are available, or what urls or texts 
> the system knows, what pictures and sound it has, it turns out, that 
> these non-code-objects are somewhat scattered around the system. They 
> may be hardcoded as literals, they may be accessible via 
> Smalltalk the 
> SysDic. If there are now new classes introduced to take away 
> this data 
> from Smalltalk ( as I understand Stephane ) I fear the access 
> to these 
> objects gets even more dissipated. 
> 
> But I think you are right regarding that if one has this in mind, it 
> should be possible to even structure these non-code-objects better 
> than they are today. If this is done with more than one new class, 
> these classes should belong together in some way, so that they make 
> something whole. 
> 
> Regards, Martin
> 
> Julian Fitzell <julian at beta4.com> wrote on 13.05.2003 16:44:50:
> >
> >Martin Wirblat wrote:
> >> Hi Stephane,
> >> 
> >> thank you for replying to me. I think I should have left out the 
> >> middle part of my post regarding references to Smalltalk, I just 
> >> thought that there has to be access to it, maybe it would 
> be better 
> >> to replace all hardwired refs to it with something like 'Smalltalk 
> >> default' in order to prepare Squeak for multiple environments, 
> >> maybe something else, I don't know. 
> >> 
> >> However, you don't convince me really on finding things in 
> >> additional classes. 
> >> 
> >> 
> >>>In Imports I have a better chance to find stuff related to 
> imported 
> >>>objects
> >>>than to namespace whose the only responsibility should be dealing 
> >>>with class names.
> >> 
> >> 
> >> At first you have to find Imports. Probably you need some more 
> >> dictionaries holding data, if you don't want to have this data in 
> >> Smalltalk. Isn't this more complicated than to have one single 
> >> place where to look for this? Wasn't Smalltalk meant to be the 
> >> single place for this? 
> >
> >Hrm... well... I mean by that logic, by extension, why have classes 
> >at all?  If we just put all the methods in one place then we'd know 
> >where to find them all.  But it isn't very logically divided.  This 
> >seems like unclean design, not to mention causing problems for 
> >eSqueak, etc. 
> > I don't think that what we have now is exactly the same problem, 
> > just to a 
> >lesser degree.
> >
> >I'd actually argue it makes it harder to find stuff because 
> while you 
> >know where to look it would take you hours to look through all the 
> >methods.  And if you're working with a certain set of functionality 
> >(ie a bunch of clases in the system) then presumably you will look 
> >for any methods having to do with that functionality there.
> >
> >You don't mention specific methods and I assume that there 
> is a small 
> >subset of methods that should be on SystemDictionary.  But most of 
> >the methods there, imo, belong on more appropriate classes.
> >
> >Julian
> 
> 
> 
> 
> 
> 



More information about the Squeak-dev mailing list