Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #30653

Re: A slightly longer mini-oof2.fs example.

Show all headers | View raw

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>As it quickly turned out with packages like mini-oof.fs, having the object
>>on the data stack is too much of an obstacle.  Mini-OOF is barely usable,
>>especially for accessing the instance variables.  So you will soon have a
>>current object.  Now what?  Use it only for instance variables?  This
>>results in inconsistent use: instance variables are relative to the
>>current
>>object, methods take it from the stack.  Inconsistent interfaces clutter
>>the mind, and therefore should be avoided.
> 
> I did not find that inconsistent when I wrote Gray.  After all,
> methods are not instance variables.  E.g., methods are bound
> dynamically, instance variables not.  Do you also think that this is
> an inconsistency that should be avoided?

No, because that is not an invocation inconsistency - invocation is your 
public interface, how you implement it is a private decision of the 
implementer.

In Forth, all things are first of all *words*.  And then you put them into 
bins like "variable" or "colon definition", usually classified by their 
stack effect.  In mini-oof2, you can have instance variables (they are 
defined with field: or friends, but actually relate to the current object; 
that choice was made because there is a large set of words already there 
with field: and a central place where to hook into to change the behavior), 
you can have methods, and you can factor your definitions into ordinary 
colon definitions, which would be "early bound methods" or non-virtual 
methods in C++.

And when you refactor your code, you can concentrate on the essence of 
refactoring, instead of going through your entire code base.  E.g. let's say 
foo was first an instance variable, holding a cell.  After a while, you 
discover that your object really has two states in which it has two 
different foos, and you now define

: foo ( -- addr ) mystate @ IF  foo1  ELSE  foo2  THEN ;

After a while, you discover furthermore that, well, this distinction is only 
necessary for 20% of your classes, and the other do well with having just 
one foo, so you declare foo as a method, and define that with

' foo1 my-baseclass to foo

or, for those who needs two states

:noname ( -- addr ) mystate @ IF  foo1  ELSE  foo2  THEN ; my-sublass to foo

The invocation never changed, and therefore, you never had to dig through 
your entire code base for all invokations of foo.

This sort of consistency makes maintaining code easy.  The thing you need to 
maintain consistently is the signature of the word (the way it is invoked), 
not the way it is implemented.

> One interesting observation in the Java part of my introductory
> programming course is that many students write "this.bla" where "bla"
> would be sufficient. I did not teach them that, and in what I show
> them I use "bla" instead (at least for instance variables).  I guess
> they learned it elsewhere and there is someone teaching that style.

Yes, probably.

> Which may be a good idea, it's more consistent with the access to the
> instance variables of other objects.

Well, you shouldn't access instance variables of other objects...

> Anyway, the problem with mini-oof.fs is that there is no current
> object at all.
> 
> Once we have a current object, the question is whether to set it
> implicitly on method call (as happens in most OO languages and most
> Forth OO packages), or whether to set it explicitly.  Or we might also
> do both: set it implicitly on method calls, and also allow explicit
> setting.
> 
> The actual difference is: When you set it implicitly on method calls,
> you pass this object on the stack.  When you don't set it on method
> calls, but only explictly, you do not pass the object on the stack,
> you only pass it through the current object.

Yes.  The thing I want to make is a *consistent* minimalistic set of 
operations, which all do *exactly one thing*.  And do that right.  And once 
there is a current object, the only way to manipulate that current object is 
the >o o> stuff, and it's orthogonal to all other operations, i.e. no other 
operation has a hidden side-effect which manipulates the current object.

The good thing for people like you is that the "do one thing right" for 
METHOD is to take a template and produce a method invocation from that 
template (that is to be consistent with +FIELD, which is the central place 
to define instance variables, and it is malleable - it will always add the 
offsets the same way, but what kind of FIELD stuff it implements can 
change).  You can change the template.  And if you like to, you can change 
that template to contain >O and O> around the actual invocation, so the 
variant of mini-oof2 you are using will require a THIS (or O as it is called 
in mini-oof2, as this is more consistent with the >O O> stuff) for invoking 
methods of the same object.  The default method invocation doesn't do this, 
because it is always easier to add things than to take them away.

