Is there a known problem with LEN and namespaces? dim n as long dim s as string = "123" '#define use_namespace #ifdef use_namespace namespace test_ #endif private function testme(s as string) as string return s + "123" end function #ifdef use_namespace end namespace #endif #ifdef...

Ah, i see José cross-posted. I would call José´s stuff "advanced" (i recommend having a look, by all all means) while the stuff i´m speaking of is far more basic. In general i´m not against including things with an include file. It´s a great method of adding (advanced - this is my point!) ...

i agree to point #1 and #2 in your preceding post, i disagree with #3 and #4 (please have a look at my pull requests: array and string. The new pp operators make a versatile syntax possible, without the need to re-write lots of the compiler) i made it work! i see your point #5 and i admit this is th...

Well, i have learned that adding multiple new key words (like in your proposal) is a "no go" - the more the more words are needed. Some even don´t want to add one single new word to the global namespace, however justified this might be. Hiding your new words in a namespace is only of limit...

The reaction to that is of course: "rather safe than sorry". (Don't allow a precedence case, to start with!) ... with you as the Guardian of the ultimate truth! To me it seems this is becomming more and more a matter of "religion", than of arguments and facts... I accept your po...

I think I understood from the beginning that your proposal is a file to include, containing a macro allowing to call different procedures in a namespace.

Yes!!!

@fxm,
you definitly weren´t the addressee of my previous post. I know you got it right from the beginning.

@JK, can you implement any of your ideas, without adding a single new key word to 'global namespace' ? The answer to my rethorical question (above) is definitely "NO". The answer to your question is definitely " YES " If you had made the effort of reading the opening post thorou...

I´m asking two questions: If i got it right, then the namespaces´ name is unavailable (blocked, reserved, consumed) for any other use in the same code. That´s the same as for a macro. Is this true (i cannot have a procedure, a variable, a constant, an enum with the same name as a namespace used in m...

I do not see any fundamental differences with a classic namespace usage: added to what i already posted above: If i got it right, then the namespaces´ name is unavailable (blocked, reserved, consumed) for any other use in the same code. That´s the same as for a macro. But a macro offers a much more...

- "array.sort" looks too much like object syntax to me, not so much like (procedural) BASIC syntax. Maybe i´m a traditionalist.

- second reason is, that you cannot do with it, what i can do implementing macros. Please, have a closer look here (https://github.com/jklwn2/fbc/tree/Array)

There have already been discussions about how new features should be added to the language. I can see two positions: 1.) don´t add new keywords to the main namespace, put everything new into an include file into it´s own namespace in order not to enlarge and "pollute" the main namespace. 2...

@grindstone, you need an editior, which can deal with LF (0x0A) only as linebreaks. In Windows the standard is CR+LF (0x0D + 0x0A). Obviously your editior doesn´t accept LF only as linebreak (or maybe it just isn´t set to do so). Or write a little conversion utility replacing LF with CR+LF in angros...

Of course you are right!

Personally, even if it´s technically possible, i would do everything i can to avoid having "dwstring" and "fb.dwstring" in the same code. It´s too easy to make hard to find mistakes - YMMV.


JK

I understand. That means that "USTRING" is a placeholder for fbc's var-len wstring data type in the future. Which means that "USTRING" eventually will be become reserved word Yes! This is what i wanted you understand all the time. (maybe my fault: language problems, not my nativ...

Sorry to contradict you again. The text you quoted is about writing user code,it´s not about the compiler. Whatever I accept, someone will be disappointed Yes, that´s a problem in general, when you are the boss :-) Once again, i understand that too many "core" statements in a language don´...