Re: [Pharo-project] IS Smalltalk Source also an object?
On Oct 17, 2011, at 10:25 AM, Guido Stepken wrote:
Hi, there!
I had a nice conversation about Smalltalk among software architects:
I claim smalltalk to be the only programming system, where source is an object too, with all advantages and disadvantages!
Am i right?
No, source is ascii text in Smalltak, and it's on the disk even. The only thing that is objects are classes and methods. Below of a full method, the reflective model stops. (you can ask the compiler to make an AST from the dead code on disk, but that model is not causally connected and thus not reflective, and it's only there when you create it. This you can do in any language, though). Of course it is interesting what happes when one fixes that... "Sub-Method Reflection": http://www.jot.fm/issues/issue_2007_10/paper14.pdf Marcus -- Marcus Denker -- http://marcusdenker.de
On Mon, Oct 17, 2011 at 1:35 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On Oct 17, 2011, at 10:25 AM, Guido Stepken wrote:
Hi, there!
I had a nice conversation about Smalltalk among software architects:
I claim smalltalk to be the only programming system, where source is an object too, with all advantages and disadvantages!
Am i right?
No, source is ascii text in Smalltak, and it's on the disk even.
Hang on. While I agree that the ideas in sub-method reflection really do make source an interesting object it is still the case that method sources and class comments /are/ objects, albeit only strings, even if implemented in an odd way with storage outside the image (but a really useful way since it provides for crash recovery). There are few other systems in which, in the running program, one can access the source of a method, bit in Smalltalk I can say thisContext method getSource, and that is I think Guido's point.
The only thing that is objects are classes and methods. Below of a full method, the reflective model stops. (you can ask the compiler to make an AST from the dead code on disk, but that model is not causally connected and thus not reflective, and it's only there when you create it. This you can do in any language, though).
Of course it is interesting what happes when one fixes that...
"Sub-Method Reflection":
http://www.jot.fm/issues/issue_2007_10/paper14.pdf
Marcus
-- Marcus Denker -- http://marcusdenker.de
-- best, Eliot
Maybe I've played too much football without a helmet or did too much C programming, but I see two questions popping out of this: (1) is source an object in Smalltalk; (2) in which languages/systems is source an object? This is an interesting debate. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda@gmail.com] Sent: Tuesday, October 18, 2011 1:43 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] IS Smalltalk Source also an object? On Mon, Oct 17, 2011 at 1:35 AM, Marcus Denker <marcus.denker@inria.fr<mailto:marcus.denker@inria.fr>> wrote: On Oct 17, 2011, at 10:25 AM, Guido Stepken wrote:
Hi, there!
I had a nice conversation about Smalltalk among software architects:
I claim smalltalk to be the only programming system, where source is an object too, with all advantages and disadvantages!
Am i right?
No, source is ascii text in Smalltak, and it's on the disk even. Hang on. While I agree that the ideas in sub-method reflection really do make source an interesting object it is still the case that method sources and class comments /are/ objects, albeit only strings, even if implemented in an odd way with storage outside the image (but a really useful way since it provides for crash recovery). There are few other systems in which, in the running program, one can access the source of a method, bit in Smalltalk I can say thisContext method getSource, and that is I think Guido's point. The only thing that is objects are classes and methods. Below of a full method, the reflective model stops. (you can ask the compiler to make an AST from the dead code on disk, but that model is not causally connected and thus not reflective, and it's only there when you create it. This you can do in any language, though). Of course it is interesting what happes when one fixes that... "Sub-Method Reflection": http://www.jot.fm/issues/issue_2007_10/paper14.pdf Marcus -- Marcus Denker -- http://marcusdenker.de -- best, Eliot
2011/10/18 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Maybe I've played too much football without a helmet or did too much C programming,
Yes, and yes, that's why you missed Eliot's answer ;) http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/55024 Nicolas but I see two questions popping out of this: (1) is source an object in Smalltalk; (2) in which languages/systems is source an object?
This is an interesting debate.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda@gmail.com] Sent: Tuesday, October 18, 2011 1:43 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] IS Smalltalk Source also an object?
On Mon, Oct 17, 2011 at 1:35 AM, Marcus Denker <marcus.denker@inria.fr<mailto:marcus.denker@inria.fr>> wrote:
On Oct 17, 2011, at 10:25 AM, Guido Stepken wrote:
Hi, there!
I had a nice conversation about Smalltalk among software architects:
I claim smalltalk to be the only programming system, where source is an object too, with all advantages and disadvantages!
Am i right?
No, source is ascii text in Smalltak, and it's on the disk even.
Hang on. Â While I agree that the ideas in sub-method reflection really do make source an interesting object it is still the case that method sources and class comments /are/ objects, albeit only strings, even if implemented in an odd way with storage outside the image (but a really useful way since it provides for crash recovery). Â There are few other systems in which, in the running program, one can access the source of a method, bit in Smalltalk I can say thisContext method getSource, and that is I think Guido's point.
The only thing that is objects are classes and methods. Below of a full method, the reflective model stops. (you can ask the compiler to make an AST from the dead code on disk, but that model is not causally connected and thus not reflective, and it's only there when you create it. This you can do in any language, though).
Of course it is interesting what happes when one fixes that...
"Sub-Method Reflection":
   http://www.jot.fm/issues/issue_2007_10/paper14.pdf
   Marcus
-- Marcus Denker -- http://marcusdenker.de
-- best, Eliot
participants (4)
-
Eliot Miranda -
Marcus Denker -
Nicolas Cellier -
Schwab,Wilhelm K