Renaming of a few Functions

[PolyVector]

I feel that there are a number of misleading function names.
An example would be the use of "XxxxID()".
Sometimes it refers to the ID Number of a particular item...
Other times it refers to the internal Handle of an item

Code: Select all

EventWindowID()
EventGadgetID()
;These return the ID

WindowID()
GadgetID()
;These return the Handle

Personally, these sorts of things have caused much confusion for me as I learn PB... I bet I'm not alone on this.

Might I suggest something like:

Code: Select all

EventWindowID()
EventGadgetID()
;These return the ID

WindowHandle()
GadgetHandle()
;These return the Handle

[Another Request]
I wouldn't mind something like this either:

Code: Select all

WindowID(hwnd)
GadgetID(hwnd)
;Returns the ID from the Handle :)

[Dare2]

Second the motion.

Methinks that would just be adding some keywords, no major new code involved, and deprecating the old keywords (and taking them out of the help manual).

[PolyVector]

One more problem...

MenuID() doesn't seem to be in the documentation... This should be documented...
And there is no UseMenu() command! That leaves MenuID() only half-useful...

[freak]

> Methinks that would just be adding some keywords, no major new code involved, and deprecating the old keywords (and taking them out of the help manual).

... and let the users rewrite some thousands of lines of code, because it is broken after that...
But hey, no big deal

Timo

[tinman]

> Methinks that would just be adding some keywords, no major new code involved, and deprecating the old keywords (and taking them out of the help manual).

... and let the users rewrite some thousands of lines of code, because it is broken after that...
But hey, no big deal :twisted:

Timo

I don't think Dare2 meant to take the commands out of the language, just to add the new ones and make the parts of the manual for the old commands point to the new commands (with a message such as "don't use this command in new code").

I'd prefer it to be the other way around, with the EventGadgetID() command changed to EventGadgetNumber(), because there is so much code and explanations which refer to the ID being the handle. To change it the way originally suggested would mean more work.

Although from a simplicity point of view it may be best to add new commands for both which make a clear separation between number and handle ;p

[Dare2]

lol.

Deprecating, not removing (except from the manual).

So now there are two keywords for the same thing, but one isn't advertised anymore.



[EDIT]

@tinman : You're right about leaving references in the manual, otherwise all the examples will have unsupported keywords (hidden features!)

[PB]

> let the users rewrite some thousands of lines of code

What's wrong with a quick search/replace?

[Kale]

Seems like a good idea, it would be more descriptive. And deprecating is good! All languages have a clean up every now and then

[PolyVector]

I know changing the name of a function can cause confusion at first... but it's FAR better than all new PB users being confused for the rest of time. Little problems like this can turn someone away from a language... Besides, If a simple search/replace is THAT hard, Fred could always make a 10 line PB program to convert your old code to the new format...

Either way, I see it as a problem
And I'm all for deprecating...

[LarsG]

*edit* this post is supposed to be after Shopro's *edit*

It can be ok to add new commands, but I don't see why on earth you'd want to break a lifelong "standard" naming, like While Wend and other loops.. they have been around since for a long time, and IMO makes an easier transition from another language for new users...

Don't get me wrong.. I like new commands, but breaking the BASIC standard is like breaking the C(++) standard.. and do you think that the C programmers would be happy about that?!?

-Lars

[guido]

This is only for symmetry and consistency reasons, but given Interface / EndInterface, Procedure / EndProcedure, Enumeration / EndEnumeration etc I consider EndWhile much nicer than WEnd which in turn reflects the meaning still a notch better than Wend...

[freedimension]

This is only for symmetry and consistency reasons, but given Interface / EndInterface, Procedure / EndProcedure, Enumeration / EndEnumeration etc I consider EndWhile much nicer than WEnd which in turn reflects the meaning still a notch better than Wend...

Yes, could be...
...but While ... Wend Loops are a standard in programming languages. Why force the advanced user to learn a new commandname? In the end it's an aliteration, While Wend, that alone is worth keeping it the way it is

[PolyVector]

I'm w/ freedimension on that one...
You wouldn't change For/Next to For/EndFor would you?

[Shopro]

maybe, only have "Warnings" be displayed when using a deprecated command would be a good idea. I think Java does this.

that way, old programs will compile, while newer ones won't use the old commands.

-Shopro

[guido]

Yes, could be...
...but While ... Wend Loops are a standard in programming languages. Why force the advanced user to learn a new commandname? In the end it's an aliteration, While Wend, that alone is worth keeping it the way it is ;-)

Of course its an alliteration, but its the only one to be seen. I prefer simple rules to pairs to be memorised. The Wend isn't striking - different keywords were chosen in other dialects and I don't recall any other language chosing WEND as a keyword. I suspect it was invented, when many programmers had their difficulties with typing (which may well be caused by the poor keyboards of boxes like ZX-80). The advanced users may well write Wend as they are used to, but PB-Newbies like me don't like to be forced to remember an additional exception the the keyword / endKeyword rule without deeper reason, which is missing in a simple end marker (END of Pascal, reversed keyword in Algol68, the curly brace of C or end of same indentation level in Python).
Next and Until are different (and I wouldn't bother to suggest a modification), because something follows (variable name or condition), even if I suspect, that the loop counter is redundant (and no implicit nexts are generated for possibly contained inner loops as it was in some strange implementation I darkly remember.

Rephrased: I'd suggest EndWhile as an alternative to Wend, and don't care whether the latter is deprecated or fully supported.