No matter how many polls you make, such a basic thing can't be changed.
It will simply kill the language.
Timo
Change \ with .
Baloney. Exaggeration for the sake of exaggeration. It would change and everyone would, after a few incidents of screwing it up, adapt and move on.It will simply kill the language.
I'm for it. The same as with blitzbasic. Mark intends to (if it ever gets released) change the \ to a . in blitzmax as well.
I don't think that last was a realistic response. Yes, you could change the syntax, but then you break with every code example (and project underway) that has been written. You also negate the existing documentation (such as it is), and you create a division in the community, because if some can argue that some things can be changed one way, then why can't other things be changed in a different way? Then we fight the long fight of trying to se the new syntax for what will become a new language.
And, as properly said, break the existing language. I don't favor the current syntax, but I recognize the inevitableness of accepting what it is for what it can do. People are free to move to a different syntax and a different language if they so choose. The language developer is entirely free to model his or her language in any manner that they desire, and none of us can dictate otherwise.
And, as properly said, break the existing language. I don't favor the current syntax, but I recognize the inevitableness of accepting what it is for what it can do. People are free to move to a different syntax and a different language if they so choose. The language developer is entirely free to model his or her language in any manner that they desire, and none of us can dictate otherwise.
has-been wanna-be (You may not agree with what I say, but it will make you think).
Fred implemented the Feature Request and Wishlist.oldefoxx wrote:The language developer is entirely free to model his or her language in any manner that they desire, and none of us can dictate otherwise.
My poll is such a request nothing more.
You are exactly describing PureBasic's history.oldefoxx wrote: Yes, you could change the syntax, but then you break with every code example (and project underway) that has been written. You also negate the existing documentation (such as it is), and you create a division in the community, because if some can argue that some things can be changed one way, then why can't other things be changed in a different way? Then we fight the long fight of trying to se the new syntax for what will become a new language.
I work with different languages and every one of them has the dot.oldefoxx wrote: People are free to move to a different syntax and a different language if they so choose.
PureBasic is the only one of them that uses the backslash.
Kill the languagefreak wrote:No matter how many polls you make, such a basic thing can't be changed.
It will simply kill the language.
Timo
Sorry, but I don't understand what you are saying
You code on the compiler 8O Wow.
And I thought Fred is the only one that messes with the compiler code...
Fred, watch your back man
@Freak: don't take my comments to serious pal
PureBasic has evolved, but to break with its existing syntax is to go against its past, not serve to merely add new features and capabilities.
Just because it has a past of evolving does not mean that it has gone
against itself. The only time a language will do that is when the creator
failed to think far enough ahead, and is either forced to adopt some
additional syntatucal rules that he/she doesn't want, or bites the bullet
and rectifies the language along some new structure that allows for more
expansion in the future.
As an example, PowerBASIC once supported DOT and Underscores in variable names. With the addition of TYPE structures, the DOT notation
was then restricted for identifying elements within a type, so you were
left with Underscores. But then it wanted to allow source lines to be
broken up into multiple lines, and deciced to adopt the _ at the end of a line to signal that the next line was to join to this one. Only that conflicted with allowing an underscore from being the trailing character of a variable name. So they modified the rule slightly, and the final two characters of a divided line have to now be a " _" (space-underscore). That continued to permit both uses for the underscore.
PowerBASIC also had embedded commands for the compiler to be marked with a leading # symbol. Then it wanted to extend the range of
constants to more than just integers, which were represented with a leading %. So it decided to change the leading # symbol for embedded commands to a $ sign, but it had to grandfather existing code, so now you could use eather, but expected to adopt the new $ convention. But then users asked for string constants as well, which would require a leading $,
so now you can still use either a leading # or $ for compiler directives, and the compiler is smart enough discern the proper use.
But that is comparitively easy, because the compiler only recognizes a fixed range of directives. Distinguishing them is pretty easy. Having two
different rules for uderscores makes them easy to separate as well. And
grandfathering allows existing code to run wherever possible - the dropped
DOT from variable names was done reluctantly, and only when it proved to be too difficult for both the compiler and the programmer to spot subtle errors and conflicts.
The self-defining variable type is unusual in a Basic dialect. Yet I don't hear anyone arguing to get rid of it. Now you want DOT naming for elements in Structures, but the use creates an immediate problem, because a.b could then either be a byte variable or a structure.element reference. You could attempt to define and have both in a program, and the compiler isn't going to know which it should be. When you look at it, only the context is going to identify what it should be, and only after a thorough understanding of the code around it and its purpose becomes clear. Things like that are what make programs unreadable, because the syntax rules overlap.
So if you want Structure.Element for PureBasic, you must then agree on a new syntax on self-defining variables, such as a.b or c.s.
Just because it has a past of evolving does not mean that it has gone
against itself. The only time a language will do that is when the creator
failed to think far enough ahead, and is either forced to adopt some
additional syntatucal rules that he/she doesn't want, or bites the bullet
and rectifies the language along some new structure that allows for more
expansion in the future.
As an example, PowerBASIC once supported DOT and Underscores in variable names. With the addition of TYPE structures, the DOT notation
was then restricted for identifying elements within a type, so you were
left with Underscores. But then it wanted to allow source lines to be
broken up into multiple lines, and deciced to adopt the _ at the end of a line to signal that the next line was to join to this one. Only that conflicted with allowing an underscore from being the trailing character of a variable name. So they modified the rule slightly, and the final two characters of a divided line have to now be a " _" (space-underscore). That continued to permit both uses for the underscore.
PowerBASIC also had embedded commands for the compiler to be marked with a leading # symbol. Then it wanted to extend the range of
constants to more than just integers, which were represented with a leading %. So it decided to change the leading # symbol for embedded commands to a $ sign, but it had to grandfather existing code, so now you could use eather, but expected to adopt the new $ convention. But then users asked for string constants as well, which would require a leading $,
so now you can still use either a leading # or $ for compiler directives, and the compiler is smart enough discern the proper use.
But that is comparitively easy, because the compiler only recognizes a fixed range of directives. Distinguishing them is pretty easy. Having two
different rules for uderscores makes them easy to separate as well. And
grandfathering allows existing code to run wherever possible - the dropped
DOT from variable names was done reluctantly, and only when it proved to be too difficult for both the compiler and the programmer to spot subtle errors and conflicts.
The self-defining variable type is unusual in a Basic dialect. Yet I don't hear anyone arguing to get rid of it. Now you want DOT naming for elements in Structures, but the use creates an immediate problem, because a.b could then either be a byte variable or a structure.element reference. You could attempt to define and have both in a program, and the compiler isn't going to know which it should be. When you look at it, only the context is going to identify what it should be, and only after a thorough understanding of the code around it and its purpose becomes clear. Things like that are what make programs unreadable, because the syntax rules overlap.
So if you want Structure.Element for PureBasic, you must then agree on a new syntax on self-defining variables, such as a.b or c.s.
has-been wanna-be (You may not agree with what I say, but it will make you think).
i *could* suggest a few small enhancements... 
<innocent looking and whistling >
<innocent looking and whistling >
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Up until now, the changes that broke old code were kept to an absolute minimum.
Mostly, only very few lines needed to be changed in a project to make
it run again with a newer version.
And yet still there were endless discussions, with lots of angry people.
If i remember right, even you, fsw, were ranting last time about some
changes...
Remember, these only affected a few lines of code per project, and now
you want to change something that will make every variable declaration
ever done in PB invalid. (yes, if you use the . for Structures, what do you
do with "a.l = 5" ?
So yes, it kills the language, because it kills every piece of code ever
written in it. How do spoken languages die? When nobody speaks them
anymore.
So with something like this, you really kill the *current PB*, and
effecively start a new one, and I doubt that every user is willing to accept
that.
As you all know from past discussions, i'm all for making changes that
are neccesary, even when they break some backward compatibility,
but this one is just too much, and imho not really neccesary.
(did I mention, i like the '\' notation?
)
Timo
Mostly, only very few lines needed to be changed in a project to make
it run again with a newer version.
And yet still there were endless discussions, with lots of angry people.
If i remember right, even you, fsw, were ranting last time about some
changes...
Remember, these only affected a few lines of code per project, and now
you want to change something that will make every variable declaration
ever done in PB invalid. (yes, if you use the . for Structures, what do you
do with "a.l = 5" ?
So yes, it kills the language, because it kills every piece of code ever
written in it. How do spoken languages die? When nobody speaks them
anymore.
So with something like this, you really kill the *current PB*, and
effecively start a new one, and I doubt that every user is willing to accept
that.
As you all know from past discussions, i'm all for making changes that
are neccesary, even when they break some backward compatibility,
but this one is just too much, and imho not really neccesary.
(did I mention, i like the '\' notation?
)Timo
quidquid Latine dictum sit altum videtur
... auch du mein sohn Brutusfreak wrote: And yet still there were endless discussions, with lots of angry people.
If i remember right, even you, fsw, were ranting last time about some
changes...
Timo
You are right, but the last time IMHO the changes that took place had more influence on how to work with PureBasic.
AFAIK it's up to Fred to decide if he implements user wishes or not
Maybe... How about classes and object inheritance? How about a dozen other things that would improve the language? How about sticking to the issue at hand?Why do people always want to make PureBasic like every other language?
Does purebasic also need:
- Large executables?
- A large runtime?
- declare statements for the API calls?
- obscure syntax?
\ instead of . doesn't break anything other than a) those people currently working on a project and wish to upgrade their compiler. b) those people wishing to recompile old code.
In both cases, those individuals have a separate install of PB. Since it's not dependent upon any registry settings, that's not an issue at all. Better yet, is that it's a compiler switch. /. means you use the . instead of the slash. Big deal.
Some people just like to overcomplicate matters.
You can already do this...Kanati2 wrote: Maybe... How about classes and object inheritance?
Below is an example that came with an older beta version.
Don't know who did this ( Fred or Danilo )
Code: Select all
;
; Example to build your COM/DX interface yourself, for example developping an Object
; Oriented DLL to use in C++ or Java
;
Interface IMyClock
GetTime()
SetTime(NewTime)
GetName()
SetName(Name$)
EndInterface
Structure MyClockFunctions
GetTime.l
SetTime.l
GetName.l
SetName.l
EndStructure
Structure MyClockObject
*VirtualTable.MyClockFunctions
CurrentTime.l
Name$
EndStructure
Procedure GetTime(*Object.MyClockObject)
; MessageRequester("Info", "GetTime()")
ProcedureReturn *Object\CurrentTime
EndProcedure
Procedure SetTime(*Object.MyClockObject, NewTime)
; MessageRequester("Info", "SetTime(): "+Str(NewTime))
*Object\CurrentTime = NewTime
EndProcedure
Procedure SetName(*Object.MyClockObject, Name$)
MessageRequester("Info", "SetName(): "+Name$)
*Object\Name$ = Name$
EndProcedure
MyClockFunctions.MyClockFunctions\GetTime = @GetTime()
MyClockFunctions.MyClockFunctions\SetTime = @SetTime()
; MyClockFunctions.MyClockFunctions\GetName = @GetName()
MyClockFunctions.MyClockFunctions\SetName = @SetName()
MyClockObject.MyClockObject\VirtualTable = MyClockFunctions
MyClock.IMyClock= @MyClockObject
MyClock\SetTime(10)
MyClock\GetTime()
MyClock\SetName("My new clock name")
Debug OffsetOf(IMyClock, SetName())
And some oversimplify them. Saying that changing \ to . wouldn't break anything is just plain wrong. Doing so would break nearly every line of code that a variable is used in (the dot is used in declaring and accessing variables).Kanati2 wrote:Some people just like to overcomplicate matters.
While there have been releases that break backward compatibility before (3.90 was a big one) that was to add significant functionality. This is merely a cosmetic change to make PB "more like" other languages for no other reason than mimicry. If we were talking about adding some significant feature to PB then breaking old code might be an option - but we aren't.
There is no reason (good or bad) to change \ to . other than to mimic VB or some other language - and that reason is no reason at all.
Having said all that - it is a perfectly valid feature request
-Mitchell
Check out kBilling for all your billing software needs!
http://www.k-billing.com
Code Signing / Authenticode Certificates (Get rid of those Unknown Publisher warnings!)
http://codesigning.ksoftware.net
Check out kBilling for all your billing software needs!
http://www.k-billing.com
Code Signing / Authenticode Certificates (Get rid of those Unknown Publisher warnings!)
http://codesigning.ksoftware.net