No, it's not. I would be far more valuable to have modularized images though: Just like Next/Apples Nibs or Bundle-mechanism. These image-modules would be edited from a development-image-bundle. They could be used to form stand-alone applications already clean of the development code or libraries that contain only a diff to the base classes, these library-images could then be combined to form more complex images. They could also contain their own namespace⦠and they would replace the non-modelling packaging mechanism, but I digress⦠^^ | packageWorkedOn | packageWorkedOn := Browser newPackageNamed: 'Calculator'. packageWorkedOn importPackage: 'Seaside'. "Create code in the Browserâ¦" packageWorkedOn saveAsMonticello. packageWordedOn saveAsPackage. packageWorkedOn saveAsApplication. or something like that ⦠^^ On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <epicfan@gmail.com> wrote:
jarober says:
The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" projects never seem to come off is simple - Smalltalk isn't just flat text in an editor. Â Smalltalk is the entire interactive environment. It would be fairly simple to get a syntax parser, but it wouldn't be Smalltalk. Â It would be Ruby or Python with Smalltalk syntax. Somewhat useful perhaps, but not really Smalltalk.
:(
Hopefully it would have sufficient knowledge to be able to do something thus.
Sorry, but I believe that it is the way that had to take commercial Smalltalk. It surprises to me that Cincom and company do not see it.
Regards. -- View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project