Is it a FOOP peculiarity?

[ralph.ronnquist]

Now I ran into a wall trying to use FOOP, or possibly it's really a bug. Namely that it appears arguments get copied in some funny way.... I've isolated my problem to this small example code:

Code: Select all

(context 'One)
(define (One:One v) (list (context) v))
(define (put v) (setf (self 1) v))

(context 'Two)
(define (Two:Two one x)
  (:put one x) ;---------------------- mark 1
  (list (context) one x))

(context MAIN)
(constant 'uno (One 1))
(constant 'duo (Two uno 2)) ;----- mark 2

(println "uno=" uno)
(println "duo=" duo)


Thus, there are two contexts: One and Two, where in particular the Two "objects" are supposedly tied to One "objects" on "construction". Both of them also hold an auxillary value, and when a Two object is created, its auxillary value is propagated to its One object.

But in the example, the One object passed in to the Two construction (at mark 2 in the code) is not the same as the One object it operates on in its constructor (at mark 1 in the code), and yet only a single One object has been created!
I get the following output:

Code: Select all

uno=(One 1)
duo=(Two (One 2) 2)

This is with "newLISP v.10.6.0 32-bit on Linux IPv4/6 UTF-8 libffi"

I really hope someone can enlighten me about what is going on here, because it kind of is a show stopper for me.

[rickyboy]

Doesn't look a FOOP thing. Looks like a "passing data by value" thing.

I haven't had to pass by reference yet in newLISP, so I've no experience to share, but here's a manual section on passing by reference.

Hope that helps a little.

[ralph.ronnquist]

Ah! Right. Thanks. Interesting that I hadn't caught on to it eariler, but obviously I need to change my mind set a bit...

[ralph.ronnquist]

Ok; that manual section is a little terse about how a punter like me should go about doing things whilst insisting on the idea of "changing fields in objects". I'm sure people have been here before, and I wonder if there's a "standard solution" somewhere?

My first intuition is that this object concept of mine should be implemented by passing around "symbolic references" rather than actual objects, and then have global support functions to
a) "create" an actual object (and get its symbolic reference),
b) to get the value of a field (by index) given a symbolic reference,
c) and to set (change!) the value of a field (by index) given a symbolic reference.
That would render my example to be as follows:

Code: Select all

(context 'One)
(define (One:One v)
  (create 'One v))
(define (put v)
  (setv (self) 1 v))

(context 'Two)
(define (Two:Two one x)
  (:put one x)
  (create 'Two one x))

(context MAIN)
(constant 'uno (One "A"))
(constant 'duo (Two uno "B"))
(println "uno=" uno " of "One:objects)
(println "duo=" duo " of " Two:objects)

With a resulting print out of

Code: Select all

uno=(One 0) of (("One" "B"))
duo=(Two 0) of (("Two" (One 0) "B"))

Thus, a symbolic reference, such as (One 0) is essentially an index into the table One:objects of actual One objects, as maintained by the global functions, and likewise for (Two 0).

I suppose, by that kind of approach I'll get my OO without hoops, except for that arms-length access to the actual objects. But I guess it might accrue unused objects in the tables.

Anyone having experience in this? Maybe even good implementations of my "create", "getv" and "setv" functions?

[ralph.ronnquist]

Maybe I should anwer my own question with: "Don't go there!".

I think it ultimately is better for me to return to a proper relational data perspective rather than attemting a relational modeling of an object oriented data perspective. In that way I can avoid forcing a base level of platform inclusions for offering an "improved" language level; not because it's hard to do, but because it's harder to maintain. As you all know, anything non-standard carries the cost of needing maintenance.

And what I liked with newLISP is it's pointedness for scripting, that virtually anything you like to automate in practice, you typically do in a page full of standard newLISP code (plus the two or three pages of comments).

The big pot holes for me are that, since it's Lisp (-ish), I can (and want to) do so much more, and also, that the name of FOOP did pull me astray into OO land. But really, it's rather a matter of me learning to utilize the polymorphism of FOOP within its boundary of a relational data perspective.