There are some arguments against NEON OO Model on which Mops and Win32Forth are based. Most of those arguments stands on some implicit presuppositions that lead to the conclusionthat NEON OO Model is bad.
I hate to participate in political debates disdaining something. But I will try here to defend NEON OO Model against tricky arguments. By the way, I never try to refute other OO models than that of Mops. Simply I want to free Mops OO Model from wrong images.
An Object should be passed via parameter stack in Forth dialects?
In Object Orientation Semantics, Object is a receiver of messages and an actor. It is not considered as a Data or Parameter or other thing to be passed to a procedure via parameter stack. Surely, an object is internally some data in Mops and Win32Forth, too. But the fact belongs to the implementation details. Implementation detail is another problem than the syntax and semantics of a language. If one says objects must be data so that they must be passed via parameter stack as parameters, the one is losing sight of OO semantics and sticking to the second class or pseudo OO, say, "Data Orientation". Of course, it is never wrong in itself for objects to be able to be passed as parameters. The objectID (normally pointer) of an object is surely a datum. But at the same time it could not be called a defect of the system if an object would not be passed as a parameter in normal message sending.
So "selector object" syntax is never worse than "object selector" syntax from the view of OO semantics (human interpretation). Or rather "selector object" syntax is better in message sending appearance in my opinion because it distiguishes the actor (object) from parameters to be processed by it.
The fact that Selector cannot be ticked hinders extensibility.
By the way, why can Selector always be ticked? Tick pushes xt of the word ticked to data stack. Which xt? Selector is not a word in that its execution semantics is undefined without combining witha class or object.
Surely, after defining a way of binding a selector can be ticked. That is, we can do in NEON Model:
: AMETHOD SELECTOR: [] ; ' AMETHOD
But it is because by defining the selector as being late bound, looking for the appropriate method of a passed object through class linkage becomes a part of contents of SELECTOR:'s execution semantics.The opinion that a selecor should always be tickable is based on a presupposition thatselector always has its definite execution semantics.But the presupposition itself is false in NEON Model.In OO semantics of NEON Model it is object, not selector that looks for method in its class on gentting message. Normal selector in NEON model is a part of message but not a name of a procedure by itself.
Still you need early bound method xt? If so you can do in PowerMops:
ref ACLASS AnObjRef no_subclasses \ ossia [[ObjPtr]] AnObjRef class_is ACLASS
: AMETHOD ( param1 param2 ... ^obj -- ? ) -> AnObjRef SELECTOR: AnObjRef ; ' AMETHOD
Or you need faster late bound method xt using a methods table? If so you can do in PowerMops:
ref ACLASS AnObjRef
: AMETHOD ( param1 param2 ... ^obj -- ? ) -> AnObjRef SELECTOR: AnObjRef ; ' AMETHOD
AnObjRef can be a temporary (that is, local) object when it is declared with "ref".
Addition:(8/3/06)
An object could be seen as an actor or data+index to method. parameters selector: object syntax shows the object as an actor and parameters+selector=message as Input to the object. That is, selector is a part of input to object.It is default OO syntax of NEON model, so we cannot reproduce the process or function from selector via tick. Why could we know from a part of the input, the process in which it will be thrown?
On the other hand, Mops allows also to see an object as data+index to method.Index to method is a pointer to the class or to the method table in PowerMops.Other optional arrangements for method binding represent this consideration.
Smalltalk-like late bind is slow.
Yes, it is slow compared with early bind. Late bind is about 20 times slower than early bind in some bench mark code in PowerMops.But early bound method is very fast in PowerMops. Although it can not be generalized, early bound method of PowerMops on PPC seems to be about 5 times faster than equivalent non-OO code in GForth native on x86 machine in CPU clock base from some data. Anyway, PowerMops' early bound method is really fast.Late bind is slower than _it_. On PowerPC, PowerMops' late bound method is about 10 % faster than non-OO equivalent codein GForth 0.6.2. Damn slow? Definitely NO.
In reality, iterative late binding (polymorphism) happens often on a heavy task in itself like "DRAW".In such a case over head concerning method binding is almost negligible.
Besides. Who can say NEON Model is incompatible with a vtable like late bind?PowerMops' class does build a methods table. It is not the matter of OO model.Again, an implementation detail!PowerMops doesn't require something like VIRTUAL declarations of methods, unlike C++.Quite handy.
To tell the truth, PowerMops' normal (wihout vtable) late binding implementation has a special search optimization (acceleration) mechanism. As the result, it becomes fast as it is.System implementer can and should elaborate one's implementation in order to make the system fit with the preference, unless the implementation details should be controlled by others.
Conclusion
An argument such that using such and such technique internally is bad will come typically from the view of language system implementers, not from that of users of the language. We could see the OO feature of a language as one of the tools to write application in the language. Implementation details could be left to the ingenuity of system implementers.Then we could concentrate the syntax-semantics relation of OO constructs.In this respect NEON model is not bad. If you have your own (favorite) Forth with OO extension different from NEON model,NEON model may look bad and ununderstandable. So what?From my experience Mops OO feature is very good for application programming.But if you don't understand and never have done programming in Mops, Mops code will look like unreadable. That would hold for any languages.The strength of OO syntax of PowerMops may be best realized when you are writing some application in PowerMops. -- Maybe not when you are trying to implement the OO model for your system.
Theories concerning OO generally look like bound by (negatively or positively) the world view of Algol family (C, C++, Java). But Forth is flexible and extensible language, instead of inflexible and fixed language, like C.Why do we need to worry about OO theories build (aversively) on (procedural or sometimes even including hybrid type) Algol family languages?Java model may be good (the best? how about Objective-C? you stick to the (a bit old) industry and/or scholastic standard? It may be ok. But unfortunately we are free from such a credo.) OO construct in context of C. But its OO syntax and semantics look still in half way. "When an object is passed as a parameter to a procedure,the procedure checks the class and ..." This sounds like always-virtualized C++. But we really need it on Forth?Surely NEON model didn't look like (reversed) Java. But so what? Is it a bad signal in itself?
In my opinion, the thought that an object is data is a quite low level idea.Even if such a thought is allowable, taking an object quite the same as other parameters is wrong according to the standard OO way of thinking. It might be better to push object IDs onto another stack than normal parameter stack in that such a thought, at least, is not confusing objects with data parameters.But once we suppose a special object stack to which objects are dynamically pushed at runtime, default late binding begins to look very natural in order to send messages consecutively to anonymous objects in the object stack. This thought seems to treat objects as a group of data.This grouping is realized as class-structures in Java or C++. Late binding loosens tight and narrow restrictions of class-as-type mechanism in Java or C++,and virtual method utilize this looser grouping. So late binding (sometimes identified with polymorphism) is seen as the true establishment of OO for Java or C++. In this philosophy, an instance (individual) is derived from its group (whole or class structure). Building the structure (set-subset grouping) is more important than individual objects. Objects (instances) are processed by something (method) according to the group they belongs to. Methods are the first class entities in this view, so each of them should have the independent meaning inspite of naming collisions.This is quite different from the philosophy of NEON model where the property of an individual object is more important than class structure, and the structure is a mere result of the similarity of properties among objects. Objects (instances) process some data as processors using their methods.Objects are the first class entities and methods are secondary (ancillary) to the object that knows them. Surely, PowerMops uses systemcall functions. Those are written in C++ so that a system object is a data -- low level object -- to be passed as a parameter to a function.But we know our OO model can cohabit with it because ours lives at higher level. In NEON OO model we don't need to stick to the lower level to keep low level accessibility because our moving to the higer level never sacrifice the lower level constructs. Such a cohabitation of low level and high level is Forth, I think.
In my humble opinion, C++ or Java looks like taking a side road to OO. In Smalltalk or NEON model we think that an object has its ability (functionality) and propertiesand shares those with other objects by inheritance. While in C++ or Java all such things seem to be treated in view of accessibility. It is not, of course, illogical. But at the same time such accessibility definitions can be so much complicated thatan object cannot be recognizable as a semantically definite entity. I suspect that this growing tendency of the complication of rules to define wether to allow/prohibit accessing may cause, so to speak, concentration of abstract class structure and thought that an object is a mere data because such a complication is very likely to break the unity of an object as an actor. Of course, such way of thinking or programming habit comming from the C++ or Java situation is neither bad nor good in and by itself. My point is that different presuppositions will lead to different ways of thinking or programming habits. Terribly bad design fom one point of view may not be so bad from another point of view, vice versa. We should reflect on which presupposition we are putting in evaluating something. That's all.
Mops' default method binding is said to be Early Binding. But it is programming-default or a kind of standard, not interpreter and/or compiler default. Mops allows plural ways of message sending. But the way of binding is always explicit in code. Mops doesn't try to force programmers to take one certain way. It simply leaves many possibility to the programmers.It may be considered bad in the world of standard programming. But if they were true, Forth itself would be bad.Additionally we never confuse normal words with messages to invoke corresponding methodsin Mops code because they obey distinguishable syntax rules. Word and selector are different entities in NEON model, so they look different in Mops code. It is natural, I think.
NEON OO model is said to be based on Smalltalk model.It is true that Smalltalk is too different from Forth since it is pure OO language. But we should be able to learn from Smalltalk (or other pure OO language) a natural and straightforward OO syntax-semantics correspondence, and think about its realization in Forth. From this point of view, NEON model has a excellent mesage sending appearance in my opinion. Moreover, advantages of NEON model are more in practical aspects of programming than in theoretical ones.This achivement is surely an evidence of Forth's tremendous expressive power since whole the OO construct has been written in Forth.
Or you insist we should keep Forth pure? Well, but we never lose the pure Forth by adding OO constructs. Supplying NEON OO feature will never prevent us from programming in pure Forth.It is the strength of Forth we are referring to. You may need a simplicity. But there is no THE simplicity. Simple doesn't always mean short code.Fortunately, everything is already simple in Forth -- aren't you confused by your implicit suppositions?You may say "we should wipe it hour by hour and let no dust alight".But we will reply "it is always clean so where can the dust alight?"(Zen of Forth).
Appendix : a defect of some of Object-Method syntax (unfinished)
My argument was(is) supposing PowerMops as a typical example of NEON OO model. And I treated only standard OO syntax of PowerMops. PowerMops has some OO related features that were not mentioned above.For example:
PowerMops allows also object-method(+class information) syntax for binding. We can select one way according to the situation.
PowerMops' class can have a method whose content may be different object-wise, and, when needed, can be changed dynamically. But this feature is achived by xt-variable functionality, which is already in standard Forth.That is, PowerMops solves this problem via instance variables, not inheritance. Since standard Forth already has the solution, NEON model doesn't need additional theoretically sophisticated late binding mechanism or other OO functionality to solve it.
(I don't know what OO features Win32Forth has. But I think what features PowerMops has could be implemented in Win32Forth.)
This article was written as a reaction agaist the claim "message-object syntax is bad or simply wrong". So, this article doesn't contain all features of PowerMops OO.
I used an OO semantics to support message-object syntax. But I am not a Dogmatiker. I never insist that this semantics is one only theoretical foundation for PowerMops' OO coding.I have never imagined that every PowerMops user should first be taken by this semantics to understand the OO code in PowerMops. My intention was simply that since one simple and understandable semantics can support message-object syntax, this syntax should have some reason. So I think that a claim "message-object syntax is bad or simply wrong" was shown to be baseless.
I like PowerMops' OO syntax by practical reason, not by dogmatical one. I have been thinking about philosophy to support PowerMops language including pure Forth part.But the motivation comes from experience of real coding on PowerMops.I have realized PowerMops is very powerful. Moreover PowerMops, which is optimizing native Forth compiler for PowerPC with OO feature based on NEON model, is wholly written in Mops.That means, PowerMops itself is an example software of NEON type OOP. And its syntax and semantics make communication with other programmers by codequite easy.I have been trying to undestand what in PowerMops language makes it so (in my opinion) great.
I found Dogmatikers tend to hate NEON OO model, or even Forth ideas.Perhaps, because those ideas doesn't fit for their dogma.It is true, theory may help to simplfy the grammar of programming language. But excessive simplification could cause practical confusion.
What I call practical reason to favour PowerMops, is the fact that what we are doing is clear from the code in PowerMops. Selectors have a bit different appearance from normal words.By that, we can easily realize whether certain part of the code is written in OO or in normal Forth. In all cases of OO coding, selector supposes object near by and may be followed by class name or certain token, which are context elements used to define appropriate method. (I tend to think such a combination of words as a "phrase", which is an extension of concept ‘word’.)The context is very local. It is consumed with one selector. (Well, now PowerMops has a syntax to extend the context in a case. But the ends of the context can be made clear in code.) Locality of information for interpretation of code is important factor for readble code.
I realized that in some OO Forth using object-method syntax, object and method cannot be distinguished from normal Forth word in the names.And according to object-method synax theory, object (or class name) switches the contexts.Since we cannot see whether a word is an object or a normal forth word from its name,object can be said to cause implicit context change.Introducing implicit context change in a language is a really bad idea, I believe.OO system of such type will be, sooner or later, unable to live without some naming convention,such as, Begin Object name by a capital letter, etc.. But setting conventions will be too weak to avoid all possible problems coming from implicit context change. For example
aFile dup
may duplicate ‘aFile’ (File duplication when dup is a mothod of file). Or ‘aFile’ may do something and ‘dup’ duplicate a stack item. How could you know which is the case from this line?If you know aFile is an object and has a method ‘dup’, the definition of dup will be found in method implementation (definitioin). But the method operating code above doesn't contain the information. That is, introducing implicit context change may break the reliability of normal forth words in the meaning of the actions when reading code(especially when debugging the code other programmers wrote).
In Reality, syntactical details are trivial. Implementing some features or flavors is also trivial in Forth based environment. Anything isn't very difficult to implement in Forth environment compared with some other languages. But I think confusing syntax should be avoided, even if that might be a result of exact mapping of OO to standard Forth syntax.
Surely, good programmers could avoid all such troubles by some coding conventions or goood memory.Some may say, "I have no problem with that. So it is perfect."OK. I could believe it is true for you. But how about anyone other than you? Forth should be only for good programmers?But no one is born as a good programmer, andnot every person will begin programming as a good programmer. Such an elitism might kill the language.
However I myself don't care about what floavors will be adopted as the future OO standard of Forth. Once the specification becomes clear, PowerMops surely can support it by an optional library.
最終更新：2019年01月08日 09:04