Perfection is only reached when there's nothing left to take away.  
Consistency is reached when things have the same interface to the outside.
Flexibility is reached when you can change all those things to suit your 
needs.

Mini-oof2 came into life, because I started to experiment with a Forth Meta 
Object Protocol.  The intention is to have something that is so basic that 
nobody can refuse to add the basics.  And that you can extend it the way you 
want.  The basics are there to provide with essential stuff, and that means 
all this essential stuff is then somewhat compatible between different OOP 
systems that base on the same foundation.  Somewhat, because people do have 
incompatible method invocation, and that can't be fixed.  But what can be 
fixed is that these method invocations consist of core components which are 
the same, and the only difference is how to glue them together.

This allows a system implementer to implement a fast and efficient set of 
primitives, which he has the duty to maintain, and leave all the other stuff 
to the OOP package implementers, and there, he doesn't have to maintain 
things.

If you don't like  foo >o bar o>  in mini-oof2, add a dot-parser recognizer 
which will transform

foo.bar   into   foo >o bar o>
foo->bar  into   foo @ >o bar o>

with any number of . and -> in the string (just replace all "." with " >o " 
and all "->" with " @ >o " and count the number of occurances, and then add 
that number of " o>" to the end - and reevaluate). 

That stuff is probably a good idea to do, and improves readability.  It 
works consistently for accessing instance variables and methods from other 
classes.  This is the sort of consistency I'm aiming at.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-22 19:29 -0700
  Re: A slightly longer mini-oof2.fs example. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-23 11:22 +0000
    Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-23 09:38 -0700
  Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 12:11 +0000
    Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-23 10:26 -0500
      Re: A slightly longer mini-oof2.fs example. Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-23 19:59 +0200
        Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-24 04:23 -0500
        Re: A slightly longer mini-oof2.fs example. Hans Bezemer <the.beez.speaks@gmail.com> - 2014-05-24 15:47 +0200
          Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-26 12:46 -0700
        Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-24 15:35 +0000
          Re: A slightly longer mini-oof2.fs example. Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-24 20:45 +0400
          Re: A slightly longer mini-oof2.fs example. Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-24 21:46 +0200
            Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-25 15:03 +0000
              Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-25 15:16 -0500
              Re: A slightly longer mini-oof2.fs example. Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-26 00:47 +0200
          Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-25 18:55 -0500
            Re: A slightly longer mini-oof2.fs example. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-26 11:44 +0000
              Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 05:25 -0500
                Re: A slightly longer mini-oof2.fs example. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-27 11:56 +0000
            Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-26 12:18 -0700
              Re: A slightly longer mini-oof2.fs example. Paul Rubin <no.email@nospam.invalid> - 2014-05-26 12:46 -0700
                Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-26 13:43 -0700
              Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 05:28 -0500
    Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-23 09:39 -0700
      Re: A slightly longer mini-oof2.fs example. mhx@iae.nl - 2014-05-23 10:29 -0700
      Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 17:16 +0000
  Re: A slightly longer mini-oof2.fs example. andraszsoter@gmail.com - 2014-05-26 10:23 -0700
    Re: A slightly longer mini-oof2.fs example. Mark Wills <markwills1970@gmail.com> - 2014-05-27 02:09 -0700
      Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 06:07 -0500
      Re: A slightly longer mini-oof2.fs example. andraszsoter@gmail.com - 2014-05-28 10:17 -0700
    Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 05:39 -0500
      Re: A slightly longer mini-oof2.fs example. Mark Wills <markwills1970@gmail.com> - 2014-05-27 04:02 -0700
        Re: A slightly longer mini-oof2.fs example. Mark Wills <markwills1970@gmail.com> - 2014-05-27 04:04 -0700
        Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 06:19 -0500

csiph-web