MSimon wrote:
FORTH handles it differently. You can only access (without contortions) the last definition of the operation.
Example in pseudo code:
(1) Define Operation
(2) Define Operation
(3) Call Operation
In such a situation the Call only references (2). Debugging then is much simpler.
Well, yes, but..
(1) Define MyOperation to print "(1)"
(2) Define My2ndOperation to print "(2)" and call MyOperation
(3) Define MyOperation to print "(3)
(4) Call MyOperation -- output is "(3)"
(5) Call My2ndOperation -- output is "(2)(1)"
BTW FORTH had objects way before any other language.
Citation?
FORTH was named in 1968, Simula 67 (an object-oriented language) was formalized in, well, 1967, before FORTH was named and released into the wild.
Also, in the 1984 book, "Thinking FORTH", author and FORTH evangelist Leo Brodie had some quite nasty things to say about objects and how bad they were (and how FORTH handled things better). His thinking did evolve, here's a couple of excerpts from the prefaces to the 2004 edition:
Bernd Paysan wrote:
The original 1984 Thinking Forth feels a bit dated today. A lot happend with
Forth in the last 20 years, since this book was first published.
...
Paradigms like object oriented programming were adopted to Forth.
...
This edition adds all the missing things from the original:
• Add chapters about Forth and OOP, Forth debugging, and maintenance.
Leo Brodie wrote:
In the 1994 Preface, I apologized that my dismissal of objected-oriented
programming in the 1984 edition was a little overreaching. What motivated
that apology was having worked for a time with an object-oriented flavor of
Forth developed by Gary Friedlander for Digalog Corp. I discovered that
the principles of encapsulation could be applied elegantly to Forth “objects”
that derived from classes that each had their own implementation of common
methods. The objects “knew” information about themselves, which made code
that called them simpler. But these were still just Forth constructs, and the
syntax was still Forth. It wasn’t Java written in Forth. There was no need
for garbage collection, etc. I won’t apologize now for my apology then, but
please know that I didn’t mean to sell out in favor of full-blown object oriented
languages.
A survey of Object Oriented FORTH variants lists NEON (1984) as the earliest.
To say that "FORTH had objects way before any other language" is stretching things a lot.
BUILDS gives you a pointer to the structure DOES does the required operation(s). For multiple possible operations you can use CASE to determine which one you want.
That sounds a bit like how Scheme "has" objects. An "object" is a function which returns other functions to do what needs to be done:
Code: Select all
(define (rect-constructor)
(lambda (message)
(define height 0)
(define width 0)
(cond
((= 'set-height! message) (lambda (h) (set! 'height h)))
((= 'set-width! message) (lambda (w) (set! 'width w)))
((= 'get-height message) (lambda () height))
((= 'get-width message) (lambda () width))
((= 'get-area message) (lambda () (* height width)))
;; etc, for more
)))
(define rect1 (rect-constructor))
(define rect2 (rect-constructor))
((rect1 'set-height) 5)
((rect1 'set-width) 10)
((rect2 'set-height) 6)
((rect2 'set-width) 8)
((rect1 'get-area))
===> 50
((rect2 'get-area))
===> 48
It's not elegant, but it's a demonstration of the idea that you can do objects and object oriented programming in almost any language. Linux is written in C, but is developed using objects and object-orientated programming. That doesn't mean I'd say that Scheme or C "have objects". Lisp 1.5 (released in 1962) has all the features necessary to implement "objects" in that fashion. Does that mean that Lisp 1.5 "had objects way before any other language"?
[/quote]