OO

any chance of OO programming features?

[boriel]

It's planned for the 2.x releases... please be patient.

Regarding to OOP (which I also like):

1. It's rather complex to implement (will make the compiler much more complex; I'm still refactoring it a lot to avoid to rewrite it form scratch!)
2. Will make your program slower and take more memory (introduced overhead)
3. Will be hard to implement in Z80 due to its few registers
4. Will change BASIC dramatically

There's also another thing I would like to discuss with all of you regarding to the ZX Basic language and where it would go from here...
When you add pointers, OOP and templates to a BASIC language is it still BASIC? Basic was designed to be easy to learn (we all know). I just pointed out this in the FreeBasic forum: If you add OOP, Pointers and Templates you don't have BASIC anymore, but a language like C++ with BASIC keywords instead. It makes no sense.

Of course I will also like BASIC to evolve, but we should choose features with care (e.g. python and java do not use pointers), instead of copying what we already know from other languages.

I dont use templates or pointers, I agree it wouldnt be basic with pointers
the added overhead of OO wont be worth the loss of speed

[boriel]

I will add OO later, anyway, but we *all* should discuss how should ZX BASIC evolve.
E.g. Currently, DIM arrays are not dynamic, but Sinclair BASIC allows DIM to declare Arrays anyware in the code, in fact they should be dynamic and resizable (REDIM). Also they could be passed as references (byRef) and probably by Value.

In fact, ZX Basic support strings passed by value (which is rather complex), while FreeBasic and many other languages do not

Also dynamic containers like lists could be very interesting IMHO

could OO be an import? or is not an option

if I didnt use OO features in a speccy game, would the OO bits use some memory that I need?

[boriel]

If you don't use OO in your program, the code won't be affected. The overhead comes with the OOP.

Your choice, Boriel, but Object Oriented coding is not relevant to my interests.

I have to admit, being able to create and destroy objects with automatic garbage collection might be a great way to have sprite capability - and the sprite would have all the relevant data like location, speed, direction, and a pointer to its graphics location as part of the object data; with all the sprite operations available on the object...

But I have to admit this is about the only case I'm salivating over.

I have to admit, being able to create and destroy objects with automatic garbage collection might be a great way to have sprite capability - and the sprite would have all the relevant data like location, speed, direction, and a pointer to its graphics location as part of the object data; with all the sprite operations available on the object...

But I have to admit this is about the only case I'm salivating over.

This cannot be done with a linked list?
sprite.x(nr)
sprite.pointer(nr)
or similar?

you could do it with resizable arrays?

[boriel]

This cannot be done with a linked list?
sprite.x(nr)
sprite.pointer(nr)
or similar?

This is something I'd like to discuss. Instead of copying C++ or the like syntax, design a new one. more close to BASIC. For example:

• No pointers but references instead (like Java or Python)
  

    Code:

  sprite.x(nr)
sprite.nextSprite.x(nr)


• List containers embedded in the language
  

    Code:

  REM an Array is a container with all elements of the same type
REM A list is not

A = [1, "Hello", sprite]
A = A + [More, Elements] : REM Dynamic

PRINT A(3)

REM Sublisting
B = A(2 TO 5)


  
  Note: List can be implemented just with the references/pointer implementation above, but this is more BASIC sugar-syntax IMHO

Please, discuss

No pointers but references instead

yes

and lists would be nice, although they are a bit slow for use on speccy for most things
they would be a useful addition still

Please, discuss

For discussion
There are LinkedLists implemented in PureBasic. Please check this:
http://purebasic.com/documentation/link ... index.html

You can run though the list with ForEach Listname, add new elements, swap them, replace, check how many entries are there with listsize, etc. This is a excellent implementation and adding this to ZXBC would be a great improvement.
I do not think, it will make things much slower. For normal variable types it is easy to calculate the memory offset of the list entry, but not for dynamic strings.

This cannot be done with a linked list?
sprite.x(nr)
sprite.pointer(nr)
or similar?

Yes, I think that would work. We don't really have good garbage collected tools for dynamic memory structures at the moment - and that's one of the things SP1 uses, built into the code. It would be possible to build a sprite system with its own system, but that would be rather a shame to have it locked in there.

This cannot be done with a linked list?
sprite.x(nr)
sprite.pointer(nr)
or similar?

Yes, I think that would work. We don't really have good garbage collected tools for dynamic memory structures at the moment - and that's one of the things SP1 uses, built into the code. It would be possible to build a sprite system with its own system, but that would be rather a shame to have it locked in there.

I think, the linked lists are much easier to use than OO, so more coders can use it without knowing C.