|
Replies:
14
-
Last Post:
May 25, 2005 12:44 AM
by: alexlamsl
|
|
|
|
|
|
|
How about support the smalltalk's become feature?
Posted:
May 19, 2005 8:05 PM
|
|
|
I think the smalltalk VM has a interesting feature of the "become" operation.
eg. String obj1 = new String("Hello");
String obj2 = new String("Demo");
obj2.become(obj1)
now, the obj1 will reference to "Demo" also.
Also, the become operation provide a most dynamic feature for the VM platform. smalltalk takes more dynamic for support this feature.
The reason i think it is neccessary for JVM to support this feature:
1. make JVM a more low-level platform for other script language. or specically for support the smalltalk language
2. support hot-replace a object with another object, support more interesting AOP or dynamic features.
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 20, 2005 10:00 AM
in response to: wangzaixiang
|
|
|
so what's wrong with obj1 = obj2 ???
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 21, 2005 1:26 PM
in response to: alexlamsl
|
|
|
Smalltalk 'become' changes the object not the reference. Somewhat unsurprisingly it's a slow operation with direct references and optimisation is a tad more difficult in it's presence.
Solution: add your own layer of indirection.
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 21, 2005 2:57 PM
in response to: tackline
|
|
|
If I read you right, you mean obj2 becomes the clone of obj1 (having all the states equal, but are distant objects)?
Well I think to translate it in Java terms that would probably mean clone() of Object being public - which I'm not sure if that is useful at all ^^"
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 22, 2005 6:43 PM
in response to: alexlamsl
|
|
|
not what you expected but more.
if obj2 becomes to obj1, then all reference which reference to obj2 now will reference to obj1, not the clone of obj1, but the obj1 directly.
this makes the obj1 reprents to obj2 for the all heap.
It looks the "become" operation is the most dynamic magic of smalltalk but java missed.
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 22, 2005 6:59 PM
in response to: wangzaixiang
|
|
|
ok I get what you are saying (finally) ^^"
And I have to say that such feature would introduce certain element of danger into the Java Language though.
The idea is that private references to objects would get altered "unwillingly", if not maliciously, if this feature is available.
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 23, 2005 4:49 AM
in response to: alexlamsl
|
|
|
A good mechanism of course can be bad things if you do it.
Now, using the standard JDK, i can change your private field also. so this is not an issue when we conside a security limit for using the function.
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 23, 2005 5:16 AM
in response to: wangzaixiang
|
|
|
Oh? An example would be grateful =)
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 23, 2005 5:27 AM
in response to: alexlamsl
|
|
|
It is simple by learning the Java's reflect API:
1. query the Class for its fields. and we get a java.lang.reflect.Field instance
2. if the Field is private, we can modify its access flag first.
3. then call the Field.get/set method to read/write it.
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 23, 2005 5:34 AM
in response to: wangzaixiang
|
|
|
Firstly, Thanks =)
Secondly, the access keywords nonetheless serve as a compile-time (& run-time) checking feature - if you accidentally tried to access an inaccessible method or field you'll be shouted at.
This safety feature would be broken by the introduction of "become", don't you agree?
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 23, 2005 5:37 AM
in response to: jarouch
|
|
|
oh - we'll be risking a SecurityException there.
A more convincing example (if it'll work, that is - I don't think so personally) is to try it on restricted environments, e.g. applets.
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 24, 2005 12:55 PM
in response to: alexlamsl
|
|
|
Better still, an example of why exactly is this feature so useful that we can't do without it.
Any useful feature can be misused. Going by just the potential usefulness argument, there was no reason to remove pointer, operator overloading etc. from Java.
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 24, 2005 9:38 PM
in response to: wangzaixiang
|
|
|
Hi, I was using Java during 6 years. The last year I have started to work with Smalltalk (St). And each time that I see a post like this... I think: I want X St feature in Java, I want Y St feature... at in the end I think that is better to directly use St instead of fighting with Java 
I know, I know this is a Java forum and I don't want to start a flame war.
I don't know how Java manages memory, but in St you could do something like this: String allInstances (in a pseudo-Java syntax: String.class.allInstances()).
This gives you all instances of the class String that are "live" in the image (the memory). I think that this kind of reflexive facility is very difficult to implement in Java, because not exists the concept of "environment" like in St.
Become is barely used in St, because:
- Is very slow, each time that you do a become the VM has to:
- Force a garbage collect (not a scavenge, but a full GC)
- And change all references from A to B
In St this problem is usually solved using proxies. (note that with modern St VMs creating generic proxies using the #doesNotUnderstand: is really fast in most cases). And because St is not static-typed, this is much more easy.
Anyway, the feature that I miss most from St each time that I use Java is...closures:
For example instead of write:
Object value = myMap.get(key);
if (value == null) {
throw new NotFoundException();
}
you could write:
myMap at: key ifNone: [ NotFoundException raise ]
Instead of:
Thread t = new Thread(new Runable() {
public void run() {
code ...
}};
you could write:
t := [ code ... ] newProcess.
Instead of:
Iterator iter = coll.iterator();
List result = new ArrayList();
while (iter.hasNext()) {
String each = (String) iter.next();
if (each.equals(myName)) {
result.add(each);
}
}
you could write:
result := coll select: [:each | each = myName ]
Get the picture? (try two do the last example using Apache's Common Collections framework, and tell me the difference).
Each time that you write a block of code (something like using { } in Java). You get an object (Block) that can be evaluated latter, and has the same execution context that the parent (is a closure).
In a pseudo-Java syntaxt is something like:
Block b = (int a){ a + 2 };
int c = b.value(3); // you get 5
(I think that Groovy has something like this)
The other feature that I miss from St... is the absence of static-type checking, and final classes :P
|
|
|
|
|
|
|
|
|
Re: How about support the smalltalk's become feature?
Posted:
May 25, 2005 12:44 AM
in response to: diegof79
|
|
|
Looks like Smalltalk has quite a few of these "powerful" features, yet it will cause Java too much in terms of ease of development and security if these were implemented in Java.
Valid point there - each language has its own strength and weaknesses so the best for us is to learn them all and use them flexibly =)
|
|
|
|
|
java.net RSS
