Array of a class that accesses the array

[ttm]

Problem====
I have an array of some class Item, and I would like to have some method of Item be able to access elements of the array. Basically I would like to find a way to declare a prototype to a class. For example,

Turing:

var ArrayOfItems : array 1 .. 10 of pointer to Item class Item     proc AccessArray         %etc     end AccessArray end Item

This obviously doesn't work, because class Item is declared after array ArrayOfItems

Non-Solution====
According to the turing documentation (look up the page for keyword "type"), this is supposed to work:

Turing:

type PtrItem : forward var ArrayOfItem : array 1 .. 10 of PtrItem class Item     proc AccessArray         %etc     end AccessArray end Item type PtrItem : pointer to Item

The problem is when you type this, turing throws a "Type 'PtrItem' has not been resolved" when the documentation explicity states that it should be:

Quote:

A forward type allows pointers to be declared to the type before the type is resolved. To resolve a type, you must follow a forward with a declaration of the same name and in the same scope. This type declaration must include a typeSpec.

Crappy workaround====
The only way I can think of to get this to work is:

Turing:

class ItemProto     export AccessArray     deferred proc AccessArray end ItemProto var ArrayOfItem : array 1 .. 10 of pointer to ItemProto class Item     inherit ItemProto     body proc AccessArray         %etc     end AccessArray end Item

... which is extremely ugly. It requires declaring 2 classes. It requires inheritance when there should be none. It requires the methods of the class to be split into 2 places in the code. It also requires items of ArrayOfItem to be explicitly casted to Item before usage. But it gets the job done.

I there probably isn't a better way to do this but any insight is appreciated.

[DemonWasp]

You should be able to do this with implement and implement by according to ericfourfour here: http://compsci.ca/v3/viewtopic.php?t=10908&highlight=turing+class+forward+declaration

However, I wasn't able to get even his code sample working (complains about a syntax error at "implement") in Turing 4.1. I'm pretty sure that this feature existed in Turing 3.1.1, because I remember using it; I suspect support for that feature got broken at some point in Turing 4, and nobody noticed because Turing's OOP mechanisms are already so broken.

My only advice is to switch to a more useful language. There are literally dozens of languages that have functional OOP integrated, including several you seem to know, based on your other posts.

[Dreadnought]

ttm wrote:

According to the turing documentation (look up the page for keyword "type"), this is supposed to work:

The problem is when you type this, turing throws a "Type 'PtrItem' has not been resolved" when the documentation explicity states that it should be:

Quote:

A forward type allows pointers to be declared to the type before the type is resolved. To resolve a type, you must follow a forward with a declaration of the same name and in the same scope. This type declaration must include a typeSpec.

If you read your quote from the documentation if says "A forward type allows pointers to be declared to the type before the type is resolved". You created an array of PtrItem not ^PtrItem. What forward types allows you to do, is something like this.

Turing:

type testy : forward var Array : array 0 .. 4 of ^testy type testy :     record         number : int     end record for i : 0 .. 4     new Array (i)     Array (i) -> number := Rand.Int (1, 10) end for for j : 0 .. 4     put Array (j) -> number end for

To adress your problem.

Like DemonWasp says you can achieve what you want with implement and implement by (they're not broken as DemonWasp suspects, but the classes/modules must be units for this to work). ericfourfour actually said this in the post DemonWasp refered to.

ericfourfour wrote:

There is more and I can expand on it if you want. The only thing you have to watch out for is that Foo can inherit but FooBody cannot. They also must be in different Turing Unit files.

Example:
Item unit

Turing:

unit class Item     implement by ItemBody     export fcn1, proc1, var1     var var1 : int     deferred fcn fcn1 (param1 : real, param2 : string) : boolean     deferred proc proc1 (param1 : ^anyclass, var param2 : int) end Item

ItemModule unit

Turing:

unit module ItemModule     import Item     export Items     var Items : array 0 .. 42 of ^Item end ItemModule

ItemBody unit

Turing:

unit class ItemBody     implement Item     import ItemModule     export NewVar % you export anything new     var NewVar : string     body fcn fcn1 (param1 : real, param2 : string) : boolean         % blah blah blah ...         result true % So turing is happy when I test if this runs     end fcn1     body proc proc1 (param1 : ^anyclass, var param2 : int)         % blah blah blah ...     end proc1 end ItemBody

Finally in the turing program

Turing:

import Item % you may also want to import ItemModule depending on how you structure this put "YAY!"

If you look through the Turing GUI files they use this kind of stuff.

Also, a class with no specified inheritance inherits anyclass, so you could write your "crappy workaround" as

Turing:

var Items : array 1 .. 10 of ^anyclass class Item     export AccessArray     proc AccessArray         put "Hello World!" % Just as a test     end AccessArray end Item new Item, Items (1) Item (Items (1)).AccessArray

Hope this helps.

[DemonWasp]

Hmm. You're definitely, Dreadnought, but I'm left with one thought:

What the hell, Turing?

This object-oriented stuff in Turing feels like it has several different designers, none of whom was really clear on what OOP was in the first place.

This supposed solution (which is almost as clean as the same solution in C++), isn't actually what ericfourfour originally wrote. His caveat, which you quoted, notes that not only do you now have two classes and inheritance, but you have to have separate files too! Amazing.

I'd rant more, but I suspect you know just how goofed up Turing's OOP is better than I do.

[ttm]

Hmm. The new method using units and implement / implement by would work I suppose, but if so, it'd be even uglier than the original crappy workaround because in addition to using 2 classes, it also uses a module, keywords that are semi-broken, and is spread out between 3 separate files (I *hate* units). Also pointers to anyclass make me wince, but I suppose that's still better than the current crappy workaround. (Not that I need any of this in my code anywhere, I'm just speculating.)

Anyways. I'd agree with DemonWasp 100% in how crappy Turing's OOP is, but then all the more merit in writing a good program in Turing.