-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andreas,

Andreas Raab wrote:
> Matej Kosik wrote:
>> What about ConstantPoint? Constant point is such an object which behaves
>> exactly like a Point except for that it cannot be moved (once it is
>> created). Can we implement such a thing in Smalltalk? Yes, it is
>> "enough" to implement E interpreter in Squeak and then you are done. Can
>> we implement constant point directly in E? Yes, it is trivial (few lines
>> of code).
>>
>> Or am I wrong? Is it somehow possible to implement ConstantPoint in
>> Smalltalk?
> 
> Sure. It's not even hard and I can think of at least three methods
> depending on how far you want to go with the level of support. The
> easiest (and most illustrative, though not directly comparable) method
> is this:
> 
> makePoint: aPoint
>   "Create a constant point object"
>   | pointClass pointObj |
>   pointClass := aPoint newUniclass.
>   pointClass compile: 'x ^', aPoint x printString.
>   pointClass compile: 'y ^', aPoint y printString.
>   ^pointClass new

This is interesting. Thank you. Although I do not have `newUniclass'
method directly in my image, there is something similar. So if I do this:

	pointClass := Object newUniqueClassInstVars: ''
                             classInstVars: ''.
	pointClass compile: 'x ^ 100'.
	pointClass compile: 'y ^ 100'.
	point := pointClass new.

I can indeed see that

	point x

gives

	100

and
	point y

gives

	100

However, if I passed reference to the `point' object to you (to your
code), were I able to stop you (your code) from doing

	point class compile: 'x ^ whatever'

? If not, then this is not the solution to the original problem. It
would be necessary to ban the "compile:" class method. And since
Smalltalk has many crooked lanes, we could again miss some other
vulnerabilities.

Does `point' have a class? Yes. Its name is

	point class

In my case `Object1'. What would prevent anyone from doing this

	(Smalltalk at: #Object1) compile: 'x ^ 10'

this should again be banned. It must be enforced that something like
that is impossible. I am afraid that the number of possible
vulnerabilities is overwhelming. Although this is related to the
"libraries" rather than to the language, the question is, whether the
"libraries" can be "tamed" or whether the whole thing should be thrown
away and everything restarted with security in mind from the begining.
In E they've done it. I believe. The tendency to keep current languages
and "adding security" is caused by the fact that we love Smalltalk
(Python, Ruby, Java, Erlang, ...) and do not want to turn back to it. I
am not proposing everyone to swich to E, I am not part of the E project,
I am only amazed, the question is, if we are really concerned with
security, whether such switch (directly or indirectly) would not be
necessary. Adding convenience/nice gui/great gui tools to E could be
possible whereas adding security to Smalltalk/Java/Python/Ruby/Erlang
may turn out to be
- - either impossible
- - or we will end up with essentially some almost E-quivalent (and thus
contributing to world fragmentation)


> 
> The other two methods are:
> * Use literal sharing, e.g., the identical x, and y values. The
> difference to the above is that both x and y would be parsed again by
> the compiler and therefore may not be identical to the input
> * Use blocks as accessors which would also use lexical scoping rules and
> be the most truthful (but least readable and hardest to implement
> directly) solution.
> 
> The main thing that's missing in Squeak to support this more easily is
> some "literal object" syntax by which you could create an anonymous
> class in a method and instantiate that class directly. This would allow
> you to reuse the same class over and over again, but it would not be
> much different from the above.
> 
> Cheers,
>   - Andreas
> 

- --
Matej Kosik
icq: 300133844, skype: matej_kosik, sarkan at jabber.sk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFN0j4L+CaXfJI/hgRAj/zAKDV7MEw2TlJ37Um7qGCBgWLqVa9rACgrKqX
rtfk+eneeCJO4Y98J4baTe0=
=eDen
-----END PGP SIGNATURE-----