Musings about modularity and programming in the large
Locked
123
123
Musings about modularity and programming in the large
 
|
Hi all,
Recently working in other high level languages I was thinking about how modularity is accomplished in these systems and how we might do it in Squeak. Now we could of course simply add something trivial that formalizes the prefixes we are using now and hide them for us (sometimes), but this doesn't really help our position much or make us much better at "programming in the large". Looking at other systems, Haskell, Ocaml and Lisp, it is interesting how they tackle this problem. What these systems all have in common is a pretty simple idea: a module declaration defines what is "exported" or visible from outside the module (or at least can be made so) and everything else is only visible to code inside the module. So combining this simple concept with Smalltalk's unique "objects all the way down" philosophy it occurred to me that a module could appear as simply a class like any other. The typical "import" mechanisms could be ignored, and export is handled as it is now. That is, today all classes and objects "export" methods; they simply respond to the ones they implement and DNU the ones they don't. Today, in Squeak all classes are inserted into a global namespace and are therefor visible from anywhere. With this module system I'm talking about, it would still work this way, but when one creates a new module, only the "module class" would be inserted. Any classes inside the module would not be inserted into the global namespace and would therefor not be visible globally. The "module class" could chose to behave completely as a normal class, i.e. the messages it exports/answers do their work by using the module's internal classes and objects, as well as global classes and other modules. An example of this might be a Seaside application which simply/responds to #renderOn: but internally has a complex series of class/objects determine the behavior. From the point of view of Seaside there is just one class that receives the render request. This is actually what we have right now, but the difference is that today every class even remotely involved in the application is visible everywhere, despite being essentially "private" to the application. The "module class" could also chose to behave as a "namespace", simply restricting access to its internal classes. But the most common behavior would likely be a hybrid between these two possibilities. That is, often you would send a message to this visible "module class" and it would behave as though it were a normal class. Other times you might send a message and the return value would be an instance of one of the modules internal classes (think, a regular instance creation method like Point>>x:y: that just happens to return an initialized instance from a class inside the module). Now, the question of course comes up of how such a system would look, be implemented, etc., etc. and I haven't really thought about that part yet. I'm sure I'm not the first person to think of such a system, so my question is: what systems do you all know about that sound like what I have described? Thanks, Jason |
Re: Musings about modularity and programming in the large
|
|
So no one knows of a system like this? There's nothing new in our
field since decades so I'm sure there are papers or an implementation out there, I just haven't found it yet. On Jan 20, 2008 5:30 PM, Jason Johnson <[hidden email]> wrote: > Hi all, > > Recently working in other high level languages I was thinking about > how modularity is accomplished in these systems and how we might do it > in Squeak. > > Now we could of course simply add something trivial that formalizes > the prefixes we are using now and hide them for us (sometimes), but > this doesn't really help our position much or make us much better at > "programming in the large". > > Looking at other systems, Haskell, Ocaml and Lisp, it is interesting > how they tackle this problem. What these systems all have in common > is a pretty simple idea: a module declaration defines what is > "exported" or visible from outside the module (or at least can be made > so) and everything else is only visible to code inside the module. > > So combining this simple concept with Smalltalk's unique "objects all > the way down" philosophy it occurred to me that a module could appear > as simply a class like any other. The typical "import" mechanisms > could be ignored, and export is handled as it is now. That is, today > all classes and objects "export" methods; they simply respond to the > ones they implement and DNU the ones they don't. Today, in Squeak all > classes are inserted into a global namespace and are therefor visible > from anywhere. With this module system I'm talking about, it would > still work this way, but when one creates a new module, only the > "module class" would be inserted. Any classes inside the module would > not be inserted into the global namespace and would therefor not be > visible globally. > > The "module class" could chose to behave completely as a normal class, > i.e. the messages it exports/answers do their work by using the > module's internal classes and objects, as well as global classes and > other modules. An example of this might be a Seaside application > which simply/responds to #renderOn: but internally has a complex > series of class/objects determine the behavior. From the point of > view of Seaside there is just one class that receives the render > request. This is actually what we have right now, but the difference > is that today every class even remotely involved in the application is > visible everywhere, despite being essentially "private" to the > application. > > The "module class" could also chose to behave as a "namespace", simply > restricting access to its internal classes. But the most common > behavior would likely be a hybrid between these two possibilities. > That is, often you would send a message to this visible "module class" > and it would behave as though it were a normal class. Other times you > might send a message and the return value would be an instance of one > of the modules internal classes (think, a regular instance creation > method like Point>>x:y: that just happens to return an initialized > instance from a class inside the module). > > Now, the question of course comes up of how such a system would look, > be implemented, etc., etc. and I haven't really thought about that > part yet. I'm sure I'm not the first person to think of such a > system, so my question is: what systems do you all know about that > sound like what I have described? > > Thanks, > Jason > |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Jason Johnson-5
I think that this is interesting to look at other lnagages. Now
unifying class and modules was never something I was found of. I'm not sure that we gain something besides confusion. A module could be "somehow a bit " polymorphic enough to be put in a system dictionary if you need but a class = factory of objects, a modules = scoped group of classes is a nice distinction. On Jan 20, 2008, at 5:30 PM, Jason Johnson wrote: > Hi all, > > Recently working in other high level languages I was thinking about > how modularity is accomplished in these systems and how we might do it > in Squeak. > > Now we could of course simply add something trivial that formalizes > the prefixes we are using now and hide them for us (sometimes), but > this doesn't really help our position much or make us much better at > "programming in the large". > > Looking at other systems, Haskell, Ocaml and Lisp, it is interesting > how they tackle this problem. What these systems all have in common > is a pretty simple idea: a module declaration defines what is > "exported" or visible from outside the module (or at least can be made > so) and everything else is only visible to code inside the module. > > So combining this simple concept with Smalltalk's unique "objects all > the way down" philosophy it occurred to me that a module could appear > as simply a class like any other. The typical "import" mechanisms > could be ignored, and export is handled as it is now. That is, today > all classes and objects "export" methods; they simply respond to the > ones they implement and DNU the ones they don't. Today, in Squeak all > classes are inserted into a global namespace and are therefor visible > from anywhere. With this module system I'm talking about, it would > still work this way, but when one creates a new module, only the > "module class" would be inserted. Any classes inside the module would > not be inserted into the global namespace and would therefor not be > visible globally. > > The "module class" could chose to behave completely as a normal class, > i.e. the messages it exports/answers do their work by using the > module's internal classes and objects, as well as global classes and > other modules. An example of this might be a Seaside application > which simply/responds to #renderOn: but internally has a complex > series of class/objects determine the behavior. From the point of > view of Seaside there is just one class that receives the render > request. This is actually what we have right now, but the difference > is that today every class even remotely involved in the application is > visible everywhere, despite being essentially "private" to the > application. > > The "module class" could also chose to behave as a "namespace", simply > restricting access to its internal classes. But the most common > behavior would likely be a hybrid between these two possibilities. > That is, often you would send a message to this visible "module class" > and it would behave as though it were a normal class. Other times you > might send a message and the return value would be an instance of one > of the modules internal classes (think, a regular instance creation > method like Point>>x:y: that just happens to return an initialized > instance from a class inside the module). > > Now, the question of course comes up of how such a system would look, > be implemented, etc., etc. and I haven't really thought about that > part yet. I'm sure I'm not the first person to think of such a > system, so my question is: what systems do you all know about that > sound like what I have described? > > Thanks, > Jason > > |
Re: Musings about modularity and programming in the large
|
|
On Jan 22, 2008 8:24 PM, stephane ducasse <[hidden email]> wrote:
> I think that this is interesting to look at other lnagages. Now > unifying class and modules > was never something I was found of. I'm not sure that we gain > something besides confusion. > A module could be "somehow a bit " polymorphic enough to be put in a > system dictionary > if you need but a class = factory of objects, a modules = scoped group > of classes is a nice > distinction. Well, what I'm thinking about maintains the "factory of objects", just expands on it a little. That is, a "module class" (a class that has kind of "private" classes inside itself) is also potentially a factory of objects. Different class methods may return different objects, but that is the the case with the system we have now. There is nothing that says a class method must return an instance of it's own class. The problem with "modules = scoped group of classes" is that it introduces some new syntax to deal with this distinction. It would be nice if things could remain "objects all the way down". As far as confusion, that is a valid concern, but in modern times all development is done in an IDE. That is, the tools expand our capabilities and I would rely on the tools for this situation as well. The tools would have to operate such that there was no confusion. |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Jason Johnson-5
Hi Jason,
On Jan 22, 2008 6:36 PM, Jason Johnson <[hidden email]> wrote: > So no one knows of a system like this? There's nothing new in our > field since decades so I'm sure there are papers or an implementation > out there, I just haven't found it yet. reading your posting, I had the impression there might be some relations to Gilad Bracha's work on Newspeak... http://gbracha.blogspot.com/ He's got several entries in his blog that describe how Newspeak deals with modularity, classes, dependencies, ... maybe you could give that a try? Best, Michael |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Jason Johnson-5
Jason Johnson wrote:
> Hi all, > > Recently working in other high level languages I was thinking about > how modularity is accomplished in these systems and how we might do it > in Squeak. This is a recurring discussion and I often see suggestions like yours: postulate a mechanism and discuss its viability. I would call this the bottom-up approach. If we went top-down we could start with specifying what we want to get from a module system. I recently came across a paper on J& ('Jet') which starts out with a list of requirements we might want to ponder in this regard: http://lambda-the-ultimate.org/node/2591 " J&: Nested Intersection for Scalable Software Composition by Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006. We identify the following requirements for general extension and composition of software systems: 1. Orthogonal extension: Extensions may require both new data types and new operations. 2. Type safety: Extensions cannot create run-time type errors. 3. Modularity: The base system can be extended without modifying or recompiling its code. 4. Scalability: Extensions should be scalable. The amount of code needed should be proportional to the functionality added. 5. Non-destructive extension: The base system should still be available for use within the extended system. 6. Composability of extensions. The first three of these requirements correspond to Wadler’s expression problem. Scalability (4) is often but not necessarily satisfied by supporting separate compilation; it is important for extending large software. Non-destructive extension (5) enables existing clients of the base system and also the extended system itself to interoperate with code and data of the base system, an important requirement for backward compatibility. Nested inheritance addresses the first five requirements, but it does not support extension composition. Nested intersection adds this capability. " IMO point 5 is often overlooked in Smalltalk systems, we love extending base code but we hardly ever think about isolating these extensions so the base code dependents don't get 'confused' by those extensions. R - |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Jason Johnson-5
You may find ideas in Naiad, the module system for Spoon.
On Jan 20, 2008 11:30 AM, Jason Johnson <
[hidden email]> wrote: Hi all, |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Reinout Heeck
There has been many propositions like this: J&, MZScheme's Unit,
Selector Namespaces, Method Namespaces, Expander, Java Module System, Jiazzy, ... I could say another 20 more. I see that the three main difficulties in adding a module system in a programming language are: - Turning non-modularized libraries into modularized one - Preserving backward compatibility - Getting the community accept the proposal Cheers, Alexandre On 23 Jan 2008, at 08:28, Reinout Heeck wrote: > Jason Johnson wrote: >> Hi all, >> Recently working in other high level languages I was thinking about >> how modularity is accomplished in these systems and how we might >> do it >> in Squeak. > > > This is a recurring discussion and I often see suggestions like > yours: postulate a mechanism and discuss its viability. I would > call this the bottom-up approach. > > If we went top-down we could start with specifying what we want to > get from a module system. I recently came across a paper on J& > ('Jet') which starts out with a list of requirements we might want > to ponder in this regard: > > > > http://lambda-the-ultimate.org/node/2591 > " > J&: Nested Intersection for Scalable Software Composition by > Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006. > > We identify the following requirements for general extension > and composition of software systems: > > 1. Orthogonal extension: Extensions may require both new > data types and new operations. > 2. Type safety: Extensions cannot create run-time type errors. > 3. Modularity: The base system can be extended without > modifying or recompiling its code. > 4. Scalability: Extensions should be scalable. The amount of > code needed should be proportional to the functionality added. > 5. Non-destructive extension: The base system should still > be available for use within the extended system. > 6. Composability of extensions. > > The first three of these requirements correspond to Wadler’s > expression problem. Scalability (4) is often but not necessarily > satisfied by supporting separate compilation; it is important for > extending large software. Non-destructive extension (5) enables > existing clients of the base system and also the extended system > itself to interoperate with code and data of the base system, an > important requirement for backward compatibility. Nested > inheritance addresses the first five requirements, but it does not > support extension composition. Nested intersection adds this > capability. > " > > > IMO point 5 is often overlooked in Smalltalk systems, we love > extending base code but we hardly ever think about isolating these > extensions so the base code dependents don't get 'confused' by > those extensions. > > > > R > - > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Reinout Heeck
On Jan 23, 2008 12:28 PM, Reinout Heeck <[hidden email]> wrote:
> > IMO point 5 is often overlooked in Smalltalk systems, we love extending > base code but we hardly ever think about isolating these extensions so > the base code dependents don't get 'confused' by those extensions. Thanks for the mail. Actually, I think Classboxes deals with exactly case 5. |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Bergel, Alexandre
Wonderful, thanks. I dig through those and see if I find something
like what I'm envisioning. On Jan 23, 2008 3:10 PM, Bergel, Alexandre <[hidden email]> wrote: > There has been many propositions like this: J&, MZScheme's Unit, > Selector Namespaces, Method Namespaces, Expander, Java Module System, > Jiazzy, ... I could say another 20 more. > > I see that the three main difficulties in adding a module system in a > programming language are: > - Turning non-modularized libraries into modularized one > - Preserving backward compatibility > - Getting the community accept the proposal > > Cheers, > Alexandre > > > > On 23 Jan 2008, at 08:28, Reinout Heeck wrote: > > > Jason Johnson wrote: > >> Hi all, > >> Recently working in other high level languages I was thinking about > >> how modularity is accomplished in these systems and how we might > >> do it > >> in Squeak. > > > > > > This is a recurring discussion and I often see suggestions like > > yours: postulate a mechanism and discuss its viability. I would > > call this the bottom-up approach. > > > > If we went top-down we could start with specifying what we want to > > get from a module system. I recently came across a paper on J& > > ('Jet') which starts out with a list of requirements we might want > > to ponder in this regard: > > > > > > > > http://lambda-the-ultimate.org/node/2591 > > " > > J&: Nested Intersection for Scalable Software Composition by > > Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006. > > > > We identify the following requirements for general extension > > and composition of software systems: > > > > 1. Orthogonal extension: Extensions may require both new > > data types and new operations. > > 2. Type safety: Extensions cannot create run-time type errors. > > 3. Modularity: The base system can be extended without > > modifying or recompiling its code. > > 4. Scalability: Extensions should be scalable. The amount of > > code needed should be proportional to the functionality added. > > 5. Non-destructive extension: The base system should still > > be available for use within the extended system. > > 6. Composability of extensions. > > > > The first three of these requirements correspond to Wadler's > > expression problem. Scalability (4) is often but not necessarily > > satisfied by supporting separate compilation; it is important for > > extending large software. Non-destructive extension (5) enables > > existing clients of the base system and also the extended system > > itself to interoperate with code and data of the base system, an > > important requirement for backward compatibility. Nested > > inheritance addresses the first five requirements, but it does not > > support extension composition. Nested intersection adds this > > capability. > > " > > > > > > IMO point 5 is often overlooked in Smalltalk systems, we love > > extending base code but we hardly ever think about isolating these > > extensions so the base code dependents don't get 'confused' by > > those extensions. > > > > > > > > R > > - > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Laurence Rozier
Hi all-- Just another plug for the #squeak and #spoon IRC channels on irc.freenode.net, as venues for discussing this stuff. thanks, -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] |
Re: Musings about modularity and programming in the large
|
|
Oh yea, I meant to say that the spoon stuff sounds the closest to what
I was talking about (but with the extra wrinkle of modules being able to live in other memory spaces). Cool stuff. On Jan 23, 2008 7:26 PM, Craig Latta <[hidden email]> wrote: > > Hi all-- > > Just another plug for the #squeak and #spoon IRC channels on > irc.freenode.net, as venues for discussing this stuff. > > > thanks, > > -C > > -- > Craig Latta > improvisational musical informaticist > www.netjam.org > Smalltalkers do: [:it | All with: Class, (And love: it)] > > > |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Jason Johnson-5
http://gulik.pbwiki.com/Namespaces
There is code available on the 3.10 Package Universes that I'm currently using to varying degrees of success. Gulik. On Jan 23, 2008 6:36 AM, Jason Johnson <[hidden email]> wrote: So no one knows of a system like this? There's nothing new in our -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/ |
|
|
In reply to this post by Michael Haupt-3
"Michael Haupt" <[hidden email]> wrote in message
> reading your posting, I had the impression there might be some > relations to Gilad Bracha's work on Newspeak... > > http://gbracha.blogspot.com/ > Wow. I just read some of that work. It seems to be remarkably clean & consistent with Smalltalk (to me ... insert standard newbie disclaimer here). The biggest difference between his work and Michael van der Gulik's work at http://gulik.pbwiki.com/Namespaces is that Gilad turns names into accessors (rather than symbol keys in a dictionary), gaining all kinds of other advantages that would be impossible otherwise. A bit cutting edge, perhaps, with some still-open questions ... but any other option probably would too... Sophie |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Jason Johnson-5
I spend some effort to summarize those work. If you are interested in
this... http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05cModuleDiversity.pdf Related work in: http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05bclassboxjOOPSLA.pdf Cheers, Alexandre On 23 Jan 2008, at 15:16, Jason Johnson wrote: > Wonderful, thanks. I dig through those and see if I find something > like what I'm envisioning. > > On Jan 23, 2008 3:10 PM, Bergel, Alexandre <[hidden email]> > wrote: >> There has been many propositions like this: J&, MZScheme's Unit, >> Selector Namespaces, Method Namespaces, Expander, Java Module System, >> Jiazzy, ... I could say another 20 more. >> >> I see that the three main difficulties in adding a module system in a >> programming language are: >> - Turning non-modularized libraries into modularized one >> - Preserving backward compatibility >> - Getting the community accept the proposal >> >> Cheers, >> Alexandre >> >> >> >> On 23 Jan 2008, at 08:28, Reinout Heeck wrote: >> >>> Jason Johnson wrote: >>>> Hi all, >>>> Recently working in other high level languages I was thinking about >>>> how modularity is accomplished in these systems and how we might >>>> do it >>>> in Squeak. >>> >>> >>> This is a recurring discussion and I often see suggestions like >>> yours: postulate a mechanism and discuss its viability. I would >>> call this the bottom-up approach. >>> >>> If we went top-down we could start with specifying what we want to >>> get from a module system. I recently came across a paper on J& >>> ('Jet') which starts out with a list of requirements we might want >>> to ponder in this regard: >>> >>> >>> >>> http://lambda-the-ultimate.org/node/2591 >>> " >>> J&: Nested Intersection for Scalable Software Composition by >>> Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006. >>> >>> We identify the following requirements for general extension >>> and composition of software systems: >>> >>> 1. Orthogonal extension: Extensions may require both new >>> data types and new operations. >>> 2. Type safety: Extensions cannot create run-time type >>> errors. >>> 3. Modularity: The base system can be extended without >>> modifying or recompiling its code. >>> 4. Scalability: Extensions should be scalable. The amount of >>> code needed should be proportional to the functionality added. >>> 5. Non-destructive extension: The base system should still >>> be available for use within the extended system. >>> 6. Composability of extensions. >>> >>> The first three of these requirements correspond to Wadler's >>> expression problem. Scalability (4) is often but not necessarily >>> satisfied by supporting separate compilation; it is important for >>> extending large software. Non-destructive extension (5) enables >>> existing clients of the base system and also the extended system >>> itself to interoperate with code and data of the base system, an >>> important requirement for backward compatibility. Nested >>> inheritance addresses the first five requirements, but it does not >>> support extension composition. Nested intersection adds this >>> capability. >>> " >>> >>> >>> IMO point 5 is often overlooked in Smalltalk systems, we love >>> extending base code but we hardly ever think about isolating these >>> extensions so the base code dependents don't get 'confused' by >>> those extensions. >>> >>> >>> >>> R >>> - >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Sophie424
Newspeak introduces a lookup of classes. Classes are looked up pretty
much the same way that methods are. This is a mechanism called virtual classes. It exists in many different systems such as Keris, gbeta, Caesar/J, Scala. It seems that Michael's proposal takes a different approach, where import statements enable a class version to be visible in a namespace. Alexandre On 23 Jan 2008, at 21:39, itsme213 wrote: > "Michael Haupt" <[hidden email]> wrote in message > >> reading your posting, I had the impression there might be some >> relations to Gilad Bracha's work on Newspeak... >> >> http://gbracha.blogspot.com/ >> > > Wow. I just read some of that work. It seems to be remarkably clean & > consistent with Smalltalk (to me ... insert standard newbie disclaimer > here). > > The biggest difference between his work and Michael van der Gulik's > work at > http://gulik.pbwiki.com/Namespaces is that Gilad turns names into > accessors > (rather than symbol keys in a dictionary), gaining all kinds of other > advantages that would be impossible otherwise. A bit cutting edge, > perhaps, > with some still-open questions ... but any other option probably would > too... > > Sophie > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Michael van der Gulik-2
On Jan 23, 2008 11:50 PM, Michael van der Gulik <[hidden email]> wrote:
> http://gulik.pbwiki.com/Namespaces > > There is code available on the 3.10 Package Universes that I'm currently > using to varying degrees of success. > > Gulik. Well, this isn't what I had in mind [1], but it looks quite good I must say. Are you planning to keep this namespace system as a separate entity from "User" and the other concepts you mentioned? The namespace part seems like potentially a good candidate for adoption to me. Do you have any pointers to projects using it, to get a feel for how well it's working in practice? [1] It's actually not so far away though. What I was envisioning was a system that behaves mostly like now, but "module classes" or "component classes" (classes that are made up of *classes* and methods instead of just methods) would be visible in the main dictionary and none of the classes that make one up would be visible. The only way one could be referenced outside is if the "module class" returned on from a method. There would probably be on the code browser when looking at such a class that lets one "zoom in" to see inside it and make changes. But anyway, i was just a kernel of an idea that others have probably had before (and wrote papers on why it doesn't work :). Not a live implementation like your system. |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Bergel, Alexandre
Yes, I ran across this from looking up the systems someone mentioned
earlier. Thanks, I'm going through it. On Jan 24, 2008 5:07 AM, Bergel, Alexandre <[hidden email]> wrote: > I spend some effort to summarize those work. If you are interested in > this... > > http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05cModuleDiversity.pdf > > Related work in: > http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05bclassboxjOOPSLA.pdf > > Cheers, > Alexandre > > > On 23 Jan 2008, at 15:16, Jason Johnson wrote: > > > Wonderful, thanks. I dig through those and see if I find something > > like what I'm envisioning. > > > > On Jan 23, 2008 3:10 PM, Bergel, Alexandre <[hidden email]> > > wrote: > >> There has been many propositions like this: J&, MZScheme's Unit, > >> Selector Namespaces, Method Namespaces, Expander, Java Module System, > >> Jiazzy, ... I could say another 20 more. > >> > >> I see that the three main difficulties in adding a module system in a > >> programming language are: > >> - Turning non-modularized libraries into modularized one > >> - Preserving backward compatibility > >> - Getting the community accept the proposal > >> > >> Cheers, > >> Alexandre > >> > >> > >> > >> On 23 Jan 2008, at 08:28, Reinout Heeck wrote: > >> > >>> Jason Johnson wrote: > >>>> Hi all, > >>>> Recently working in other high level languages I was thinking about > >>>> how modularity is accomplished in these systems and how we might > >>>> do it > >>>> in Squeak. > >>> > >>> > >>> This is a recurring discussion and I often see suggestions like > >>> yours: postulate a mechanism and discuss its viability. I would > >>> call this the bottom-up approach. > >>> > >>> If we went top-down we could start with specifying what we want to > >>> get from a module system. I recently came across a paper on J& > >>> ('Jet') which starts out with a list of requirements we might want > >>> to ponder in this regard: > >>> > >>> > >>> > >>> http://lambda-the-ultimate.org/node/2591 > >>> " > >>> J&: Nested Intersection for Scalable Software Composition by > >>> Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006. > >>> > >>> We identify the following requirements for general extension > >>> and composition of software systems: > >>> > >>> 1. Orthogonal extension: Extensions may require both new > >>> data types and new operations. > >>> 2. Type safety: Extensions cannot create run-time type > >>> errors. > >>> 3. Modularity: The base system can be extended without > >>> modifying or recompiling its code. > >>> 4. Scalability: Extensions should be scalable. The amount of > >>> code needed should be proportional to the functionality added. > >>> 5. Non-destructive extension: The base system should still > >>> be available for use within the extended system. > >>> 6. Composability of extensions. > >>> > >>> The first three of these requirements correspond to Wadler's > >>> expression problem. Scalability (4) is often but not necessarily > >>> satisfied by supporting separate compilation; it is important for > >>> extending large software. Non-destructive extension (5) enables > >>> existing clients of the base system and also the extended system > >>> itself to interoperate with code and data of the base system, an > >>> important requirement for backward compatibility. Nested > >>> inheritance addresses the first five requirements, but it does not > >>> support extension composition. Nested intersection adds this > >>> capability. > >>> " > >>> > >>> > >>> IMO point 5 is often overlooked in Smalltalk systems, we love > >>> extending base code but we hardly ever think about isolating these > >>> extensions so the base code dependents don't get 'confused' by > >>> those extensions. > >>> > >>> > >>> > >>> R > >>> - > >>> > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Jason Johnson-5
>
> Well, what I'm thinking about maintains the "factory of objects", just > expands on it a little. That is, a "module class" (a class that has > kind of "private" classes inside itself) is also potentially a factory > of objects. Different class methods may return different objects, but > that is the the case with the system we have now. There is nothing > that says a class method must return an instance of it's own class. > > The problem with "modules = scoped group of classes" is that it > introduces some new syntax to deal with this distinction. It would be > nice if things could remain "objects all the way down". Wy Module named: #Zork contains: { A, B } > As far as confusion, that is a valid concern, but in modern times all > development is done in an IDE. That is, the tools expand our > capabilities and I would rely on the tools for this situation as well. > The tools would have to operate such that there was no confusion. I do not believe that. I'm teaching too much oop to eat that cake. |
Re: Musings about modularity and programming in the large
|
|
In reply to this post by Michael Haupt-3
yes newspeak has some nice features: mixin, no metaclass (I imagine),
"block structure" not sure how to describe that for objet initialization... On Jan 22, 2008, at 10:36 PM, Michael Haupt wrote: > Hi Jason, > > On Jan 22, 2008 6:36 PM, Jason Johnson <[hidden email]> > wrote: >> So no one knows of a system like this? There's nothing new in our >> field since decades so I'm sure there are papers or an implementation >> out there, I just haven't found it yet. > > reading your posting, I had the impression there might be some > relations to Gilad Bracha's work on Newspeak... > > http://gbracha.blogspot.com/ > > He's got several entries in his blog that describe how Newspeak deals > with modularity, classes, dependencies, ... maybe you could give that > a try? > > Best, > > Michael > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |