|
|
 Up |
|
|
  |
Author: Brad EckertBrad Eckert Date: Jul 25, 2008 11:28
The two prevailing syntaxes seem to be:
message object
object message
Neon uses "message object". That's the one I'm familiar with from
Win32forth. Neon has a big following, but that could be the result of
being in the right place at the right time.
OOF uses "object message". I like that better, but for different
reasons than Bernd. It seems to me that object can set up the search
order (I don't see any SET-ORDER in OOF) to limit the visibility of
methods and data to their associated objects. This search order can
include ancestors. "message object" also limits scope, but in a less
Forth-like way. I like to start things off by looking at possible
implementation.
A base class would contain a word similar to CREATE (call it CREATE-
CLASS) but instead of pushing the address of the structure onto the
stack, it would store it into a variable called CLASS. This allows
descendants to append to the class structure.
|
| Show full article (3.28Kb) |
|
| | 132 Comments |
|
|
Author: Elizabeth D RatherElizabeth D Rather Date: Jul 25, 2008 11:54
Brad Eckert wrote:
> The two prevailing syntaxes seem to be:
> message object
> object message
>
> Neon uses "message object". That's the one I'm familiar with from
> Win32forth. Neon has a big following, but that could be the result of
> being in the right place at the right time.
>
> OOF uses "object message". I like that better, but for different
> reasons than Bernd. It seems to me that object can set up the search
> order (I don't see any SET-ORDER in OOF) to limit the visibility of
> methods and data to their associated objects. This search order can
> include ancestors. "message object" also limits scope, but in a less
> Forth-like way. I like to start things off by looking at possible
> implementation.
|
| Show full article (1.88Kb) |
|
| | no comments |
|
|
Author: DavidMDavidM Date: Jul 25, 2008 14:04
On Fri, 25 Jul 2008 11:28:39 -0700, Brad Eckert wrote:
> The two prevailing syntaxes seem to be: message object
> object message
There's a third syntax, and one which is used by most of the popular
programming languages:
object oo-token message
For example, in C++ you have:
objvar . message ([args]) or
objptr -> message ([args])
In Python and Java it is:
objref . message ([args])
John Sadler's FICL forth uses a variant of this, as in:
objref classref --> message
Within my aumForth, I'm using:
objref -> message
|
| Show full article (3.01Kb) |
| no comments |
|
|
Author: CelimeCelime Date: Jul 26, 2008 01:12
"Elizabeth D Rather" forth.com> a
|
| |
| no comments |
|
|
Author: Ian OsgoodIan Osgood Date: Jul 26, 2008 08:29
On Jul 26, 1:12Â am, "Celime" wrote:
> "Elizabeth D Rather" forth.com> a écrit dans le message denews: l4ednbaxVqPIvBfVnZ2dnUVZ_qjin__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$z__@supernews.com...> Brad Eckert wrote:
>
> ...
>>> SwiftForth's SWOOP is "object message", and the implementation does
>> use search orders much as you describe. Â Rick Van Norman, who was the
>> principal author of SWOOP, preferred this order because it makes it
>> possible to go:
>
>> Â Â obj1 Â obj2 Â obj3 Â method
>
>> (where obj2 is within obj1's class, etc.) which he found a lot more
>> powerful.
>
> But this technique does not comply with the basic access protection
> rules
> for internal objects.
>
> -Charles ...
|
| Show full article (1.25Kb) |
| no comments |
|
|
Author: CelimeCelime Date: Jul 26, 2008 13:32
"Ian Osgood" quirkster.com> a
|
| |
| no comments |
|
|
Author: Bernd PaysanBernd Paysan Date: Jul 26, 2008 13:45
Brad Eckert wrote:
> OOF uses "object message". I like that better, but for different
> reasons than Bernd. It seems to me that object can set up the search
> order (I don't see any SET-ORDER in OOF) to limit the visibility of
> methods and data to their associated objects. This search order can
> include ancestors. "message object" also limits scope, but in a less
> Forth-like way. I like to start things off by looking at possible
> implementation.
Look a bit closer at oof.fs, then you'll see the set-order:
%% grep -n set-order oof.fs
36:\ find definitions get-order set-order get-current wordlist
68:DOES> @ >r get-order nip r> swap set-order ;
219: r> over >r + set-order r> ;
235: ?dup 0= IF drop set-order true abort" method not found!" THEN
354: get-order wordlist tuck classlist ! 1+ set-order
601: :ilist + @ >r get-order r> swap 1+ set-order 1 voc# +! ;
654: dup inter-list ! dup set-current swap 1+ set-order
|
| Show full article (1.50Kb) |
| no comments |
|
|
Author: Elizabeth D RatherElizabeth D Rather Date: Jul 26, 2008 15:36
Ian Osgood wrote:
> On Jul 26, 1:12 am, "Celime" wrote:
>> "Elizabeth D Rather" forth.com> a écrit dans le message denews: l4ednbaxVqPIvBfVnZ2dnUVZ_qjin__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$z__@supernews.com...> Brad Eckert wrote:
>>
>> ...
>>>>> SwiftForth's SWOOP is "object message", and the implementation does
>>> use search orders much as you describe. Rick Van Norman, who was the
>>> principal author of SWOOP, preferred this order because it makes it
>>> possible to go:
>>> obj1 obj2 obj3 method
>>> (where obj2 is within obj1's class, etc.) which he found a lot more
>>> powerful.
>> But this technique does not comply with the basic access protection
>> rules
>> for internal objects.
>>
>> -Charles
>>
>> ... ...
|
| Show full article (1.90Kb) |
| no comments |
|
|
Author: Andrew HaleyAndrew Haley Date: Jul 27, 2008 02:54
Celime wrote:
>> The enforcement of access protection (private, public, interfaces,
>> etc) is not a requirement for an object oriented system. The Forth
>> philosophy is to grant access to all layers by default, giving the
>> user the responsibility to use the sharp tools wisely.
Right.
>> That said, there are probably tricks one can play with wordlists to do
>> implementation hiding and interface publishing. I've seen Forth module
>> systems which let you declare some words in a file public vs. private,
>> for example.
> That depends on the desired goal. If it is to allow the distribution
> of Forth libraries in full safety, I think protection of the
> internal coding is important.
|
| Show full article (1.45Kb) |
| no comments |
|
|
|
|
|
Date: Jul 27, 2008 04:24
Elizabeth D Rather wrote:
> Yes, SwiftForth also has "packages" that can be declared public or
> private. It's a strategy we've found useful in any program with a
> potentially very large namespace. But I don't see that as necessarily
> connected to OOP, though.
Not sure what you mean by that. Any literature I've seen on OOP
discusses the importance of encapsulation/information hiding.
I see in the the SwiftForth manual's section on SWOOP a rather complete
description of information hiding. SWOOP provides for the proper
technique with its PRIVATE and PROTECTED declarations:
From the SF manual:
"In true object-oriented programming, classes must have the ability to
hide members from external access."
-Doug
|
| |
| no comments |
|
|
|
|
