Change \ with .

[freedimension]

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).

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

Hugh!!! Triple-FullACK

For conveniently converting C or VB Code to PB, some people invented the search and replace functionality in the editor of your choice.

[fsw]

...Having said all that - it is a perfectly valid feature request

[fsw]

For conveniently converting C or VB Code to PB, some people invented the search and replace functionality in the editor of your choice.

The same can be said with changing '\' with '.' in old pb code.

[Kale]

Maybe... How about classes and object inheritance? How about a dozen other things that would improve the language?

OOP to improve the language? This is one hell of a hot potato to drop in this mix. I personally don't agree that OOP would improve PB but in other languages such as Python it makes sense since everything in Python is an object.

[freedimension]

For conveniently converting C or VB Code to PB, some people invented the search and replace functionality in the editor of your choice.

The same can be said with changing '\' with '.' in old pb code.

Yes, but I see no reason why I should. I wrote my Code for PB, and PB expected it like this. If you have C- or VB-Code, nobody forces you to convert it to PB. Got my Point?

[GedB]

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?

My point is with the comments such as "like other programming languages" and "PB is grown up now." There are regular threads that say 'I want PB to be just like every other language'.

If every other language got it right, then why would I have settled on PB?

If this approach was taken, grabbing every feature from every other language PB would quickly morph into a fat, bloated language like all the others.

You ask for class and object inheritance. If these are introduced then how should resources be handled? Will a garbage collector be required? That will add a huge overhead to your executables.

At the moment PB only includes the functions that I use within the executable. That is why the executable is so small. As soon as you bring in inheritance the ancestor classes start linking in functions I'm not using.

To get around this you have to make the compiler much much more complicated. Full dead code analysis is needed.

All the other langauges became fat and bloated for good resson. As soon as you take a certain path, the implications cascade until your language is like every other.

The command line option is another good example. One of the things I value so hightly about PB is that even the compliated code postings on this forums can be pasted into my Editor and run, no trouble.

As soon as you start adding command line options, then I lose this. Some people post code with dots and others with slashes. I can't just cut and paste, I have to check which one they are using.

It may seem like a small thing, but my tolerance for hassle is low. I've moved on from many other languages and if PB starts to waste my time like this I'll move on again.

There is no other language like PB. I would like other languages to be more like PB, but I don't want PB to be like every other language.

[Inner]

Easy fix;

#MACRO \ AS .

At the top of code.

can't remember the posters name now but, _ for end of line on a single line of code spread over many is absolutely stuppid, did the programmer ever hear of $0D,$0A ?

[Kale]

One of the things I value so hightly about PB is that even the compliated code postings on this forums can be pasted into my Editor and run, no trouble. As soon as you start adding command line options, then I lose this.

This is my fear when macros are introduced.

[GedB]

Easy fix;

#MACRO \ AS .

Exactly my point. One fix leads to another leads to another.

All of this will add what functionality?

[freak]

Come on guys, do you really think this change will happen?
I don't think so.

Timo

[Karbon]

I sure hope it doesn't!

[oldefoxx]

Relax. The suggestion was made. It was countered. The problems with
doing it were discussed. It was even voted on by a poll, although that has
no significance at all (compiler design and implementation is not a subject
of popular opinion or dispute, but designer preference). And its been
talked to death. So let's move on.

[Inner]

Why are you scared of macros there good things, not just for changing how things about how a compiler see a \ rather than a .

I've never liked \ personally, frankly it shouldn't be even . it should be "->" or but no need to complain really \ works for the most part all be it looking a little bizzare.

[GedB]

Inner,

\

Is just one character that is easily accessible. It is used to traverse file hierarchies, so why is it not suitable for structure hierarchies?

->

is two characters, one of which requires the shift key. How on earth is that better?

[thefool]

Inner,

\

Is just one character that is easily accessible. It is used to traverse file hierarchies, so why is it not suitable for structure hierarchies?

->

is two characters, one of which requires the shift key. How on earth is that better?

I agree, \ is better than ->

so lets keep it at \

but thats not a reason to be angry...