On 1 mars 07, at 10:22, Andreas Raab wrote:

> stephane ducasse wrote:
>>> In short: What impresses me about the Java solution is not that  
>>> it's flawless - what impresses me is that it works, that people  
>>> actually use it to deploy code and this code actually works in  
>>> the way intended.
>> But do you think that VW, VA code does not work once deployed? I  
>> would like to understand why Jar are better than parcels for example.
>
> Here are some "simple" issues: How do Parcels deal with conflicting  
> modifications to base classes? Say, one that says "Object>>isCommon  
> ^true" and one that says "Object>>isCommon ^false"? (Java simply  
> doesn't allow modifications to base classes which, really, isn't  
> such a bad thing from the point of view of modularity)

yes but you cannot have extra behavior and subclass does not solve  
the problem. I can show a lot of problems where not having
class extension can be killing you.

> Another one: Which assurances do parcels give in terms of security?  
> As far as I know there is no bytecode verifier, parcel have full  
> access to the entire Smalltalk namespace (covered by ClassLoaders  
> in Java), there are no limitations in terms of what operations a  
> parcel can perform (nil become: true; Java had a good set of fixes  
> in this area to get it right and not to leak ambient authority) and  
> I don't think VW even knows what a sandbox is.
>
> A third one: Which namespace are parcels loaded into? Can two  
> different versions of parcels be loaded side-by-side? How (if at  
> all) do they affect each other? Etc.

I think so. In fact in VW3.0 there were a hidden namespace just to be  
able to have atomic unloading.

>> May be I should post to VW to see what are the problem with  
>> deployed code in VW.
>> A parcel in VW has dev and depl prerequisites and it seems to work  
>> too.
>
> Well, sure. Sorta. Kinda. :-) We can do the same in Squeak with  
> projects and change sets and it seems to work, too. Sorta. Kinda. :-)
>
> Cheers,
>   - Andreas
>
>
>