Re: RfD - Object Extensions
- From: "mark4" <i440r@xxxxxxxxxxxx>
- Date: 16 Jun 2006 10:55:38 -0700
err... the ans standard already butchered this language, why butcher it
more ?
object obfuscation adds NOTHING
Doug Hoffman wrote:
PROBLEM
While there is general agreement that Object-Oriented Programming (OOP)
can be a valuable technique for solving certain types of problems,
Forth currently has no standard extension for this. A standard
extension would provide the following benefits:
1) Code written by anyone using a Forth ANS OOP extension could be
easily read, understood, and possibly used in whole or in part, by
others.
2) A standard set of classes could be created and grown over time.
This would provide a rich set of useful classes for constructs such as
object lists, dynamically sizable strings with many string methods, and
much more.
3) More programmers would be inclined to try Forth since many of
today's programmers insist on object programming support from any
language they use.
PROPOSAL
Adopt a long-existing "unofficial standard" OOP extension, based on the
once commercial product Neon. This basic syntax has been in use for 22
years and has since spread to four other Forths on two different
platforms (Yerk, Win32Forth, Mops/PowerMops, and Andrew McKewan's
ANS-compatible extensions. Platforms are Windows and Macintosh.).
TYPICAL USE
The basic Neon Model (hence referred to as NM) is inherently simple to
learn and use, yet offers a rich set of of OOP features allowing for
full expression of object-based solutions to problems using Forth. As
an example consider the following definition and use of a point class:
:CLASS Point \ :class begins the definition of a class, here the class
name is Point
VAR x \ declare two instance variables, embedded objects named x and
y of class VAR
VAR y
:M PUT: ( x y -- ) put: y put: x ;M \ :m begins the definition of a
method, ;m ends it
:M GET: ( -- x y ) get: x get: y ;M
:M CLASSINIT: 10 20 put: SELF ;M \ a method named classinit: will
automatically be invoked
\ upon object (or ivar) instantiation
;CLASS \ ;class ends the class definition
Point p \ instantiate a named object in the dictionary, named p
get: p \ will return 2 items to the stack, the numbers 10 and 20
REMARKS
A long-standing debate over the form of message sending has existed.
The two popular forms are as follows:
1. parameters-message-object
2. parameters-object-message
1. and 2. are similar but slightly different. The placement of the
parameter(s), if any, is generally agreed upon.
I would comment that there has been an over-emphasis on the importance
of the above. In this submitter's opinion there are many, many more
issues to carefully consider when selecting an OOP standard. However,
because of the history of the debate, I believe that I must address
this at the outset of this proposal.
Some have maintained that 2. is more "Forth-like" because it places the
noun (object) before the verb (message). However there appears to be
no problem with other ANS Forth constructs such as "100 TO MYVALUE"
which has the same ordering as 1. (verb preceding noun).
Further, this proposal (NM) is very flexible as-is and can easily
handle the situation where an object is passed via the stack to another
word which needs to send a message to that object. Consider the
following four different ways of handling this situation:
a) : test ( obj -- ) message: ** ;
b) : test ( obj -- ) message: [ ] ;
c) : test { obj -- } message: obj ;
Comment about c). A popular form of locals is used here. It has been
repeatedly demonstrated that, especially with the many optimizing
compilers in use today, locals can be as fast or faster than stack
manipulation.
d) : test ( obj -- ) message: <classname> ;
Comment about d). This uses a feature of the NM to easily and simply
invoke early binding, providing a significant speed increase, by
sending a message to the class with an object of class <classname> on
the stack. Of course this can only be used when the class of the
object is known.
Hopefully the above examples will put to rest any still-existing
concerns over the ordering of message and object. The NM can do both.
The NM presented, although simple and powerful as is, can be extended
even further in the future should the need/desire arise. These
extensions could include multiple inheritance, temporary objects
(existing only within one colon definition), class variables and class
methods, private methods and ivars, and much more. A precise example
of how this may be done exists in the Mops and PowerMops Forth
implementations, the full source code for which is freely available.
Other significant design features of the NM are listed as follows:
- Default early binding for speed. When defining methods of a class
that call other methods of that same class or superclass (which is
simply good factoring practice), it makes a lot of sense to use early
binding. This is the default, which the compiler will automatically
invoke, so there is no extra work for the programmer.
- Proper support of embedded objects as class instance variables
(ivars). One need only declare <classname> <ivarname> within a class
definition. Subsequent objects or ivars will then have these embedded
objects and the objects will be properly initialized and respond to
messages valid for its class.
- Objects can be created as named dictionary objects or unnamed objects
in the heap.
- As is done in SWOOP (SwiftForth's object programming extension), when
defining a class the message name, method definition, and association
of that method with that message, is all done in one step.
Additionally, also as in SWOOP, there is no need to declare that a
superclass method is being over-ridden. This is implied by the simple
existence of a new method definition of the same name.
- Also like SWOOP, the so called "Smalltalk-like" class/message-name
ordering scheme is used. While slightly slower than a virtual table
(VT) scheme, so called "Java-like", this submitter believes that the
flexibility of the Smalltalk-like scheme is the best design choice for
a Forth standard. The VT is very restrictive and, while it may work
for a single programmer, getting the entire Forth community to agree on
a common class/message ordering scheme would be difficult or
impossible.
REFERENCE IMPLEMENTATION
An ANS-compatible NM implementation, complete with full documentation
and an example class library, is available at the following URL:
http://members.talkamerica.net/douglashoffman@xxxxxxxxxxxxxxx/
Use file CLASS12F.zip for Windows, and CLASS12MF.zip for Macintosh.
The content is identical, but the formatting is different.
Note that this implementation is based directly on the work of Andew
McKewan circa 1996-1997.
TEST CASES
A complete set of test cases are provided in the Reference
Implementation. See file TEST12.F.
EXPERIENCE
As mentioned above, the NM has existed for 22 years. Current
implementations, with nearly identical syntax to the provided Reference
are Win32Forth and PowerMops.
Respectfully submitted,
Douglas B. Hoffman
16 Jun 2006
.
- Follow-Ups:
- Re: RfD - Object Extensions
- From: Doug Hoffman
- Re: RfD - Object Extensions
- References:
- RfD - Object Extensions
- From: Doug Hoffman
- RfD - Object Extensions
- Prev by Date: Re: State of Forth 200x
- Next by Date: Re: RfD - Object Extensions
- Previous by thread: RfD - Object Extensions
- Next by thread: Re: RfD - Object Extensions
- Index(es):
Relevant Pages
|
