Re: Java's modules rock? (was Re: election details)
Locked
Re: Java's modules rock? (was Re: election details)
 
|
On 3/2/07, Todd Blanchard <[hidden email]> wrote:
> It seems there have been some attempts at this in Squeak - islands? > Squeak-E? I haven't followed them. Squeak-islands and Squeak-E haven't been worked on for ages. I have plans to make a secure fork of Squeak using salvagable code from both, but don't hold your breath :-). > But this is easy given that Java freezes everything at compile time. > No extensions to anything allowed post-compile (ok - post load). > Unfortunately, the bar is higher in Smalltalk as we want to allow > extension of anything. I assume you mean being able to add methods to any class in the image rather than just the classes in your own package? > I don't think it would be conceptually hard to do something similar > in Smalltalk if you were to have class lookup work similarly to > method lookup but along namespace hierarchies. I'm working on that. Now... if I make a stable, usable, clean and largely backwards-compatible solution, will people integrate it into Squeak? It would be a very large, dare I say revolutionary change. > The other thing that > would make extension safe is a copy on write semantic with class > wherein extensions to classes that are not local to your namespace > result in a new class with the same name in your namespace being > created that derives from the class in the parent namespace. Thus, > your mods are kept local to your context. It does make class binding > harder as class names have to be resolved dynamically in the methods > that reference them. That's harder. How do you plan to make sure that instances of the original class have their method lookup redefined automatically? Say for example that you redefine a method in Object - how would you make sure that a String literal in your code would have your redefined method in it's superclass hierarchy? Personally, I don't think it's ever necessary to redefine methods in "System" objects such as Object, Collection or String. Other programming languages manage fine without being able to do this. The most common reason people do this is to check if an instance is of a certain class (like Object>>isMorph or Object>>isMyStupidClass) - people should use isKindOf:. If that is too slow then isKindOf: should be made a primitive method. Methods like String>>isURL don't belong in the String class! That should be URL class>>isURL:. Object>>asMorph should be Morph class>>fromObject:, and so forth. Michael. |
Re: Java's modules rock? (was Re: election details)
|
|
Michael van der Gulik wrote:
> Squeak-islands and Squeak-E haven't been worked on for ages. I have > plans to make a secure fork of Squeak using salvagable code from both, > but don't hold your breath :-). I'd love to hear your plans for a secure Squeak. When you explain them, please also cc me directly, so that I don't miss them. Thanks. -- Text by me above is hereby placed in the public domain Cheers, --MarkM |
RE: Java's modules rock? (was Re: election details)
|
|
+1
Michael, I've been meaning to review your work, have you made any progress on it. Have you considered putting together a protection profile? Could we use your work as a starting point for FIPS? How far away from a working model are you? Revolutionary is good, as long as the target is realistic. I can't realistically offer to help for at least another 6 months, I'm swamped. But maybe we can have a more in depth conversation on the Cryptography Team List. Take care, Ron > -----Original Message----- > From: Mark S. Miller > Sent: Thursday, March 01, 2007 8:45 PM > > Michael van der Gulik wrote: > > Squeak-islands and Squeak-E haven't been worked on for ages. I have > > plans to make a secure fork of Squeak using salvagable code from both, > > but don't hold your breath :-). > > I'd love to hear your plans for a secure Squeak. When you explain them, > please > also cc me directly, so that I don't miss them. Thanks. > > > -- > Text by me above is hereby placed in the public domain > > Cheers, > --MarkM > |
RE: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Michael van der Gulik-2
> From: Michael van der Gulik > > Personally, I don't think it's ever necessary to redefine methods in > "System" objects such as Object, Collection or String. Other > programming languages manage fine without being able to do this. > > The most common reason people do this is to check if an instance is of > a certain class (like Object>>isMorph or Object>>isMyStupidClass) - > people should use isKindOf:. If that is too slow then isKindOf: should > be made a primitive method. > > Michael. > I just did this right before I read this email. I have a method Object>>xmlContentString It has a default implementation for every object in the system. I need it so that I can override the behavior of special objects. I could move this method to my xmlParser and write a case statement, or double dispatch with a default on #respondsTo: #ifFalse, but it seems so much cleaner to put the behavior on the objects themselves. I agree it's not a good idea to extend base objects arbitrarily but it does make the code much cleaner. It makes sense to be to put the behavior where it goes and let the polymorphism work its magic. We could still verify base class implementations by isolating user extensions or overrides to base classes. Having this level of control is really cool; I'd hate to lose it. Ron Teitelbaum |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Michael van der Gulik-2
Michael van der Gulik wrote:
>> But this is easy given that Java freezes everything at compile time. >> No extensions to anything allowed post-compile (ok - post load). >> Unfortunately, the bar is higher in Smalltalk as we want to allow >> extension of anything. > > I assume you mean being able to add methods to any class in the image > rather than just the classes in your own package? That has been the implicit assumption, yes, but personally I don't see that as a requirement. If the tradeoffs are between changing methods on class Object and having a workable and reasonably secure module system I would opt for the latter. > Now... if I make a stable, usable, clean and largely > backwards-compatible solution, will people integrate it into Squeak? I can't speak for Squeak, but for Croquet I would say, yes, we would. And I would also say that the focus should be on "stable, usable, clean" and much less on "largely backwards-compatible" ;-) > It would be a very large, dare I say revolutionary change. So is Croquet. You'd feel right at home. > The most common reason people do this is to check if an instance is of > a certain class (like Object>>isMorph or Object>>isMyStupidClass) - > people should use isKindOf:. If that is too slow then isKindOf: should > be made a primitive method. Right. And that's just what I (not quite coincidentally ;-) said in a recent discussion with Goran - having a very, very fast type test of some sort would solve quite a number of problems . Cheers, - Andreas |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Michael van der Gulik-2
>
>> The other thing that >> would make extension safe is a copy on write semantic with class >> wherein extensions to classes that are not local to your namespace >> result in a new class with the same name in your namespace being >> created that derives from the class in the parent namespace. Thus, >> your mods are kept local to your context. It does make class binding >> harder as class names have to be resolved dynamically in the methods >> that reference them. > > That's harder. > > How do you plan to make sure that instances of the original class have > their method lookup redefined automatically? Say for example that you > redefine a method in Object - how would you make sure that a String > literal in your code would have your redefined method in it's > superclass hierarchy? > > Personally, I don't think it's ever necessary to redefine methods in > "System" objects such as Object, Collection or String. Other > programming languages manage fine without being able to do this. Really? I thought you mean redefine and you could be right bt below you mean addition. Have you seen how Swing is build and the Math library of number in Java just because they cannot do class extension. I think that class extensions are really good to make smooth integration (cf. the acacongua excellent unit frameworks). > Methods like String>>isURL don't belong in the String class! That > should be URL class>>isURL:. Object>>asMorph should be Morph > class>>fromObject:, and so forth. Thanks but these are not about **redefinition** Apparently you confuse class extension addition and class extension redefinition. We could have one without the other. May be you should read, because it presents selector namespace which can be a sensible solution to the problem that andreas points. But Smalltalker have been facing that since already two decades. http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05cModuleDiversity.pdf |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Michael van der Gulik-2
I would be curious to read what you have done so far. Do you plan to
send something to ESUG research track. It would be cool. Now how your extension solution compares with selectorNamespace and classboxes. Because the lookup of classbox follow the import chain first then inheritance (this is may be too early to get my neurons working correclty) And classboxes are hidden namespaces with import too, if you did not notice. Stef On 2 mars 07, at 02:31, Michael van der Gulik wrote: > On 3/2/07, Todd Blanchard <[hidden email]> wrote: > >> It seems there have been some attempts at this in Squeak - islands? >> Squeak-E? I haven't followed them. > > Squeak-islands and Squeak-E haven't been worked on for ages. I have > plans to make a secure fork of Squeak using salvagable code from both, > but don't hold your breath :-). > >> But this is easy given that Java freezes everything at compile time. >> No extensions to anything allowed post-compile (ok - post load). >> Unfortunately, the bar is higher in Smalltalk as we want to allow >> extension of anything. > > I assume you mean being able to add methods to any class in the image > rather than just the classes in your own package? > >> I don't think it would be conceptually hard to do something similar >> in Smalltalk if you were to have class lookup work similarly to >> method lookup but along namespace hierarchies. > > I'm working on that. > > Now... if I make a stable, usable, clean and largely > backwards-compatible solution, will people integrate it into Squeak? > It would be a very large, dare I say revolutionary change. > >> The other thing that >> would make extension safe is a copy on write semantic with class >> wherein extensions to classes that are not local to your namespace >> result in a new class with the same name in your namespace being >> created that derives from the class in the parent namespace. Thus, >> your mods are kept local to your context. It does make class binding >> harder as class names have to be resolved dynamically in the methods >> that reference them. > > That's harder. > > How do you plan to make sure that instances of the original class have > their method lookup redefined automatically? Say for example that you > redefine a method in Object - how would you make sure that a String > literal in your code would have your redefined method in it's > superclass hierarchy? > > Personally, I don't think it's ever necessary to redefine methods in > "System" objects such as Object, Collection or String. Other > programming languages manage fine without being able to do this. > > The most common reason people do this is to check if an instance is of > a certain class (like Object>>isMorph or Object>>isMyStupidClass) - > people should use isKindOf:. If that is too slow then isKindOf: should > be made a primitive method. > > Methods like String>>isURL don't belong in the String class! That > should be URL class>>isURL:. Object>>asMorph should be Morph > class>>fromObject:, and so forth. > > Michael. > > |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by stephane ducasse
stephane ducasse wrote:
> > http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05cModuleDiversity.pdf > I'd be delighted if someone could summarize the main points of the paper in less than 30 pages. I started reading it but after the first eight pages or so I got too much reminded of this post about AOP (I know this may sound nasty but it's also very funny so I'll post it anyways and *please* take it with a bit of humor ;-) http://www.theserverside.com/news/thread.tss?thread_id=39026 "Let me frame my comment by defining a few terms first, a topiccut is a some section of a topic that I'm addressing. A critpoint is a criticism location attached to some sub point of a context. A lecture is the application of a criticism given a set of critpoints. critpoints may or may not be defined by other critpoints. The use of topiccuts, critpoints, lectures involve what is defined as a 'discussion'. A taxonomy of 'discussion' needs to be defined to determine the applicability of the effectiveness of the use of critpoints, topiccuts and lectures. It all makes sense if you really think about it. In a later post, I will introduce the required query by example syntax which does not resemble the context syntax. I define this as the ContextJ project (ContextN and ContextMono forthcoming)... Now that everything has been defined, I'm a little unsure how to define my critpoints and where they may apply. I'm tired, maybe I'll just put my criticism in context directly next time..." Cheers, - Andreas |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Andreas.Raab
Hi Andreas,
on Fri, 02 Mar 2007 07:53:38 +0100, you wrote: > Michael van der Gulik wrote: >> ... people do this is to check if an instance is of >> a certain class (like Object>>isMorph or Object>>isMyStupidClass) - >> people should use isKindOf:. If that is too slow then isKindOf: should >> be made a primitive method. > > Right. And that's just what I (not quite coincidentally ;-) said in a > recent discussion with Goran - having a very, very fast type test of > some sort would solve quite a number of problems . Attached. 1M yes/no queries per second on my 1.73 GHz notebook :) /Klaus > Cheers, > - Andreas |
PerProtocolDictionary.st (1K)
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Andreas.Raab
Andreas
ahahahaha what humor...... But this was so fun and constructiv. Thanks for it. If you do not want to know selector namespace semantics versus ruby mixin vs classboxes do not read it. Easy. you can just have a look at the text and the figure (no need to read the greek if you do not understand it). Of course you can say that the paper is useless, xxxx put the adjective that make you laugh the most. But this is the only paper that present selectorNamespace as far as we know, alex had to test SmallScript to make sure that this was the right behavior. And we found interesting to have a model to talk about binding, freezing binding, visibility,... So suggest you not to read the papers on Ocaml mixins because they are much more complex. Stef > stephane ducasse wrote: >> http://www.iam.unibe.ch/~scg/Archive/Papers/ >> Berg05cModuleDiversity.pdf > > I'd be delighted if someone could summarize the main points of the > paper in less than 30 pages. I started reading it but after the > first eight pages or so I got too much reminded of this post about > AOP (I know this may sound nasty but it's also very funny so I'll > post it anyways and *please* take it with a bit of humor ;-) > > http://www.theserverside.com/news/thread.tss?thread_id=39026 > > "Let me frame my comment by defining a few terms first, a topiccut > is a some section of a topic that I'm addressing. A critpoint is a > criticism location attached to some sub point of a context. A > lecture is the application of a criticism given a set of > critpoints. critpoints may or may not be defined by other > critpoints. The use of topiccuts, critpoints, lectures involve what > is defined as a 'discussion'. A taxonomy of 'discussion' needs to > be defined to determine the applicability of the effectiveness of > the use of critpoints, topiccuts and lectures. > > It all makes sense if you really think about it. > > In a later post, I will introduce the required query by example > syntax which does not resemble the context syntax. > > I define this as the ContextJ project (ContextN and ContextMono > forthcoming)... > > Now that everything has been defined, I'm a little unsure how to > define my critpoints and where they may apply. I'm tired, maybe > I'll just put my criticism in context directly next time..." > > Cheers, > - Andreas > > |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Michael van der Gulik-2
>> I don't think it would be conceptually hard to do something similar
>> in Smalltalk if you were to have class lookup work similarly to >> method lookup but along namespace hierarchies. No, this is not difficult to achieve. This is even called "virtual classes", or "virtual type". Want some example of existing systems? CaesarJ [1], Keris [2], gbeta [3], [1] http://caesarj.org/ [2] Author's web page: http://zenger.org/research.html [3] http://www.daimi.au.dk/~eernst/gbeta/ and particularly http:// www.daimi.au.dk/~eernst/papers/fampol.ps [4] Thesis of William Cook, http://www.cs.utexas.edu/~wcook/papers/ thesis/cook89.pdf , most interesting for our purpose is Section 3.5 page 27. > I'm working on that. > > Now... if I make a stable, usable, clean and largely > backwards-compatible solution, will people integrate it into Squeak? > It would be a very large, dare I say revolutionary change. Should be trivial to implement in Squeak. Some issue arise when implementing this in a static type language (http://www.daimi.au.dk/ ~eernst/papers/tr-pb577.pdf), however this is not an issue for squeak. Where you might have some problems is to achieve a complete integration with the tools... >> The other thing that >> would make extension safe is a copy on write semantic with class >> wherein extensions to classes that are not local to your namespace >> result in a new class with the same name in your namespace being >> created that derives from the class in the parent namespace. Thus, >> your mods are kept local to your context. It does make class binding >> harder as class names have to be resolved dynamically in the methods >> that reference them. > > That's harder. This is a hard problem. I spend 4 years on it (http:// www.iam.unibe.ch/~scg/Archive/Papers/Berg05aclassboxesJournal.pdf , feel free to skip the greek stuff if you're not comfortable with). I am interested in having virtual classes in Squeak. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.cs.tcd.ie/Alexandre.Bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Java's modules rock? (was Re: election details)
|
|
Hi Alex,
I read the CaesarJ tutorial until it said if(comp instanceof Container) {returnContainerNode((Container)comp);} else{returnComponentNode(comp);} which is about "wrappers are selected depending on the dynamic type of the wrappee". In this simple example there are just containers and components. I fear that in more complex situations the actual number of "if (x instanceof Y)" becomes unmanageable :( /Klaus On Sat, 03 Mar 2007 17:36:03 +0100, Alexandre Bergel wrote: >>> I don't think it would be conceptually hard to do something similar >>> in Smalltalk if you were to have class lookup work similarly to >>> method lookup but along namespace hierarchies. > > No, this is not difficult to achieve. This is even called "virtual > classes", or "virtual type". > Want some example of existing systems? CaesarJ [1], Keris [2], gbeta [3], > > [1] http://caesarj.org/ > [2] Author's web page: http://zenger.org/research.html > [3] http://www.daimi.au.dk/~eernst/gbeta/ and particularly http:// > www.daimi.au.dk/~eernst/papers/fampol.ps > [4] Thesis of William Cook, http://www.cs.utexas.edu/~wcook/papers/ > thesis/cook89.pdf , most interesting for our purpose is Section 3.5 page > 27. > >> I'm working on that. >> >> Now... if I make a stable, usable, clean and largely >> backwards-compatible solution, will people integrate it into Squeak? >> It would be a very large, dare I say revolutionary change. > > Should be trivial to implement in Squeak. Some issue arise when > implementing this in a static type language (http://www.daimi.au.dk/ > ~eernst/papers/tr-pb577.pdf), however this is not an issue for squeak. > > Where you might have some problems is to achieve a complete integration > with the tools... > > > >>> The other thing that >>> would make extension safe is a copy on write semantic with class >>> wherein extensions to classes that are not local to your namespace >>> result in a new class with the same name in your namespace being >>> created that derives from the class in the parent namespace. Thus, >>> your mods are kept local to your context. It does make class binding >>> harder as class names have to be resolved dynamically in the methods >>> that reference them. >> >> That's harder. > > This is a hard problem. I spend 4 years on it (http:// > www.iam.unibe.ch/~scg/Archive/Papers/Berg05aclassboxesJournal.pdf , feel > free to skip the greek stuff if you're not comfortable with). > > I am interested in having virtual classes in Squeak. > > Cheers, > Alexandre |
Re: Java's modules rock? (was Re: election details)
|
|
Yes, exactly. The complexity explodes.
Moreover an if construct should be replaced with a polymorphic construct, even here: return comp returnWrapperNode and then the method returnWrapperNode has to be implemented on ContainerNode and ComponentNode. Ah, but wait, this Java language they are using does not support class extensions, so you have to go for the non-OO solution or know all your classes and wrappers up-front and add the necessary 'returnWrapperNode' methods :-( :-( It shows how choices in your packaging/deployment format in the end turn out to drive the design of your programs. Even though you can shoot yourself in the foot with the Smalltalk deployment approach (that allows method and class additions and redefintions ), *it does not drive my design*. This, to me, is a very clear advantage. On 03 Mar 2007, at 3 March/18:08, Klaus D. Witzel wrote: > Hi Alex, > > I read the CaesarJ tutorial until it said > > if(comp instanceof Container) > {returnContainerNode((Container)comp);} > else{returnComponentNode(comp);} > > which is about "wrappers are selected depending on the dynamic type > of the wrappee". > > In this simple example there are just containers and components. I > fear that in more complex situations the actual number of "if (x > instanceof Y)" becomes unmanageable :( > > /Klaus > > > On Sat, 03 Mar 2007 17:36:03 +0100, Alexandre Bergel wrote: > >>>> I don't think it would be conceptually hard to do something similar >>>> in Smalltalk if you were to have class lookup work similarly to >>>> method lookup but along namespace hierarchies. >> >> No, this is not difficult to achieve. This is even called "virtual >> classes", or "virtual type". >> Want some example of existing systems? CaesarJ [1], Keris [2], >> gbeta [3], >> >> [1] http://caesarj.org/ >> [2] Author's web page: http://zenger.org/research.html >> [3] http://www.daimi.au.dk/~eernst/gbeta/ and particularly http:// >> www.daimi.au.dk/~eernst/papers/fampol.ps >> [4] Thesis of William Cook, http://www.cs.utexas.edu/~wcook/papers/ >> thesis/cook89.pdf , most interesting for our purpose is Section >> 3.5 page 27. >> >>> I'm working on that. >>> >>> Now... if I make a stable, usable, clean and largely >>> backwards-compatible solution, will people integrate it into Squeak? >>> It would be a very large, dare I say revolutionary change. >> >> Should be trivial to implement in Squeak. Some issue arise when >> implementing this in a static type language (http:// >> www.daimi.au.dk/~eernst/papers/tr-pb577.pdf), however this is not >> an issue for squeak. >> >> Where you might have some problems is to achieve a complete >> integration with the tools... >> >> >> >>>> The other thing that >>>> would make extension safe is a copy on write semantic with class >>>> wherein extensions to classes that are not local to your namespace >>>> result in a new class with the same name in your namespace being >>>> created that derives from the class in the parent namespace. Thus, >>>> your mods are kept local to your context. It does make class >>>> binding >>>> harder as class names have to be resolved dynamically in the >>>> methods >>>> that reference them. >>> >>> That's harder. >> >> This is a hard problem. I spend 4 years on it (http:// >> www.iam.unibe.ch/~scg/Archive/Papers/ >> Berg05aclassboxesJournal.pdf , feel free to skip the greek stuff >> if you're not comfortable with). >> >> I am interested in having virtual classes in Squeak. >> >> Cheers, >> Alexandre > > > |
|
|
In reply to this post by stephane ducasse
>>Personally, I don't think it's ever necessary to redefine methods in
>>"System" objects such as Object, Collection or String. Other >>programming languages manage fine without being able to do this. Well lots of other languages make it "just fine" without being "classes all the way down" as well. I think both of these things are part of what makes Smalltalk different and much more powerful then nearly all other languages (only lisp can really compete imo). _________________________________________________________________ Don’t miss your chance to WIN 10 hours of private jet travel from Microsoft® Office Live http://clk.atdmt.com/MRT/go/mcrssaub0540002499mrt/direct/01/ |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Klaus D. Witzel
> I read the CaesarJ tutorial until it said
> > if(comp instanceof Container) > {returnContainerNode((Container)comp);} > else{returnComponentNode(comp);} > > which is about "wrappers are selected depending on the dynamic type > of the wrappee". > > In this simple example there are just containers and components. I > fear that in more complex situations the actual number of "if (x > instanceof Y)" becomes unmanageable :( It seems to me that this piece of code is automatically generated. Slide 44 shows how it works underneath i guess. As a simple user, you just have to declare inner classes. Cheers, Alexandre > > On Sat, 03 Mar 2007 17:36:03 +0100, Alexandre Bergel wrote: > >>>> I don't think it would be conceptually hard to do something similar >>>> in Smalltalk if you were to have class lookup work similarly to >>>> method lookup but along namespace hierarchies. >> >> No, this is not difficult to achieve. This is even called "virtual >> classes", or "virtual type". >> Want some example of existing systems? CaesarJ [1], Keris [2], >> gbeta [3], >> >> [1] http://caesarj.org/ >> [2] Author's web page: http://zenger.org/research.html >> [3] http://www.daimi.au.dk/~eernst/gbeta/ and particularly http:// >> www.daimi.au.dk/~eernst/papers/fampol.ps >> [4] Thesis of William Cook, http://www.cs.utexas.edu/~wcook/papers/ >> thesis/cook89.pdf , most interesting for our purpose is Section >> 3.5 page 27. >> >>> I'm working on that. >>> >>> Now... if I make a stable, usable, clean and largely >>> backwards-compatible solution, will people integrate it into Squeak? >>> It would be a very large, dare I say revolutionary change. >> >> Should be trivial to implement in Squeak. Some issue arise when >> implementing this in a static type language (http:// >> www.daimi.au.dk/~eernst/papers/tr-pb577.pdf), however this is not >> an issue for squeak. >> >> Where you might have some problems is to achieve a complete >> integration with the tools... >> >> >> >>>> The other thing that >>>> would make extension safe is a copy on write semantic with class >>>> wherein extensions to classes that are not local to your namespace >>>> result in a new class with the same name in your namespace being >>>> created that derives from the class in the parent namespace. Thus, >>>> your mods are kept local to your context. It does make class >>>> binding >>>> harder as class names have to be resolved dynamically in the >>>> methods >>>> that reference them. >>> >>> That's harder. >> >> This is a hard problem. I spend 4 years on it (http:// >> www.iam.unibe.ch/~scg/Archive/Papers/ >> Berg05aclassboxesJournal.pdf , feel free to skip the greek stuff >> if you're not comfortable with). >> >> I am interested in having virtual classes in Squeak. >> >> Cheers, >> Alexandre > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.cs.tcd.ie/Alexandre.Bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Ron Teitelbaum
Hi all.
Sorry for the lack of replies... I've been... umm... distracted by Wesnoth (http://www.wesnoth.org) :-). On 3/2/07,
Ron Teitelbaum <[hidden email]> wrote: +1 What's a protection profile? I wouldn't use my work as a starting point for the FIPS stuff until it works at least as well as the 3.9 image. Progress so far has been slow. Basic classes like Namespace have been tentatively made; I'm now modifying the Browser to be able to look at them. After that, I've got several other tasks: - Find a way of storing source code so that Namespaces are preserved. I might let the squeak.changes file format bit-rot (eventually deprecating it completely) and instead modify Monticello to preserve Namespace structure. - Make sure other tools in PlusTools work with Namespaces. - Then I start the massive task of converting core Squeak classes to use Namespaces: Kernel, Collections and Networking. - Then I take a very serious look at Islands and Squeak-E, salvaging what I can for a secure Squeak. I can't realistically offer to help for at least another 6 months, I'm Sure. Michael. |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Mark S. Miller
On 3/2/07, Mark S. Miller <[hidden email]> wrote: Michael van der Gulik wrote: Have a look at the wiki pages on http://www.squeaksource.com/SecureSqueak.html. Some of your work is quoted there :-). Cheers, Michael. |
Re: Java's modules rock? (was Re: election details)
|
|
In reply to this post by Bergel, Alexandre
He he, nice, built-in slowness :-)
On 07 Mar 2007, at 7 March/00:30, Bergel, Alexandre wrote: >> I read the CaesarJ tutorial until it said >> >> if(comp instanceof Container) >> {returnContainerNode((Container)comp);} >> else{returnComponentNode(comp);} >> >> which is about "wrappers are selected depending on the dynamic >> type of the wrappee". >> >> In this simple example there are just containers and components. I >> fear that in more complex situations the actual number of "if (x >> instanceof Y)" becomes unmanageable :( > > It seems to me that this piece of code is automatically generated. > Slide 44 shows how it works underneath i guess. > As a simple user, you just have to declare inner classes. > > Cheers, > Alexandre > > >> >> On Sat, 03 Mar 2007 17:36:03 +0100, Alexandre Bergel wrote: >> >>>>> I don't think it would be conceptually hard to do something >>>>> similar >>>>> in Smalltalk if you were to have class lookup work similarly to >>>>> method lookup but along namespace hierarchies. >>> >>> No, this is not difficult to achieve. This is even called >>> "virtual classes", or "virtual type". >>> Want some example of existing systems? CaesarJ [1], Keris [2], >>> gbeta [3], >>> >>> [1] http://caesarj.org/ >>> [2] Author's web page: http://zenger.org/research.html >>> [3] http://www.daimi.au.dk/~eernst/gbeta/ and particularly http:// >>> www.daimi.au.dk/~eernst/papers/fampol.ps >>> [4] Thesis of William Cook, http://www.cs.utexas.edu/~wcook/ >>> papers/thesis/cook89.pdf , most interesting for our purpose is >>> Section 3.5 page 27. >>> >>>> I'm working on that. >>>> >>>> Now... if I make a stable, usable, clean and largely >>>> backwards-compatible solution, will people integrate it into >>>> Squeak? >>>> It would be a very large, dare I say revolutionary change. >>> >>> Should be trivial to implement in Squeak. Some issue arise when >>> implementing this in a static type language (http:// >>> www.daimi.au.dk/~eernst/papers/tr-pb577.pdf), however this is not >>> an issue for squeak. >>> >>> Where you might have some problems is to achieve a complete >>> integration with the tools... >>> >>> >>> >>>>> The other thing that >>>>> would make extension safe is a copy on write semantic with class >>>>> wherein extensions to classes that are not local to your namespace >>>>> result in a new class with the same name in your namespace being >>>>> created that derives from the class in the parent namespace. >>>>> Thus, >>>>> your mods are kept local to your context. It does make class >>>>> binding >>>>> harder as class names have to be resolved dynamically in the >>>>> methods >>>>> that reference them. >>>> >>>> That's harder. >>> >>> This is a hard problem. I spend 4 years on it (http:// >>> www.iam.unibe.ch/~scg/Archive/Papers/ >>> Berg05aclassboxesJournal.pdf , feel free to skip the greek stuff >>> if you're not comfortable with). >>> >>> I am interested in having virtual classes in Squeak. >>> >>> Cheers, >>> Alexandre >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.cs.tcd.ie/Alexandre.Bergel > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |