Marcus Denker <marcus at ira.uka.de> wrote:
> Hi!
> > 
> > But Debian's DFSG did not let it through as "Debian free" - 
> > they are even pickier.
> Thats wrong. The Open Source Definition is pretty much *identical* to
> the Debian Free Software Guidelines. 

Ok, my fault. After checking on the net I agree that this is the case.
I thought that they where a bit different since I had gotten the
impression that OSI approves licenses a bit to easily sometimes and that
Debian seems quite serious on the other hand. But you are right.

My impression about SqueakL/Debian though (my memory may serve me wrong
here) was that the export clause (!) was no problem for Debian, it was
the indemnification stuff as Stephen Stafford explained:

http://macos.tuwien.ac.at:9009/438570542.asHtml

...which probably would be a problem for OSI too then I guess.

> Just read it:
> 
> http://www.debian.org/social_contract#guidelines
> http://opensource.org/docs/definition_plain.html
> 
> > I think it just did not happen.
> >
> It did not happen because everyone who thought about it *knew* what the
> outcome of such a question would be: "SqueakL is not Open Source according
> to the Open Source definition"
> 
> Maybe this is just what's needed to get people to *really* start thinking
> about changing SqueakL?

Yep. But it won't happen until someone coughs up money to have it done I
guess. :-)
But throwing SqueakL at OSI and see what they say could probably be
done. I think I even did that a few months ago but got no answer. Or
perhaps it was FSF - I don't remember - it was one of them at least.

regards, Göran

PS. <CSOTD>
Well, well... Can't come up with code right now. But I could explain a
nice little technique called
"double dispatch" perhaps not known to some newbies.

Personally I use when I want to be able to have multiple views on domain
objects
and still be able to rely on polymorphism on the domain object to create
the proper view.

Let's say you have a bunch of different fruit objects of classes Banana,
Lemon etc. Perhaps you also
create some form of UI classes called for example Views. A BananaView
for Bananas, LemonView for Lemons and so on.

Instead of doing this like a real OO newbie:

obj class == Banana ifTrue:[ BananaView on: obj ] 

...you would of course implement a method called say "getView" in the
Banana class like this:

Banana>>getView
	^BananaView on: self

...thus you implement getView for all fruit classes and you will get the
proper view. Ok, but what if you
suddenly have different views altogether, for example a bunch of
viewclasses for the web and another for
Morphic? Darn. Well, the obvious mistake would be too fall back into
non-OO practices like this:

Banana>>getWebView
Banana>>getMorphicView

...and let the caller decide which one to use. But that's ugly. Another
way would be to stuff a conditional into getView like this:

Banana>>getView
	(some test finding out which view to make - not so easy)
		ifTrue:[ ^WebBananaView on: self]
		ifFalse:[ ^MorphicBananaView on: self]

...not so pretty either and the test can be hard. Yuk. Conditionals are
a sure sign that perhaps we could use polymorphism instead - "let the
objects decide" so to speak. Ok. What if the domain object, when it gets
the message #getView could just bounce back and ask, "Well, I don't know
which particular view, but since I am a banana, it better be a
SomethingBananaView...". This can be implemented like:

getViewFor: theCaller
	"Bounce right back and call the proper method in the caller.
	Since I am a Banana, I will call the getBananaViewFor: method."

	^theCaller getBananaViewFor: self


...ok, now it is up to the called to implement #getBananaViewFor: so
that the correct type of View is created.
The first dispatch is on the domain object, the second is a
bounce-right-back-thingy on the caller, which typically is another
already existing View object. Thus - "double dispatch".

We could also view it as a way to find the correct method not only based
on the class of the receiver but also on the class of the caller.

Over-and-out.

</CSOTD> DS