Author Topic: Some thoughs on implementation.  (Read 67 times)

0 Members and 1 Guest are viewing this topic.

Brian Alvarez

  • Full Member
  • ***
  • Posts: 218
    • PluriBASIC
Some thoughs on implementation.
« on: January 13, 2019, 10:00:39 PM »
 I have been tackling some issues i have encountered. There are some solutions that i am happy with, and some others, not so much.

 Overall, i am enjoying working with oxygen, and the fact that there is no help available, is kind of the salt to the challenge, making it even more enjoyable. Some times i need to go back and do it better because i am presented with a method that is better than what i was doing, because there is not help file, but thats ok.

 Some of the things i wonder why where implemented the way they were in oxygen are... shared equates. For example, i am used to being able to use this:

Code: [Select]
$EXTRA = "SOMETHING"
%EXTRA = 12345

 No collisions, everything is fine. However, with Oxygen, a string constant has exactly the same name than a numeric one, making it necessary to add some kind of disctintive. So, lets say there is a constant named Extra, then no local or global variables, functions, classes, unions or Types can be created with that name.

 So, in order to allow this, i had to add a prefix to each constant, numeric, string and wstring equates. This way there are no collisions. However, when trying to use one of this equates in RAW blocks, it will not be as intuitive, because, when an equate is defined as %extra, in a RAW block it will be required to refer to it as _20EXTRA. I have no problem adding a prefix for internal stuff that the end programmer does not need to touch, but for this i would rater like to do it some other way.

I have more thoughts but something has come up while redacting this, so i will continue in the morning. :)

Brian Alvarez

  • Full Member
  • ***
  • Posts: 218
    • PluriBASIC
Re: Some thoughs on implementation.
« Reply #1 on: January 14, 2019, 10:35:51 AM »
For example, take a look at this code:

https://forum.powerbasic.com/forum/user-to-user-discussions/powerbasic-for-windows/47474-on-screen-ruler/page3

 As you can see there is an equate named %POINT, converting it literally would collide with the TYPE POINT, so, a distinctive was required.
A lot of existing code has such collisions.